[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-10 04:01 --- Subject: Bug 20126 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-10 04:00:54 Modified files: gcc: ChangeLog loop.c recog.c recog.h

[Bug libfortran/19872] closed and re-opened file not overwriten

--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-10 03:52 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug libfortran/19872] closed and re-opened file not overwriten

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-10 03:43 --- Subject: Bug 19872 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-10 03:43:09 Modified files: libgfortran: ChangeLog libgfortran/io : t

[Bug tree-optimization/20920] [4.1 Regression] ICE with eh and VRP

--- Additional Comments From kazu at cs dot umass dot edu 2005-04-10 03:34 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01050.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20920

Fix tree-optimization/20920

Sigh. Another SSA_NAME flowing through EH edges getting in the way. I'm starting to think that it would be much better to make these SSA_NAME_OCCURS_IN_ABNORMAL_PHI into virtuals. We would avoid all the monkeying around that optimizers have to do. It would involve a bit of trickery because we o

[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry

--- Additional Comments From roger at eyesopen dot com 2005-04-10 03:18 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On 9 Apr 2005, Alexandre Oliva wrote: > On Apr 8, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > > > ++ /* If there isn't a volat

[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry

--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-10 02:43 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 8, 2005, Roger Sayle <[EMAIL PROTECTED]> wrote: > ++ /* If there isn't a volatile MEM, there's nothing we can do. */

[Bug target/20375] [4.0/4.1 Regression] C++ ICE in assign_parm_find_entry_rtl

--- Additional Comments From rth at gcc dot gnu dot org 2005-04-09 23:44 --- Nathan, this patch is causing problems on Alpha. In particular, we now run assign_parms_setup_varargs before processing the last named argument (union U in this test case). Which yields an abort in assign_parm

[Bug fortran/20925] "Possible frontend bug: array constructor not expanded"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 22:29 --- Hmm, /* Problems occur when we get something like integer :: a(lots) = (/(i, i=1,lots)/) */ /* TODO: Unexpanded array initializers. */ internal_er

[Bug fortran/20925] "Possible frontend bug: array constructor not expanded"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 22:27 --- Note this one and PR 20923, I found with the benchmark here: which is about f95 features. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

[Bug fortran/20925] New: "Possible frontend bug: array constructor not expanded"

The following code ICEs: program sel implicit none integer,parameter :: n=1000 integer:: cste, i integer, dimension(n) :: vect=(/ (-i, i=1,n) /) cste = vect(1) end t.f90: In function 'MAIN__': t.f90:6: internal compiler error: Possi

[Bug target/20924] New: [4.0/4.1 regression] inline float divide does not set correct fpu status flags

Neither the min-latency nor the max-throughput inline float divide set the Invalid Operation flag in the fpsr when calculating 0/0. $ cat divdf3.c #include #include #include double divdf3 (double a, double b) { return a / b; } int main (int argc, char **argv) { if (argc !

[Bug fortran/20923] New: Compile time is high for the following code

While I was looking for an ICE, I noticed that the following code causes gfortran to take a long time (almost a minute, this is without optimizations) program sel implicit none integer,parameter :: n=1000 integer:: i,j real,dimension(n*n) ::

[Bug libfortran/19014] print *,maxloc(array) segfaults

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 21:38 --- Subject: Bug 19014 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-09 21:38:47 Modified files: libgfortran: ChangeLog gcc/testsuite : C

[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a>0)

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 21:38 --- Subject: Bug 19106 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-09 21:38:47 Modified files: libgfortran: ChangeLog gcc/testsuite : C

[Bug tree-optimization/20922] New: missed always false conditional

The following function should just "return 1": int f(int i) { int i1 = i -2; if (i1 > i) return 0; return 1; } We miss this on the tree level, I found this while look into the following fortran code: SUBROUTINE d ( a, b,n) IMPLICIT NONE INTEGER :: n REAL,DIMENSION(n) :: a REAL,DIMENSION(

[Bug tree-optimization/19126] Missed IV optimization (redundant instruction in loop)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 20:45 --- This shows up a lot in fortran code like the following (and yes I copied this from some where and reduced it): SUBROUTINE d ( a, b, ndim ) IMPLICIT NONE INTEGER, INTENT(IN) :: ndim REAL,DIMENSION(ndim,ndim

[Bug libfortran/20744] size= isn't implemented correctly

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-09 20:38 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-04/msg00100.html -- What|Removed |Added

[Bug libfortran/19014] print *,maxloc(array) segfaults

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-09 20:33 --- Patch: http://gcc.gnu.org/ml/fortran/2005-04/msg00214.html -- What|Removed |Added

[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a>0)

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-09 20:32 --- Updated patch: http://gcc.gnu.org/ml/fortran/2005-04/msg00214.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106

[Bug ada/20921] Unable to access components of task access constraint

--- Additional Comments From simon at pushface dot org 2005-04-09 20:27 --- Created an attachment (id=8574) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8574&action=view) Reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20921

[Bug ada/20921] New: Unable to access components of task access constraint

This type Event_Queue_Base (Start_Started : Boolean; Priority : System.Priority; Storage_Size : Positive) is tagged private; task type Dispatcher (The_Queue : access Event_Queue_Base'Class) is pragma Priority (The_Queue.Priority)

[Bug fortran/20853] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:43 --- Confirmed ("Array bounds information needed, but not available for assumed-size array", says Intel). -- What|Removed |Added

[Bug fortran/20852] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:42 --- Confirmed. Intel says: "A CHARACTER function name must not be declared with an asterisk type-param-value (i.e., (LEN=*)) if the function is recursive." -- What|Removed

[Bug fortran/20851] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:41 --- Confirmed. As Intel says (rather long message): "In an elemental subprogram, a dummy argument, or a subobject thereof, shall not appear in a specification-expr except as the argument to certain inquiry fun

[Bug libfortran/20163] gfortran - error opening direct access file

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 19:40 --- Subject: Bug 20163 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-09 19:40:48 Modified files: gcc/testsuite : ChangeLog Added files: gcc/t

[Bug fortran/20850] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:39 --- Confirmed. Right now, gfortran encounters an internal error: --- In file pr20850.f90:4 END 1 Internal Error at (1): find_array_spec(): Missing spec ---

[Bug libfortran/20163] gfortran - error opening direct access file

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 19:37 --- Subject: Bug 20163 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-09 19:37:14 Modified files: libgfortran: ChangeLog libgfortran/runtim

[Bug tree-optimization/20920] [4.1 Regression] ICE with eh and VRP

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 19:34 --- Adding build keyword as this is causing the powerpc-darwin build to fail. -- What|Removed |Added -

[Bug tree-optimization/20920] [4.1 Regression] ICE with eh and VRP

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 19:33 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug tree-optimization/20920] New: ICE

Consider: void f(int) __attribute__((__noreturn__)); int d(const char *); char * j (); char * foo (int x) { char *path = __null; try { path = j (); if (path != __null) if (d (path) != 0) f (127); f (127); } catch (...) { } return path; } With

[Bug libstdc++/19322] std::isnan<>() is broken on FreeBSD

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 19:32 --- *** Bug 20919 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug libstdc++/20919] Floating point functions in cmath (like isinf, isnan) recurse and cause stack overflow.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 19:32 --- *** This bug has been marked as a duplicate of 19322 *** -- What|Removed |Added

[Bug libstdc++/20919] Floating point functions in cmath (like isinf, isnan) recurse and cause stack overflow.

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

[Bug fortran/20849] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:29 --- Confirmed. This one should be an error in all cases (even without -pedantic). -- What|Removed |Added ---

[Bug c++/20919] New: Floating point functions in cmath (like isinf, isnan) recurse and cause stack overflow.

from 458 template 459 int 460 __capture_isnan(_Tp __f) { return isnan(__f); } 532 template 533 int 534 isnan(_Tp __f) { return __capture_isnan(__f); } Now, on line 460, the "isnan" call refers to a macro. However, that macro in turn expands

[Bug fortran/20848] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:28 --- Confirmed, I think this should be an error in all cases. -- What|Removed |Added

[Bug fortran/20847] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:26 --- Confirmed. Error message from Intel: "A COMMON block data object may not have the SAVE attribute." -- What|Removed |Added --

[Bug fortran/20846] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:25 --- Confirmed, we shouldn't be able to specify a FILE and a UNIT in the same INQUIRE statement. Perhaps this should even be an error in any case (that is, without -pedantic and -std=f95). -- What

[Bug fortran/20845] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:19 --- OK, it took me time to see what was missing here, but the g95 error message is rather clear: "Module variable 'x' at (1) with default components must have the SAVE attribute" Confirmed and marked as min

[Bug fortran/20844] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:17 --- Right now we are issuing a "Fortran runtime error: Missing format for FORMATTED data transfer". Is that enough? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20844

[Bug fortran/20843] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:16 --- This one is right now segfaulting. Confirmed. -- What|Removed |Added Status|UN

[Bug fortran/20842] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:15 --- Confirmed and marked as minor. g95 error for that one is: "END tag at (1) is not compatible with output" -- What|Removed |Added ---

[Bug fortran/20840] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:13 --- *** Bug 20841 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20840

[Bug fortran/20841] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:13 --- *** This bug has been marked as a duplicate of 20840 *** -- What|Removed |Added

[Bug fortran/20840] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:11 --- Confirmed (for example, g95 issues "Cannot have vector subscripts with an internal file") and marked as minor. -- What|Removed |Added --

[Bug fortran/20839] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:08 --- Confirmed and marked as minor. -- What|Removed |Added Severity|normal

[Bug fortran/20838] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:05 --- On i686-linux, I get: pr20838.f90: In function MAIN__: pr20838.f90:4: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:3606 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug fortran/20837] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:01 --- Error message from Intel: "This attribute is permitted only within a MODULE". Confirmed and marked as minor. -- What|Removed |Added ---

[Bug fortran/20836] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 19:00 --- Confirmed and marked as minor. For info, Intel compiler says: "Component INFO of PUBLIC type ALL_TYPE cannot have a type that is PRIVATE" -- What|Removed |Added --

[Bug fortran/13257] [4.0 only] Error instead of warning for missing comma in format string

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 18:46 --- Fixed on the mainline waiting for 4.0 branch to reopen to apply there. -- What|Removed |Added

[Bug fortran/13257] Error instead of warning for missing comma in format string

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 18:44 --- Subject: Bug 13257 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-09 18:44:07 Modified files: gcc/testsuite : ChangeLog libgfortran: C

[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549

--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09 18:26 --- Here's a reduced test case: extern void abort (void); extern void **alloc (void); void *test (void) { void **p = alloc (); if (!p) abort (); __builtin_set_thread_pointer (p); return *p; } It wou

[Bug fortran/20835] error needed

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-09 17:49 --- Confirmed and marked as minor. -- What|Removed |Added Severity|normal

[Bug target/20795] ICE in assign_parms

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 17:15 --- Subject: Bug 20795 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-09 17:15:34 Modified files: gcc: Change

[Bug target/20795] ICE in assign_parms

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-09 17:10 --- Subject: Bug 20795 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-09 17:09:49 Modified files: gcc: ChangeLog gcc/testsuite : C

[Bug c++/20918] unwarranted warning "control reaches end of non-void-function"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 17:01 --- of bug 20624. *** This bug has been marked as a duplicate of 20624 *** -- What|Removed |Added ---

[Bug c++/20624] [4.0/4.1 Regression] wrong "control reaches end of non-void function" warning

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 17:01 --- *** Bug 20918 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/20918] unwarranted warning "control reaches end of non-void-function"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 17:00 --- This is not a dup of bug 20681 but ... -- What|Removed |Added Status|RESOLVED

[Bug c++/20681] [4.0/4.1 Regression] wrong "control reaches end of non-void function" warning

--- Additional Comments From fsm at robots dot ox dot ac dot uk 2005-04-09 16:58 --- *** Bug 20918 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c++/20918] unwarranted warning "control reaches end of non-void-function"

--- Additional Comments From fsm at robots dot ox dot ac dot uk 2005-04-09 16:58 --- *** This bug has been marked as a duplicate of 20681 *** -- What|Removed |Added

[Bug c++/20918] New: unwarranted warning "control reaches end of non-void-function"

gured with: ../gcc/configure --prefix=/lvm/fred/gcc/4.0/install-20050409 --enable-static --enable-shared --enable-languages=c,c++,f95 --with-mpfr=/lvm/fred/pkg/gmp/install Thread model: posix gcc version 4.0.0 20050409 (prerelease) # 4.1 version: $ g++ -v Using built-in specs. Target: i686-pc-linux

[Bug middle-end/20736] [4.0/4.1 Regression] -fprofile-generate crashes on numerous occasions

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 16:27 --- Hmm, maybe this is only reproducable on the 4.0 branch. -- What|Removed |Added Known to

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From moritz at bunkus dot org 2005-04-09 16:25 --- Ups! Thanks for the quick help and sorry for not reading the man page thoroughly enough before posting this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20916

[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549

--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09 16:16 --- D'oh. Ignore my previous post; I forgot that the 4.0 branch now defaults to checking disabled. I can indeed reproduce the problem, an am looking into it now ... -- http://gcc.gnu.org/bugzilla/show_bu

[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549

--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-09 16:09 --- I cannot reproduce the problem on today's GCC 4.0.0 version ... What is different for you? Do you have any patches on top? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20917

[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 14:41 --- It is ICE on: gcc_assert (deaths_in_region[rgn] == count_or_remove_death_notes (blocks, 0)); -- What|Removed |Added --

[Bug middle-end/20917] ICE in schedule_insns at sched-rg.c:2549

--- Additional Comments From aj at gcc dot gnu dot org 2005-04-09 14:40 --- Created an attachment (id=8571) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8571&action=view) Preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20917

[Bug middle-end/20917] New: ICE in schedule_insns at sched-rg.c:2549

Compiling GLIBC on s390-linux-gnu I get the following ICE: gcc pthread.c -c -std=gnu99 -DNDEBUG=1 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fmessage-length=0 -g -fpic -D__NO_WEAK_PTHREAD_ALIASES -DHAVE_Z_NODELETE -DIS_IN_linuxthreads=1 -I../include -I. -I/usr/src/packages/BUILD/gl

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 14:14 --- (In reply to comment #5) > You cannot use a va_list any more after passing it to a consumer like > vprintf. Just a note to fix your code, use va_copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From schwab at suse dot de 2005-04-09 14:11 --- You cannot use a va_list any more after passing it to a consumer like vprintf. -- What|Removed |Added

[Bug c++/20915] Precedence of /* over #if ???

--- Additional Comments From giovannibajo at libero dot it 2005-04-09 13:29 --- Invalid, this is the way it is. This is exactly the kind of bug which should *not* be reported in Bugzilla, but rather asked about in any newsgroup/forum/mailing list about programming. -- What

[Bug target/18847] ACATS cxa5012 SEGV on on x86_64

--- Additional Comments From laurent at guerby dot net 2005-04-09 13:18 --- Seems to be an heisenbug see http://gcc.gnu.org/ml/gcc/2005-04/msg00432.html changing subject since it no longer ICE on ia64. Reduced testcase from Richard Kenner, which confirms the bug, follows: $ cat cxa5012

[Bug c++/20912] C++ FE emitting assignments to read-only global symbols

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 12:48 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug c++/20915] Precedence of /* over #if ???

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-09 12:36 --- They are both preprocessor based. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20915

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From moritz at bunkus dot org 2005-04-09 12:31 --- Forgot to mention: compilation was done with a simple "g++ -Wall -o va_list_messed_up va_list_messed_up.cpp" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20916

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From moritz at bunkus dot org 2005-04-09 12:30 --- Created an attachment (id=8570) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8570&action=view) output of "g++ -v" on that platform -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20916

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From moritz at bunkus dot org 2005-04-09 12:30 --- Created an attachment (id=8569) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8569&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20916

[Bug c++/20916] va_list passed to a function gets messed up by a call to another function

--- Additional Comments From moritz at bunkus dot org 2005-04-09 12:29 --- Created an attachment (id=8568) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8568&action=view) source code for the sample case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20916

[Bug c++/20916] New: va_list passed to a function gets messed up by a call to another function

I'll attach a short sample file that works nicely on 32 bit architectures but breaks on AMD64. A function taking varargs calls va_start and passes that va_list object to another function. This one will output it twice with vprintf. Between the two calls to vprintf there's another function call.

[Bug c++/20915] New: Precedence of /* over #if ???

In: /* #if 0 */ #endif you get: ~/ootbc/members/src$ g++ foo.cc foo.cc:4:2: #endif without #if I thought that CPP directives dominated comments rather than the other way around (as the compiler seems to be doing) -- Summary: Precedence of /* over #if ??? Product: gcc

[Bug c++/20240] [3.3 Regression] invalid using-redeclaration accepted

--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-09 11:00 --- any reason why this bug is still NEW? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20240

[Bug c++/20173] [3.3/3.4/4.0/4.1 regression] gcc accepts invalid partial specialization attempt of member function

--- Additional Comments From sstrasser at systemhaus-gruppe dot de 2005-04-09 10:59 --- is still accepted by 4.0 although 20157 is fixed now -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20173

[Bug libstdc++/20914] Another grouping trouble

-- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20914

[Bug middle-end/14311] builtins for atomic operations needed

--- Additional Comments From pcarlini at suse dot de 2005-04-09 08:10 --- Ah, ok, now I got it ;) Actually, you meant exactly that i386 will *never* be exchangeable with i486+... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14311

[Bug middle-end/14311] builtins for atomic operations needed

--- Additional Comments From pcarlini at suse dot de 2005-04-09 07:53 --- Can you expand a bit on that? I understand perfectly that we are not going to have CAS for i386, but what's wrong with i486+?!? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14311

[Bug libstdc++/20914] Another grouping trouble

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

[Bug libstdc++/20914] New: Another grouping trouble

Unfortunately, we have got another *long* standing issue, which affects both integers and floats: when grouping, we should not involve an initial sign. For instance, -20, in "de_DE" gets grouped as -.200.000 and the initial '.' on the left is completely bogus. -- Summary: Another g