[Bug java/21245] New: gcjh creates invalid/empty header files

While trying to adapt a patch from GNU classpath to libgcj I found that gcjh was failing to build a CNI header from a class file. I accidently deleted my terminal and lost the command output. So I tried again and the bug seemed to have vanished. After some investigation I found the following:

[Bug libstdc++/21244] Confusion in template instantiation

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 07:13 --- The first example is invalid is a dup of bug 19404. Now the second example looks to be a bug in libstdc++. -- What|Removed |Added -

[Bug java/21245] gcjh creates invalid/empty header files

--- Additional Comments From konqueror at gmx dot de 2005-04-27 07:17 --- Created an attachment (id=8749) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8749&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21245

[Bug c++/21246] New: Compiler fails when using and incrementing a variable i: f(i,++i) equivalent to f(i+1,i+1); ++i

The next code, should show int the screen "a:2 b:3"; but shows "a:3 b:3". I have tested it into several versions from 3.3 to 4.0. Always the same result. void foo(int a,int b) { std::cout<<"a:"

[Bug c++/21246] Compiler fails when using and incrementing a variable i: f(i,++i) equivalent to f(i+1,i+1); ++i

-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21246

[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible

-- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21238

[Bug libstdc++/21244] Confusion in template instantiation

--- Additional Comments From pcarlini at suse dot de 2005-04-27 08:54 --- The second example seems to me also a duplicate of 19404. This is a reduced testcase: class Foo { }; template void operator/(const Foo&, T); enum { _S_word_bit = 1 }; class vector_bool { void _M_allocate() { (_S_w

[Bug middle-end/20794] [4.0/4.1 Regression] Arrays and pointer arithmetic on __attribute ((aligned)) types permitted

--- Additional Comments From dorit at il dot ibm dot com 2005-04-27 08:59 --- (In reply to comment #18) > I submitted a patch, http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html, > but as the mail says it results in a lot of regressions in the compat and > vector tests. I'll see wh

[Bug libstdc++/21244] Confusion in template instantiation

--- Additional Comments From dominik dot strasser at infineon dot com 2005-04-27 09:07 --- (In reply to comment #4) > The second example seems to me also a duplicate of 19404. This is a reduced > testcase: > > class Foo { }; > template void operator/(const Foo&, T); > enum { _S_word_bit

[Bug libstdc++/21244] Confusion in template instantiation

--- Additional Comments From dominik dot strasser at infineon dot com 2005-04-27 09:09 --- Created an attachment (id=8750) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8750&action=view) Use const static member instead of enum -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=212

[Bug c++/21244] Confusion in template instantiation

--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:15 --- No, we don't want to change the implementation of the library in case of user error. Really, this is a duplicate of 19404. *** This bug has been marked as a duplicate of 19404 *** -- What|Removed

[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code

--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:15 --- *** Bug 21244 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/21244] Confusion in template instantiation

--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:24 --- On second thought, maybe we can safely change the enum to not be anonymous... -- What|Removed |Added

[Bug libstdc++/21244] Confusion in template instantiation

-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21244

[Bug libstdc++/21244] Confusion in template instantiation

--- Additional Comments From dominik dot strasser at infineon dot com 2005-04-27 09:28 --- (In reply to comment #8) > On second thought, maybe we can safely change the enum to not be anonymous... I think so, too as I can't see any user error in the second example. -- http://gcc.gnu.

[Bug libstdc++/21244] Confusion in template instantiation

--- Additional Comments From pcarlini at suse dot de 2005-04-27 09:37 --- Yes, you are right, but I don't want to fiddle too much with that constant, in particular risking to change its size (the standard doesn't guarantee that the underlying type of that anonymous enum is int), seems sa

[Bug ada/21247] New: Cross-building gnat-4.0.0 requires native gnat-4.0.0

Bootstrapping a gcc-4.0.0/gnat cross-toolchain on FC3 using the native FC3-gcc-3.4.3-22.fc3 toolchain fails with: # ../gcc-4.0.0/configure --target=i386-rtems4.7 --enable-languages=c,ada --disable-multilib --prefix=/opt/rtems-4.7 --with-gnu-as --with-gnu-ld --with-newlib --with-system-zlib --disab

[Bug libfortran/20436] [4.0 only] using nested reshape functions gives runtime error

-- What|Removed |Added Known to fail||4.0.0 Known to work||4.1.0 Summary|usring nested reshape |[4

[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED

[Bug c++/21248] New: internal compiler error

Building kdelibs 3.4 with gcc 4.0.0 on i686-pc-linux-gnu. Failed with "internal compiler error" on kimgio/exr.cpp. Command line as follows: /bin/sh ../libtool --silent --mode=compile --tag=CXX g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../kdecore -I../kio/kssl -I../kio -I../dcop -I../libltdl -

[Bug c++/21248] internal compiler error

--- Additional Comments From pete at flooble dot net 2005-04-27 10:39 --- Created an attachment (id=8751) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8751&action=view) The command line generating the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248

[Bug c++/21248] internal compiler error

--- Additional Comments From pete at flooble dot net 2005-04-27 10:39 --- Created an attachment (id=8752) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8752&action=view) Output as generated from command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21248

[Bug c++/21248] internal compiler error

--- Additional Comments From pete at flooble dot net 2005-04-27 10:46 --- Created an attachment (id=8753) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8753&action=view) preprocessed file (gzipped due to size - *.ii.gz) as required by bug-submit guidelines Note: gzipped due to unc

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW

[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible

--- Additional Comments From bduerner at gmx dot de 2005-04-27 11:33 --- This testcase gives the following error: numpunct_test.cpp:106: instantiated from here /usr/lib/gcc/i586-ark-linux/3.4.4/../../../../include/c++/3.4.4/bits/locale_facets.tcc:435: error: no type named `__cache_

[Bug c++/21246] Compiler fails when using and incrementing a variable i: f(i,++i) equivalent to f(i+1,i+1); ++i

--- Additional Comments From giovannibajo at libero dot it 2005-04-27 11:40 --- This is not a bug, the order of evaluation is unspecified. Read about this here: http://gcc.gnu.org/bugs.html section "Increment/decrement operator (++/--) not working as expected" *** This bug has been mark

[Bug c/11751] wrong evaluation order of an expression

--- Additional Comments From giovannibajo at libero dot it 2005-04-27 11:40 --- *** Bug 21246 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/21240] Deadlock (pthread) in signal handler

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 12:06 --- Do you have a testcase? On second thought pthreads and mutex lockes and signals are out of the scope of a compiler, If this is a bug, this is a glibc bug but I really doubt it. -- What|Rem

[Bug ada/21241] ACATS ICE verify_flow_info failed cxg1002 cxg1003 cxg2006 cxg2007 cxg2018 cxg2019 cxg2020

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 12:09 --- This ICE is caused by more checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21241

[Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible

--- Additional Comments From pcarlini at suse dot de 2005-04-27 12:12 --- Thanks for the testcase. The issue is subtle and the typedef is only the tip of the iceberg: num_get (involved in >>(int)) uses the caching facilities provided by the primary numpunct, which a specialization simply

[Bug inline-asm/21249] New: incorrect code generation for rdtsc on x86_64

The following inline assembly is generating correct code on x86 but not on x86_64 (Counter is a uint64_t): asm volatile ( "rdtsc" : "=A" (Counter) ); -- Summary: incorrect code generation for rdtsc on x86_64 Product: gcc Version: 4.0.0 Status: UNCONFI

[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64

--- Additional Comments From tfautre at pandora dot be 2005-04-27 13:08 --- Created an attachment (id=8754) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8754&action=view) Small test program that exibits the problem. The problem becomes more obvious when the program is compiled wi

[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:11 --- What do you mean, it is generating wrong code? Actually you are using inline-asm wrong, try the following instead: #define rdtsc(low,high) \ __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high)) This com

[Bug c++/21248] internal compiler error

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:25 --- I cannot reproduce this on the mainline or "4.0.0 20050410", I will build a 4.0.0 release later today, this might also be already fixed on the 4.0 branch too. -- What|Removed

[Bug preprocessor/21250] New: line number 0 for causes GAS to complain

powerpc64-linux-gcc -c -o any-file.o any-file.S results in any-file.S: Assembler messages: any-file.S:1: Warning: line numbers must be positive; line number 0 rejected as the pre-processed file looks like # 1 "any-file.S" # 0 "" # 1 "" # 1 "any-file.S" ... This regression is cau

[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64

--- Additional Comments From tfautre at pandora dot be 2005-04-27 13:30 --- Thanks for the code, it's working. The inline rdtsc code was from an IBM article; and after reading the GCC doc on =A, I must admit I was expecting it to work on x86_64 too. "ASpecifies the `a' or `d' regis

[Bug inline-asm/21249] incorrect code generation for rdtsc on x86_64

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:32 --- (In reply to comment #3) > If =A is for using edx:eax in 32 bits mode, what is it doing exactly in 64 > bits > then? rdx:rax? Just rax. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21249

[Bug preprocessor/21250] line number 0 for causes GAS to complain

-- What|Removed |Added CC||bothner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/sh

[Bug c++/21248] internal compiler error

--- Additional Comments From rguenth at gcc dot gnu dot org 2005-04-27 13:35 --- ICE in gcc/expr.c:3087 emit_move_insn is called with y == NULL. #0 emit_move_insn (x=0x42dbc170, y=0x0) at /net/alwazn/home/rguenth/src/gcc/gcc4.0/gcc/expr.c:3087 #1 0x081d2ddc in convert_modes (mode

[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target

--- Additional Comments From gdr at integrable-solutions dot net 2005-04-27 13:37 --- Subject: Re: [3.3 regression] ICE in in gen_split_1204 on i686-pc-linux-gnu target "rgrosseboerger at dspace dot de" <[EMAIL PROTECTED]> writes: | The proposed patch fixes the reduced testcase and m

[Bug rtl-optimization/20211] autoincrement generation is poor

--- Additional Comments From amylaar at gcc dot gnu dot org 2005-04-27 13:37 --- (In reply to comment #4) > There are both primary and secondary platforms among the AUTO_INC_DEC > targets. > So it is probably good to gain some wider test coverage about the compile- > time/run-time impa

[Bug c++/21166] g++ gives error on reference to packed structure elements

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|UNCONFIRMED

[Bug rtl-optimization/20211] autoincrement generation is poor

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 13:41 --- (In reply to comment #8) > (In reply to comment #4) > > There are both primary and secondary platforms among the AUTO_INC_DEC > > targets. > > So it is probably good to gain some wider test coverage about

[Bug preprocessor/21250] [4.1 Regression] line number 0 for causes GAS to complain

-- What|Removed |Added Summary|line number 0 for |[4.1 Regression] line number |causes GAS to complain |0 for causes GAS |

[Bug c++/21251] New: Placement into shared memory

I would like to use placement to instantiate a C++ object into a shared memory segment and access that object from a second process. When I test with an integer, the integer is accessible from the second process. But when I instantiate a C++ class object, it seems a memory pointer, which

Re: gcc 4.0.0, doc/gcc.1 not there

Maybe there is something funny about your environment, like an auto-mounted NFS src directory which got auto-unmounted during the build? No, it's all local. However ... it must have been some craziness left over from a previous build, even though I did make distclean in srcdir and remove

[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target

--- Additional Comments From rgrosseboerger at dspace dot de 2005-04-27 14:00 --- Subject: RE: [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target > -Original Message- > From: gdr at integrable-solutions dot net > > Did you apply the patch? > > -- Gaby No, Rog

[Bug c++/21251] Placement into shared memory

-- What|Removed |Added GCC build triplet||i686-pc-linux-gnu GCC host triplet||i686-pc-linux-gnu GCC target triplet|

[Bug c++/21251] Placement into shared memory

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:03 --- Are you talking about the vtable being at two different locations, well there is no way since the struct is a non-POD which means it cannot do many things with. If you want to share data, try with a POD i

[Bug java/21245] gcjh creates invalid/empty header files

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:18 --- Confirmed, I thought I saw something about this before, maybe it was on IRC or on the mailing lists. -- What|Removed |Added -

[Bug tree-optimization/21171] [4.0/4.1 Regression] IV OPTS removes does not create a new VOPs for constant values

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 14:28 --- Subject: Bug 21171 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 14:28:12 Modified files: gcc: ChangeLog tree-ssa-loop-ivopts.c

[Bug c++/21252] New: ICE: (in c_parse_error, at c-common.c:5885)

I got the following ice: /usr/local/bin/g++ -save-temps -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -Wall -O9 -march=athlon -MT atom_co64.lo -MD -MP -MF .deps/atom_co64.Tpo -c atom_co64.cpp -fPIC -DPIC In file included from mp4common.h:36, from atom_co64.cpp:22: mp4property.h

[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)

-- What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252

[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)

--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-27 14:35 --- Created an attachment (id=8755) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8755&action=view) This preprocessed file causes an ice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252

[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:42 --- Can you please re-attach the preprocessed source and not encode the file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21252

[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)

--- Additional Comments From ltg at zes dot uni-bremen dot de 2005-04-27 14:46 --- Created an attachment (id=8756) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8756&action=view) This preprocessed file causes an ice. -- What|Removed |Added

[Bug c++/21252] ICE: (in c_parse_error, at c-common.c:5885)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:54 --- On the mainline (and I think 4.0 also), we get: mp4property.h:61: error: invalid pure specifier (only `= 0' is allowed) before ';' token mp4property.h:77: error: invalid pure specifier (only `= 0' is allowe

[Bug c++/17401] [3.4/4.0 Regression] ICE with invalid pure specifier

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 14:54 --- *** Bug 21252 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/21251] Placement into shared memory

--- Additional Comments From mronell at alumni dot upenn dot edu 2005-04-27 14:56 --- I believe that the pointer points to a component within the vtable, but I do not want to jump to that conclusion. When the object is instantiated in shared memory, the first element seems to be a poin

[Bug c++/21251] Placement into shared memory

--- Additional Comments From pcarlini at suse dot de 2005-04-27 15:01 --- (POD ("Plain Old Data") is a technical term, defined in the standard, basically something you can copy bit by bit, via memcpy) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21251

[Bug fortran/21177] wrong code with NULL()

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 15:38 --- Subject: Bug 21177 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 15:37:55 Modified files: gcc/fortran: ChangeLog interface.c gcc/te

[Bug fortran/21177] wrong code with NULL()

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 15:43 --- Subject: Bug 21177 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 15:42:54 Modified files: gcc/fortran: Change

[Bug fortran/21177] wrong code with NULL()

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-27 15:44 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 15:59 --- Subject: Bug 21244 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 15:59:09 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/inclu

[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 16:03 --- Subject: Bug 21244 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 16:02:28 Modified files: libstdc++-v3 : Change

[Bug libstdc++/21244] [4.0/4.1 Regression] Vector anonymous enum problem

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 16:03 --- Subject: Bug 21244 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 16:02:28 Modified files: libstdc++-v3 : Change

[Bug fortran/21104] Segmentation fault on correct code

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-27 16:03 --- This is a bug for the following reasons: A] From the standard, we have: 12.3.1.1 Explicit interface A procedure other than a statement function shall have an explicit interface if .. (2) The procedure ha

[Bug fortran/21253] New: Bounds Check

Compiled with the bounds checker on and program terminated early with the following message: "Fortran runtime error: Array reference out of bounds" 1. Need a clue of some kind, e.g., line number, array identity, etc. 2. G77 does not indicate an out of bounds. -- Summary: Bounds Check

[Bug tree-optimization/21254] New: Incorrect code with -funroll-loops for multiple targets with same code

The following C++, when compiled with g++-4.0.0, produces incorrect code when compiled with -O1 -funroll-loops on both sparc-sun-solaris2.8 and i686-pc-linux- gnu. This is a bare-bones simplification of real code from an application using the Boost.Spirit library. If compiled without -funroll-

[Bug c++/21232] [3.4 Regression] g++ segfaults

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-27 16:15 --- This works for me (3.4.0, 3.4.1, 3.4.3), too. I even downloaded Mandrake's versions (3.4.1 and 3.4.3). No problem. Can you reproduce the bug with the preprocessed file? Are you sure that this is not a hard

[Bug fortran/21253] Bounds Check

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 17:06 --- For part 2: might be PR 19777, do you have a simple testcase which shows the problem. For part 1, I will file a seperate bug (later today) about the enhancing the error message -- What|Re

[Bug rtl-optimization/21254] Incorrect code with -funroll-loops for multiple targets with same code

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 17:44 --- The tree level does not change with -funroll-loops. -- What|Removed |Added Componen

[Bug fortran/21253] Bounds Check

--- Additional Comments From blime at cox dot net 2005-04-27 17:58 --- Subject: Re: Bounds Check Sorry, I do not have a simple test case, but might be able to construct one if part 1 is solved. blime pinskia at gcc dot gnu dot org wrote: >--- Additional Comments From pinskia at

[Bug libfortran/20950] [4.0 only] segfault in INQUIRE asking for SEQUENTIAL status

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 18:15 --- Subject: Bug 20950 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 18:15:39 Modified files: gcc/testsuite : Change

[Bug libfortran/20950] [4.0 only] segfault in INQUIRE asking for SEQUENTIAL status

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-27 18:16 --- Patch commited to 4.0. Fixed. -- What|Removed |Added Status|NEW

[Bug target/21255] New: %R and %S are not safe to use from asms

%R and %S should consider the special endianness of floaitng point registers, and when they find an unexpected argument, they should emit an error rather than abort. -- Summary: %R and %S are not safe to use from asms Product: gcc Version: 4.1.0 Status

[Bug fortran/21256] New: Illegal use of assumed-sized array in an array expression

Gfortran is not checking if an assumed sized array is used correctly in an array expression. Gfortran compiles the following without an error or warning subroutine e(a) real, intent(out) :: a(*) a = 1.e0 end subroutine NAG's compiler issues kargl[210] f95 -c e.f90 Error: e.f90, line 3: Inv

[Bug fortran/21257] New: Duplicate use of construct name

Consider the following program: program f integer i loop: do i = 1, 5 print *, i end do loop loop: do i = 1, 5 print *, i end do loop end program f Gfortran compiles the program and it executes both loops. NAG's compiler claim

[Bug libstdc++/21172] potential integer overflow error in STL heap functions

--- Additional Comments From pete_a90 at yahoo dot com 2005-04-27 19:09 --- I know there are no practical risks to this (heap isn't that popular and it's practically impossible to allocate an array that large) but it won't work if the user made a custom iterator with unsigned char as t

[Bug libstdc++/21172] potential integer overflow error in STL heap functions

--- Additional Comments From pcarlini at suse dot de 2005-04-27 19:26 --- Please, either provide an analysis that the problem really happens, *given the specific algorithm*, or provide a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21172

[Bug tree-optimization/21258] New: Teach VRP to pick up a constant from case label.

Consider: void bar (void); void foo (int a) { switch (a) { case 4: if (a >= 3 && a <= 5) bar (); } } Note that we could remove the "if" statement, VRP does not catch this. I think Diego already knows about this, but I think it's worth a PR so that we don't

[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.

--- Additional Comments From dnovillo at redhat dot com 2005-04-27 19:43 --- Subject: Re: New: Teach VRP to pick up a constant from case label. On Wed, Apr 27, 2005 at 07:38:04PM -, kazu at cs dot umass dot edu wrote: > I think Diego already knows about this, but I think it's wort

[Bug middle-end/20794] [4.0/4.1 Regression] Arrays and pointer arithmetic on __attribute ((aligned)) types permitted

--- Additional Comments From sje at cup dot hp dot com 2005-04-27 19:44 --- It looks like most of the compat tests have been fixed but I still get two failures. They are tmpdir-gcc.dg-struct-layout-1/t002 and tmpdir-gcc.dg-struct-layout-1/t027. I cut down t002 and wound up with void *

g++ compiling code that is wrong.

Hello. I dont know if I am to write here, but I think I found a bug that I know is not related to my hardware or my system. Problem is that I don't know how to report it or if it allready been reported(Kind of hard to search for a bug when you dont know how to describe it.). Backstory : I am a

[Bug c++/11285] GCC 3.3 C++ for Sparc Solaris assumes system header files are C.

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 21:03 --- Subject: Bug 11285 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 21:03:00 Modified files: libjava: ChangeLog libjava/gnu/java/n

Re: g++ compiling code that is wrong.

> > Hello. > > I dont know if I am to write here, but I think I found a bug that I know > is not related to my hardware or my system. Problem is that I don't know > how to report it or if it allready been reported(Kind of hard to search > for a bug when you dont know how to describe it.). > >

[Bug c/21159] [4.0/4.1 Regression] "no effect" warning despite cast to void*

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 21:41 --- Subject: Bug 21159 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-27 21:41:15 Modified files: gcc: ChangeLog c-typeck.c gcc/tes

[Bug c/21159] [4.0/4.1 Regression] "no effect" warning despite cast to void*

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-27 21:47 --- Subject: Bug 21159 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-27 21:47:31 Modified files: gcc: Change

[Bug c/21159] [4.0/4.1 Regression] "no effect" warning despite cast to void*

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-27 21:49 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug other/346] gcc install clobbers files that it shouldn't touch

--- Additional Comments From steven at gcc dot gnu dot org 2005-04-27 23:54 --- Can someone comment on the status of this bug? -- What|Removed |Added CC

[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched

--- Additional Comments From janis at gcc dot gnu dot org 2005-04-28 00:07 --- There are other SPEC CPU2000 comparison failures on powerpc64-linux with "-m64 -O2 -fmodulo-sched" that resist attempts to minimize the testcases. apsi has been failing since:

[Bug libstdc++/21172] potential integer overflow error in STL heap functions

--- Additional Comments From pcarlini at suse dot de 2005-04-28 00:08 --- Ok, let's reopen the PR as "enhancement": actually, it's easy to produce a testcase that leads to __secondChild growing beyond __len and the latter can be equal to the biggest representable _Distance. --

[Bug libstdc++/21172] potential integer overflow error in STL heap functions

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-

[Bug tree-optimization/21258] Teach VRP to pick up a constant from case label.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 00:36 --- Confirmed, in a way PR 20514 is related. -- What|Removed |Added Status|UNCONFIRM

[Bug c++/19614] Excessive memory consumption with a class with large (200) virtual (pure?) function and derived classes

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 00:52 --- On the mainline, (on x86) we use about 300 megs which is an improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614

[Bug rtl-optimization/21144] [4.0/4.1 regression] Apparent infinite loop in reload

--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-28 01:15 --- Confirmed. The patch is OK for both mainline and the gcc-4.0 branch, assuming it passes the regtest, in case anyone was waiting for approval. -- What|Removed |Added -

[Bug c++/21251] Placement into shared memory

--- Additional Comments From mronell at alumni dot upenn dot edu 2005-04-28 01:32 --- "Plain Old Data" unfortunately is not a good solution in my case. I maintain http://allocator.sourceforge.net which provides an open-source shared memory allocator for the C++ Standard Template Library

[Bug libstdc++/21251] Placement into shared memory

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 01:44 --- (In reply to comment #4) > However, as before, my approach depends on being able to place and share C++ > objects through shared memory. Its that still possible? > > Am I missing some esoteric compiler fl

[Bug middle-end/21259] New: ICE on assigning the pointer to a array with __attribute__ aligned

Compiler gets a segfault if the following code is tried on gcc 3.4.3 the same works fine on gcc4.0 and mainline static void foo ( int arg){ unsigned long long int __attribute__ ((aligned (4))) aligned_array[arg]; unsigned long long int *bak = aligned_array; } -- Summary: ICE on as

[Bug c++/13051] problem with static member and ?: operator

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-28 02:02 --- reopening to -- What|Removed |Added Status|RESOLVED|UNC

  1   2   >