Nabble - gcc - bugs

[Bug target/42208] gcc trunk incorrectly linking against /usr/lib/libgcc_s.1.dylib

2009-12-23T06:10:32Z

------- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-12-23 14:10 -------
Current behavior is correct.

--

howarth at nitro dot med dot uc dot edu changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42208

[Bug java/42307] WalkerTest execution failures

2009-12-23T06:09:16Z

------- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-12-23 14:09 -------
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html.

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42307

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

2009-12-23T06:09:01Z

------- Comment #39 from dominiq at lps dot ens dot fr 2009-12-23 14:09 -------
With the patch in comment #37, the tests pass, but are not vectorized. I did a
mistake after applying the patch in comment #38 and I am doing a "quick"
bootstrap (~5h).

I have regtested the patch in comment #31 and I have ~75 regressions on
x86_64-apple-darwin10 in the gcc vect test suite (~100 on
powerpc-apple-darwin9). Is this expected? and do you want the list?

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/42480] New: Wrong-code for air.f90 with "-O2 -fgraphite-identity"

2009-12-23T05:58:04Z

At revision 155425 the executable for air.f90 compiled with "-O2
-fgraphite-identity" gives:

...
ITERATION# TIME FINAL MASS RESIDUAL
14 100.000043187820 0.01000000 NaN
deltat, final t, iterations
100.00000000000000 100.00004318782042 14
14 NaN

The executable obtained with "-O1 -fgraphite-identity" is correct.

--
Summary: Wrong-code for air.f90 with "-O2 -fgraphite-identity"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42480

[Bug middle-end/42479] New: Wrong-code for induct.f90 with " -O3 -floop-block"

2009-12-23T05:54:31Z

At revision 155425 the executable for induct.f90 compiled with " -O3
-floop-block" gives:

...
Maximum wand/quad abs rel mutual inductance = 1.84138324899744549E-002
...

instead of

...
Maximum wand/quad abs rel mutual inductance = 5.95379428444659381E-002
...

when compiled with "-O2 -floop-block".

Note that the wrong code runs in ~8.5s, while the fastest right code runs in
~14s.

--
Summary: Wrong-code for induct.f90 with " -O3 -floop-block"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42479

[Bug fortran/42478] [meta-bug] gfortran OpenMP bugs

2009-12-23T05:49:46Z

------- Comment #1 from dfranke at gcc dot gnu dot org 2009-12-23 13:49 -------
Shouldn't the "openmp" keyword
(http://gcc.gnu.org/bugzilla/describekeywords.cgi) be sufficient?

--

dfranke at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dfranke at gcc dot gnu dot
| |org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478

[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64

2009-12-23T05:41:45Z

------- Comment #10 from janus at gcc dot gnu dot org 2009-12-23 13:41 -------
*** Bug 42477 has been marked as a duplicate of this bug. ***

--

janus at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |janus at gcc dot gnu dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471

[Bug fortran/42477] Runtime segfault with -fopenmp -static

2009-12-23T05:41:44Z

------- Comment #3 from janus at gcc dot gnu dot org 2009-12-23 13:41 -------
(In reply to comment #2)
> Dupe of PR30471?

Ah, yes, indeed. The segfault is cured by the workaround from comment #7 of
that PR (i.e. compiling with -fopenmp -static -Wl,--whole-archive -lpthread
-Wl,--no-whole-archive).

*** This bug has been marked as a duplicate of 30471 ***

--

janus at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477

[Bug fortran/42477] Runtime segfault with -fopenmp -static

2009-12-23T05:32:35Z

------- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-23 13:32 -------
Dupe of PR30471?

--

dfranke at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |dfranke at gcc dot gnu dot
| |org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477

[Bug fortran/42477] Runtime segfault with -fopenmp -static

2009-12-23T05:29:15Z

------- Comment #1 from janus at gcc dot gnu dot org 2009-12-23 13:29 -------
Btw, one also gets the segfault without actually calling 'omp_get_num_procs':

subroutine s
!$ use omp_lib
!$ print *, 'Number of processors:', omp_get_num_procs()
end subroutine

end

This program can be compiled and run also without -fopenmp, and does absolutely
nothing (besides producing a segfault with -fopenmp -static).

--

janus at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.4.1 4.5.0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477

[Bug fortran/42478] New: [meta-bug] gfortran OpenMP bugs

2009-12-23T05:13:13Z

--
Summary: [meta-bug] gfortran OpenMP bugs
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478

[Bug fortran/42477] New: Runtime segfault with -fopenmp -static

2009-12-23T04:56:39Z

Consider this simple program:

use omp_lib
print *, 'Number of processors:', omp_get_num_procs()
end

After compiling this with "-fopenmp -static -fbacktrace", executing it gives
the output:

Number of processors: 2

Program received signal 11 (SIGSEGV): Segmentation fault.

Backtrace for this error:
+ function __restore_rt (0x41EAB0)
from file sigaction.c

The segfault is gone when compiling without the -static flag. Also this seems
to be a Fortran-only problem. An equivalent C program does not run into the
segfault.

--
Summary: Runtime segfault with -fopenmp -static
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42477

[Bug translation/42469] option help strings not properly using TAB

2009-12-23T04:08:18Z

------- Comment #1 from jsm28 at gcc dot gnu dot org 2009-12-23 12:08 -------
Part of this appears to be the same exgettext issue as bug 42467.

The rest appears to be option help strings using one or more spaces where
a single TAB should be used:

common.opt:-Wframe-larger-than=<number> Warn if a function's stack frame
requires more than <number> bytes
common.opt:-fcompare-debug[=<opts>] Compile with and without e.g. -gtoggle, and
compare the final-insns dump
common.opt:-fdbg-cnt=<counter>:<limit>[,<counter>:<limit>,...] Set the debug
counter limit.
common.opt:-fira-verbose=<number> Control IRA's level of diagnostic messages.
common.opt:-flto-compression-level=<number> Use zlib compression level <number>
for IL
common.opt:-fplugin-arg-<name>-<key>[=<value>] Specify argument <key>=<value>
for plugin <name>
c.opt:-imultilib <dir> Set <dir> to be the multilib include subdirectory
fortran/lang.opt:-fblas-matmul-limit=<n> Size of the smallest matrix for
which matmul will use BLAS
fortran/lang.opt:-finit-character=<n> Initialize local character variables to
ASCII value n
fortran/lang.opt:-finit-integer=<n> Initialize local integer variables to n
fortran/lang.opt:-finit-logical=<true|false> Initialize local logical variables
fortran/lang.opt:-finit-real=<zero|nan|inf|-inf> Initialize local real
variables
fortran/lang.opt:-fmax-array-constructor=<n> Maximum number of objects
in an array constructor

--

jsm28 at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |40883
nThis| |
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-12-23 12:08:18
date| |
Summary|19 localization fails with |option help strings not
|gcc ---help=fortran |properly using TAB

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42469

[Bug translation/42467] exgettext should not remove TABs from option help strings

2009-12-23T04:00:37Z

------- Comment #4 from jsm28 at gcc dot gnu dot org 2009-12-23 12:00 -------
*** Bug 42468 has been marked as a duplicate of this bug. ***

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42467

[Bug translation/42468] Localization fails with --CLASSPATH line in gcc --help=Java

2009-12-23T04:00:37Z

------- Comment #1 from jsm28 at gcc dot gnu dot org 2009-12-23 12:00 -------
This is the same exgettext bug as bug 42467.

*** This bug has been marked as a duplicate of 42467 ***

--

jsm28 at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42468

[Bug translation/42467] exgettext should not remove TABs from option help strings

2009-12-23T03:58:25Z

------- Comment #3 from jsm28 at gcc dot gnu dot org 2009-12-23 11:58 -------
The option help string is passed for translation as a whole before
the special interpretation for TAB as described in options.texi:

The help text is automatically line-wrapped before being displayed.
Normally the name of the option is printed on the left-hand side of
the output and the help text is printed on the right. However, if the
help text contains a tab character, the text to the left of the tab is
used instead of the option's name and the text to the right of the
tab forms the help text. This allows you to elaborate on what type
of argument the option takes.

Thus, exgettext is wrong to remove the text before the tab (which
generally does need translation of things such as <options>).

--

jsm28 at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |40883
nThis| |
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-12-23 11:58:25
date| |
Summary|Localization fails with - |exgettext should not remove
|gnat<options> line in gcc --|TABs from option help
|help=Ada |strings

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42467

[Bug c/42476] New: "warning: will never be executed" about code which is executed with "-Wunreachable-code"

2009-12-23T03:20:11Z

Compiling the following code snippet:

int main(int argc, char **argv)
{
int i;
int asize = 3;
int array[3];

for (i = asize - 1; i < asize; i++)
array[i] = 42;

for (i = 0; i < asize; i++)
printf("%i\n", array[i]);
}

with "gcc -O -Wunreachable-code gccbug.c" shows the following warning message:

gccbug.c: In function 'main':
gccbug.c:8: warning: will never be executed

(Where line 8 is the body of the first for-loop, array[i] = 42;)

Though, array[2] is set to 42, as the later printf shows when executing.

When replacing the "- 1" of line 7 with an higher value, e.g. "- 2", the
warning disappears. Not passing "-O" to the compiler lets the warning
disappear, too.

I tested it with two versions of gcc. The first:
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.4
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.4/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0,
pie-10.1.5'
Thread model: posix
gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5)

The second:
Using built-in specs.
Target: arm-elf
Configured with: /tmp/gcc.ndS8/gcc-4.4.1/configure --enable-languages=c
--with-mpfr=/usr --without-headers --target=arm-elf --prefix=/usr/local/arm-elf
--with-local-prefix=/usr/local/arm-elf --disable-werror --disable-multilib
--disable-shared --disable-nls --disable-libssp --with-arch=armv4t
--with-cpu=arm7tdmi-s
Thread model: single
gcc version 4.4.1 (GCC)

The warning appears with both gcc versions.

--
Summary: "warning: will never be executed" about code which is
executed with "-Wunreachable-code"
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: agraf at znc dot in

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42476

[Bug rtl-optimization/42429] [4.4 Regression] Miscompilation of 2fish on s390

2009-12-23T03:14:39Z

------- Comment #9 from jakub at gcc dot gnu dot org 2009-12-23 11:14 -------
Fixed.

--

jakub at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42429

[Bug c++/42472] class members not getting assigned access thru another method

2009-12-23T03:09:22Z

------- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 11:09 -------
C++ is not java, you cannot delegate to another constructor like this:

primes::primes(ulong p):maxp(p) { primes(); }

That creates a temporary object of type primes, it does not call the
constructor.

Therefore primes::i and primes::p are not initialised by the primes(long)
constructor.

--

redi at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
Version|unknown |4.3.2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472

[Bug c++/38392] Template friend function injection

2009-12-23T03:02:07Z

------- Comment #8 from redi at gcc dot gnu dot org 2009-12-23 11:02 -------
See http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/cwg_defects.html#329

I believe a "use" of the function must come after the definition for it to be
instantiated, indeed if I add this after the explicit instantiation it links
OK:

void(*pf)() = &Function;

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392

[Bug c++/42471] No return value from operator =() is accepted by the compiler

2009-12-23T02:41:19Z

[Bug c++/42470] Conversion Constructor not accepted/recognized

2009-12-23T02:30:29Z

------- Comment #1 from redi at gcc dot gnu dot org 2009-12-23 10:30 -------
The code should not compile, Visual Studio is wrong.

Base b = 5;

is a copy initialization, equivalent to

Base b = Base(5);

which requires a copy constructor, but your copy constructor takes a non-const
Base& and so cannot bind to the temporary.

This is covered by 8.5 [dcl.init] paragraph 14 in the standard.

--

redi at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
GCC build triplet|What is this? |
GCC host triplet|Not sure what this means; |
|here is the result of uname |
|-a: Linux |
GCC target triplet|What is this? |
Resolution| |INVALID

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470

[Bug target/42448] [4.3/4.4/4.5 Regression] Wrong code with _Complex char in structure

2009-12-23T01:57:03Z

[Bug objc/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954

2009-12-23T01:39:44Z

[Bug objc/42475] ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954

2009-12-23T01:06:10Z

------- Comment #1 from yavor at gnu dot org 2009-12-23 09:06 -------
Created an attachment (id=19379)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19379&action=view)
preprocessed source

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475

[Bug objc/42475] New: ICE at -O1 and above: internal compiler error: in simplify_subreg, at simplify-rtx.c:4954

2009-12-23T01:04:35Z

This happens only on x86_64-unknown-linux-gnu and x86_64-pc-kfreebsd-gnu.
Complete command:

gcc CynthiuneHeaderCell.m -c \
-MMD -MP -I/home/y/yavor/include -DGNUSTEP
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1
-DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG
-fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -O2
-fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS
-fgnu-runtime -v -save-temps -fconstant-string-class=NSConstantString
-IFrameworks -IFrameworks/Cynthiune/Cynthiune.framework/Headers -I.
-I/home/y/yavor/GNUstep/Library/Headers -I/home/y/yavor/local/include/GNUstep
-I/home/y/yavor/include/GNUstep \
-o obj/CynthiuneHeaderCell.m.o
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++,objc
--with-mpfr=/home/y/yavor CPPFLAGS=-I/home/y/yavor/include
Thread model: posix
gcc version 4.4.2 (GCC)
COLLECT_GCC_OPTIONS='-c' '-MMD' '-MP' '-I/home/y/yavor/include' '-DGNUSTEP'
'-DGNUSTEP_BASE_LIBRARY=1' '-DGNU_GUI_LIBRARY=1' '-DGNU_RUNTIME=1'
'-DGNUSTEP_BASE_LIBRARY=1' '-D_REENTRANT' '-fPIC' '-g' '-Wall' '-DDEBUG'
'-fno-omit-frame-pointer' '-DGSWARN' '-DGSDIAGNOSE' '-Wno-import' '-O2'
'-fno-strict-aliasing' '-fexceptions' '-fobjc-exceptions'
'-D_NATIVE_OBJC_EXCEPTIONS' '-fgnu-runtime' '-v' '-save-temps'
'-fconstant-string-class=NSConstantString' '-IFrameworks'
'-IFrameworks/Cynthiune/Cynthiune.framework/Headers' '-I.'
'-I/home/y/yavor/GNUstep/Library/Headers'
'-I/home/y/yavor/local/include/GNUstep' '-I/home/y/yavor/include/GNUstep' '-o'
'obj/CynthiuneHeaderCell.m.o' '-shared-libgcc' '-mtune=generic'

/srv/data/home/y/yavor/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.2/cc1obj
-E -quiet -v -I/home/y/yavor/include -IFrameworks
-IFrameworks/Cynthiune/Cynthiune.framework/Headers -I.
-I/home/y/yavor/GNUstep/Library/Headers -I/home/y/yavor/local/include/GNUstep
-I/home/y/yavor/include/GNUstep -iprefix
/srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/ -MMD
obj/CynthiuneHeaderCell.m.d -MP -MQ obj/CynthiuneHeaderCell.m.o -DGNUSTEP
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1
-DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -DDEBUG -DGSWARN -DGSDIAGNOSE
-D_NATIVE_OBJC_EXCEPTIONS CynthiuneHeaderCell.m -mtune=generic -Wall
-Wno-import -fPIC -fno-omit-frame-pointer -fno-strict-aliasing -fexceptions
-fobjc-exceptions -fgnu-runtime -fconstant-string-class=NSConstantString -g
-fworking-directory -O2 -fpch-preprocess -o CynthiuneHeaderCell.mi
ignoring nonexistent directory
"/srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/srv/data/home/y/yavor/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include"
ignoring duplicate directory
"/srv/data/home/y/yavor/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include-fixed"
ignoring nonexistent directory
"/srv/data/home/y/yavor/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/../../../../x86_64-unknown-linux-gnu/include"
ignoring nonexistent directory "/home/y/yavor/GNUstep/Library/Headers"
#include "..." search starts here:
#include <...> search starts here:
/home/y/yavor/include
Frameworks
Frameworks/Cynthiune/Cynthiune.framework/Headers
.
/home/y/yavor/local/include/GNUstep
/home/y/yavor/include/GNUstep
/srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include

/srv/data/home/y/yavor/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.2/include-fixed
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-c' '-MMD' '-MP' '-I/home/y/yavor/include' '-DGNUSTEP'
'-DGNUSTEP_BASE_LIBRARY=1' '-DGNU_GUI_LIBRARY=1' '-DGNU_RUNTIME=1'
'-DGNUSTEP_BASE_LIBRARY=1' '-D_REENTRANT' '-fPIC' '-g' '-Wall' '-DDEBUG'
'-fno-omit-frame-pointer' '-DGSWARN' '-DGSDIAGNOSE' '-Wno-import' '-O2'
'-fno-strict-aliasing' '-fexceptions' '-fobjc-exceptions'
'-D_NATIVE_OBJC_EXCEPTIONS' '-fgnu-runtime' '-v' '-save-temps'
'-fconstant-string-class=NSConstantString' '-IFrameworks'
'-IFrameworks/Cynthiune/Cynthiune.framework/Headers' '-I.'
'-I/home/y/yavor/GNUstep/Library/Headers'
'-I/home/y/yavor/local/include/GNUstep' '-I/home/y/yavor/include/GNUstep' '-o'
'obj/CynthiuneHeaderCell.m.o' '-shared-libgcc' '-mtune=generic'

/srv/data/home/y/yavor/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.4.2/cc1obj
-fpreprocessed CynthiuneHeaderCell.mi -quiet -dumpbase CynthiuneHeaderCell.m
-mtune=generic -auxbase-strip obj/CynthiuneHeaderCell.m.o -g -O2 -Wall
-Wno-import -version -fPIC -fno-omit-frame-pointer -fno-strict-aliasing
-fexceptions -fobjc-exceptions -fgnu-runtime
-fconstant-string-class=NSConstantString -o CynthiuneHeaderCell.s
GNU Objective-C (GCC) version 4.4.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2, GMP version 4.1.4, MPFR version 2.4.1.
warning: GMP header version 4.1.4 differs from library version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b175c3d272f5dca0566abc1b5eef4179
CynthiuneHeaderCell.m: In function '-[CynthiuneHeaderCell
drawInteriorWithFrame:inView:]':
CynthiuneHeaderCell.m:100: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4954
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

--
Summary: ICE at -O1 and above: internal compiler error: in
simplify_subreg, at simplify-rtx.c:4954
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yavor at gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42475

[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM

2009-12-23T01:00:59Z

------- Comment #8 from ramana at gcc dot gnu dot org 2009-12-23 09:00 -------
Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01060.html

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887

[Bug bootstrap/42474] New: SIGSEGV in linemap_lookup

2009-12-23T00:46:06Z

While building gcc from tag gcc_4_4_1_release on Haiku, a segfault occurred
several times in various files, in the same location in linemap_lookup:

mn = set->cache;

The set variable is NULL. I changed linemap_lookup to return NULL when the set
is NULL and this problem went away. I also experienced this SIGSEGV while
using gcc 4.3.3 on Haiku. I will try investigating more recent gcc versions
when I get a chance.

/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc/xgcc -v
Using built-in specs.
Target: i586-pc-haiku
Configured with: ./configure --prefix=/c/develop/gcc_4-4-1_java
--enable-languages=c,c++,java --disable-nls --disable-shared
--target=i586-pc-haiku
Thread model: single
gcc version 4.4.1 (GCC)

Haiku revision 34251

expected behavior: compile without errors
actual behavior: recurring SIGSEGV in linemap_lookup

/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc/xgcc -shared-libgcc
-B/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc -nostdinc++
-L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src
-L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src/.libs
-B/c/develop/gcc_4-4-1_java/i586-pc-haiku/bin/
-B/c/develop/gcc_4-4-1_java/i586-pc-haiku/lib/ -isystem
/c/develop/gcc_4-4-1_java/i586-pc-haiku/include -isystem
/c/develop/gcc_4-4-1_java/i586-pc-haiku/sys-include -x c++-header -O2 -g
-I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include/i586-pc-haiku
-I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include
-I/c/develop/gcc-4-4-1/libstdc++-v3/libsupc++ -O2 -g
/c/develop/gcc-4-4-1/libstdc++-v3/include/precompiled/stdtr1c++.h -o
i586-pc-haiku/bits/stdtr1c++.h.gch/O2g.gch

/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc/xgcc -shared-libgcc
-B/c/develop/gcc-4-4-1/host-i586-pc-haiku/gcc -nostdinc++
-L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src
-L/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/src/.libs
-B/c/develop/gcc_4-4-1_java/i586-pc-haiku/bin/
-B/c/develop/gcc_4-4-1_java/i586-pc-haiku/lib/ -isystem
/c/develop/gcc_4-4-1_java/i586-pc-haiku/include -isystem
/c/develop/gcc_4-4-1_java/i586-pc-haiku/sys-include -x c++-header -O2 -g
-I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include/i586-pc-haiku
-I/c/develop/gcc-4-4-1/i586-pc-haiku/libstdc++-v3/include
-I/c/develop/gcc-4-4-1/libstdc++-v3/libsupc++ -O2 -g
/c/develop/gcc-4-4-1/libstdc++-v3/include/precompiled/extc++.h -o
i586-pc-haiku/bits/extc++.h.gch/O2g.gch

Thread 405300 caused an exception: Segment violation

Program received signal SIGSEGV, Segmentation fault.
linemap_lookup (set=0x2c9d828, line=73) at ../.././libcpp/line-map.c:276
276 mn = set->cache;

linemap_lookup (set=0x2c9d828, line=73) at ../.././libcpp/line-map.c:276
276 mn = set->cache;
(gdb) bt
#0 linemap_lookup (set=0x2c9d828, line=73) at ../.././libcpp/line-map.c:276
#1 0x003fa1e9 in diagnostic_report_current_module (context=0xcd6520) at
../.././gcc/diagnostic.c:236
#2 0x002f64dd in cp_diagnostic_starter (context=0xcd6520,
diagnostic=0x7ffec714)
at ../.././gcc/cp/error.c:2374
#3 0x003f9989 in diagnostic_report_diagnostic (context=0xcd6520,
diagnostic=0x7ffec714)
at ../.././gcc/diagnostic.c:403
#4 0x003f9c4d in internal_error (gmsgid=0x95a5e7 "%s") at
../.././gcc/diagnostic.c:658
#5 0x0058aa1f in crash_signal (signo=Variable "signo" is not available.
) at ../.././gcc/toplev.c:601
#6 0x7ffec838 in ?? ()
#7 0x008c5907 in comp_hashnodes (px=0xb80cc483, py=0x39) at internal.h:672
#8 0x7ffec794 in ?? ()
#9 0xb80cc483 in ?? ()
#10 0x00000039 in ?? ()
#11 0x000000b9 in ?? ()
#12 0x24548d00 in ?? ()
#13 0xc363cd04 in ?? ()
#14 0x008c123b in linemap_lookup (set=0xdb9dbfdc, line=2147404600) at
../.././libcpp/line-map.c:272
#15 0x02c9d828 in ?? ()

--
Summary: SIGSEGV in linemap_lookup
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrewbachmann at yahoo dot com
GCC build triplet: i586-pc-haiku
GCC host triplet: i586-pc-haiku
GCC target triplet: i586-pc-haiku

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42474

[Bug debug/42395] [4.5 Regression] "error: definition in block 12 does not dominate use in block 19" with -O3 -g

2009-12-23T00:41:38Z

------- Comment #4 from jakub at gcc dot gnu dot org 2009-12-23 08:41 -------
While that change triggered it because at *.ifcvt it causes a difference:
<bb 7>:
i_41 = j_4(D);
- # DEBUG i => NULL
+ # DEBUG i => i_9
if (i_41 <= 4095)
goto <bb 3>;
it doesn't to appear to be the bug, i_9 definition dominates this use.
The problem is that *.vect changes the IL in a way that it no longer dominates
it.

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42395

[Bug debug/42454] [4.5 Regression] debug_ranges table contains empty range for unused .text section with -ffunction-sections

2009-12-23T00:11:46Z

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

2009-12-22T23:55:42Z

------- Comment #38 from irar at il dot ibm dot com 2009-12-23 07:55 -------
Created an attachment (id=19378)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19378&action=view)
Force alignment of reduce only

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

2009-12-22T23:54:55Z

------- Comment #37 from irar at il dot ibm dot com 2009-12-23 07:54 -------
Created an attachment (id=19377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19377&action=view)
Force alignment but don't vectorize

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug debug/42186] [4.5 Regression] [graphite] internal compiler error: verify_ssa failed

2009-12-22T23:54:30Z

------- Comment #9 from spop at gcc dot gnu dot org 2009-12-23 07:54 -------
Fixed.

--

spop at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

2009-12-22T23:54:08Z

------- Comment #36 from irar at il dot ibm dot com 2009-12-23 07:54 -------
Thanks!
So, it is alignment of the vectorized arrays. I'd like to do two more checks:
1. Just force alignment of the two arrays (temp and reduce) and do not
vectorize.
2. Force alignment of reduce only (and vectorize both loops).
I am attaching the hacks. Could you please chesk this as well?

Thanks,
Ira

--

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/42393] [4.5 Regression] [graphite] internal compiler error: in check_loop_closed_ssa_use

2009-12-22T23:53:59Z

------- Comment #5 from spop at gcc dot gnu dot org 2009-12-23 07:53 -------
Fixed.

--

spop at gcc dot gnu dot org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42393