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

--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-12 06:58 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 12, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Apr 11, 2005, Josh Conner <[EMAIL PROTECTED]> wrote: >> I'm now g

Re: Mainline build failure on i686-pc-linux-gnu

--prefix=/home/gdr --enable-languages=c++ --disable-nls Thread model: posix gcc version 4.1.0 20050411 (experimental) Blowing away that compiler and using the native compiler (3.3.1) of my system let me complete the build. Whatever problem there was yesterday, it seems to have been fixed. Thanks, -- Gaby

[Bug tree-optimization/20962] copyprop dump files have wrong names

--- Additional Comments From dnovillo at redhat dot com 2005-04-12 04:15 --- Subject: Re: New: copyprop dump files have wrong names On Tue, Apr 12, 2005 at 03:48:10AM -, kazu at cs dot umass dot edu wrote: > test.c.t21.copyprop1 > test.c.t26.copyprop2 > test.c.t40.copyprop3 > test

Re: [Bug tree-optimization/20962] New: copyprop dump files have wrong names

On Tue, Apr 12, 2005 at 03:48:10AM -, kazu at cs dot umass dot edu wrote: > test.c.t21.copyprop1 > test.c.t26.copyprop2 > test.c.t40.copyprop3 > test.c.t55.copyprop5 > test.c.t66.copyprop4 > > Note that the last two lines are sort of swapped. > t55 and t66 should have copyprop4 and copyprop6,

Re: Mainline build failure on i686-pc-linux-gnu

Diego Novillo <[EMAIL PROTECTED]> writes: | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ | > -o crtbegin.o | > make[1]: *** [crtbegin.o] Aborted | > make[1]: Leaving directory `/home/gdr/build/4.1/gcc' | > make:

[Bug tree-optimization/20962] New: copyprop dump files have wrong names

Consider void foo (void) { } "./cc1 -quiet -O2 -fdump-tree-copyprop test.c" gives me test.c.t21.copyprop1 test.c.t26.copyprop2 test.c.t40.copyprop3 test.c.t55.copyprop5 test.c.t66.copyprop4 Note that the last two lines are sort of swapped. t55 and t66 should have copyprop4 and copyprop6, respec

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

--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-12 03:35 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 11, 2005, Josh Conner <[EMAIL PROTECTED]> wrote: > I'm now getting a ICE building the mainline (please ignore the > "3.4.3"

[Bug c++/20961] ICE on pragma weak/__attribute__((weak))

--- Additional Comments From nick at ilm dot com 2005-04-12 02:42 --- mislabeled as c - should be c++ compiling as c on x86_64-unknown-linux-gnu succedes compiling as c++ on x86_64-unknown-linux-gnu fails compiling as c on i686-pc-linux-gnu succedes compiling as c++ on i686-pc-linux-gnu

[Bug c/20961] ICE on pragma weak/__attribute__((weak))

--- Additional Comments From nick at ilm dot com 2005-04-12 02:37 --- I meant to say that it succedes with i686-pc-linux-gnu not x86-unknown-linux-gnu > /dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0-20050410/

[Bug c/20961] New: ICE on pragma weak/__attribute__((weak))

The following program fails on x86_64-unknown-linux-gnu but succeedes on x86-unknown-linux-gnu with the prerelease. > /dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/gcc -c bug.C gcc: Internal error: Segmentation fault (program cc1plus) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> f

Re: Mainline build failure on i686-pc-linux-gnu

On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ > -o crtbegin.o > make[1]: *** [crtbegin.o] Aborted > make[1]: Leaving directory `/home/gdr/build/4.1/gcc' > make: *** [all-gcc] Error 2 > What's your top-of-ChangeLog?

Mainline build failure on i686-pc-linux-gnu

Build of freshly updated mainline tree fails with: /home/gdr/build/4.1/./gcc/xgcc -B/home/gdr/build/4.1/./gcc/ -B/home/gdr/i686-pc- linux-gnu/bin/ -B/home/gdr/i686-pc-linux-gnu/lib/ -isystem /home/gdr/i686-pc-lin ux-gnu/include -isystem /home/gdr/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W

[Bug c++/20646] [4.0/4.1 Regression] ICE on illegal code: "extern static" struct member

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-04-12 01:10 --- (In reply to comment #6) > localhost:~/GCC/FSF/gcc-4.0.0-20050410-build lars$ > i686-apple-darwin7.2.1/libobjc/.libs/libobjc-gnu.1.0.0.dylib: Mach-O > dynamically linked shared > library i3

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-04-12 01:07 --- the error messages remain the same: set_ld_library_path_env_vars: ld_library_path=.:/Users/lars/GCC/FSF/gcc-4.0.0-20050410-build/gcc:/ Volumes/Data/Users/lars/GCC/FSF/gcc-4.0.0-20050410-buil

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-04-12 00:54 --- bootstrap and testing went faster than I expected, from a cursory examination all the failures remain with the patch applied: === objc Summary === # of expected passes

[Bug fortran/18197] bus error on returning from a function

-- Bug 18197 depends on bug 20960, which changed state. Bug 20960 Summary: bus error for return an array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20960 What|Old Value |New Value

[Bug fortran/20960] bus error for return an array

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-12 00:49 --- Actually this is invalid code as I found out the hard way, XLC has the same issue as gfortran. Why ICC plays so fast and lose I have no idea, oh well. The correct way to declare the function and use it is t

[Bug fortran/20956] gfortran - internal compiler error with -fdefault-real-8

--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-12 00:15 --- > > powerpc-apple-darwin7.8.0 > Must be target specific troutmask:kargl[204] cat ki.f subroutine prncp3 common /concrt/ sigma(6) equivalence (sigma(1),p1) sigma(1)=sin(phi + 2.*pi/3

[Bug fortran/20956] gfortran - internal compiler error with -fdefault-real-8

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-12 00:11 --- (In reply to comment #2) > Dale, what OS are you using? The above compiles > fine on amd64-*-freebsd. powerpc-apple-darwin7.8.0 Also make sure that you are using -fdefault-real-8, I could confirm it on

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From drow at false dot org 2005-04-12 00:06 --- Subject: Re: Top-level gcc configure/makefile does not handle --with-sysroot On Mon, Apr 11, 2005 at 08:39:53PM -, prothonotar at tarnation dot dyndns dot org wrote: > > --- Additional Comments From protho

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

-- What|Removed |Added CC||drow at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955

[Bug fortran/20956] gfortran - internal compiler error with -fdefault-real-8

--- Additional Comments From kargl at gcc dot gnu dot org 2005-04-12 00:04 --- (In reply to comment #0) > subroutine prncp3 > common /concrt/ sigma(6) > equivalence (sigma(1),p1) > sigma(1)=sin(phi + 2.*pi/3.d0) > return > end Dale, what OS are you us

[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself

--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11 23:59 --- Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01227.html -- What|Removed |Added

[Bug fortran/17758] gfortran_abort should be marked as noreturn

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 23:52 --- _gfortran_runtime_error is another one which shows up for -fbounds-checking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17758

[Bug fortran/19777] -fbounds-check catches non-existent bounds violation

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 23:50 --- D.491 = D.487 <= 0; D.492 = D.487 > 0; D.493 = D.491 || D.492; D.494 = __builtin_expect (D.493, 0); That is just wrong. -- What|Removed |Added --

[Bug fortran/20960] New: bus error for return an array

Take the following code: function f () result (mat) real, dimension(3) :: mat mat(1) = 1 return end program t real, dimension(3) :: mat mat = f () end - Run it and you will get a bus error/segfault. I think this is the same as PR 18197. This works with ICC 8.1. It was redu

[Bug fortran/18197] bus error on returning from a function

-- What|Removed |Added BugsThisDependsOn||20960 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18197

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-04-11 23:21 --- I applied the patch and doing another bootstrap now. results tomorrow (what a luck that I can sleep while it bootstraps ;-)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20959

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

--- Additional Comments From sje at cup dot hp dot com 2005-04-11 23:14 --- The problem is that the inline divide instructions are generating frcpa instructions that use the floating point status register (fpsr) 1 when they should be using fpsr 0. I will test a patch overnight and submi

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 23:10 --- Does this patch help: Index: linking.m === RCS file: /cvs/gcc/gcc/libobjc/linking.m,v retrieving revision 1.4 diff -u -p -r1.4 linking.m --- l

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-04-11 23:00 --- Created an attachment (id=8602) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8602&action=view) detailed log file of testsuite run output of make check-objc RUNTESTFLAGS="--target_board

[Bug libobjc/20959] lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-04-11 22:59 --- Created an attachment (id=8601) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8601&action=view) Test suite summary output of make check-objc RUNTESTFLAGS="--target_board=unix/-fgnu-runt

[Bug libobjc/20959] New: lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental)

see http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00798.html and attached files -- Summary: lots of libobjc regressions on i686-apple-darwin7.2.1 with GCC 4.0 RC1 compared to 4.0.0 20050220 (experimental) Product: gcc Ve

[Bug c++/20949] [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...

--- Additional Comments From pluto at pld-linux dot org 2005-04-11 22:38 --- (In reply to comment #1) > Well without a test, there is still nothing we can do anyways because they could be invoking undefined > behavior :). > Also do they fail when compiled with -O0? Konqueror works fine

[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-11 22:07 --- Subject: Bug 20933 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-11 22:06:47 Modified files: gcc: ChangeLog tree-ssa-alias.c tree-ssa.c

[Bug libgcj/20958] Compile Errors In two files in gnu.gcj

--- Additional Comments From aluchko at redhat dot com 2005-04-11 21:56 --- Created an attachment (id=8600) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8600&action=view) fix This patch fixes the two small syntax errors that show up using gcj. -- http://gcc.gnu.org/bugzilla/s

[Bug libgcj/20958] New: Compile Errors In two files in gnu.gcj

While building the java sources of gcj using Eclipse I discovered two lines which ecj (Eclipse Compiler for Java) regarded as syntax errors in libjava/gnu/gcj/runtime/PersistentByteMap.java and libjava/gnu/gcj/tools/gcj_dbtool/Main.java I'm attaching a small patch fixing the problem --

[Bug target/20957] Error while compiling kernel

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 21:42 --- Can you attach the preprocessed as requested by . -- What|Removed |Added ---

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

--- Additional Comments From sje at cup dot hp dot com 2005-04-11 21:34 --- This also came up in the string starting at http://gcc.gnu.org/ml/gcc/2005-03/msg00483.html I gave a patch in http://gcc.gnu.org/ml/gcc/2005-03/msg00729.html but having GCC generate this error gives a bunch o

[Bug target/20957] Error while compiling kernel

-- What|Removed |Added Severity|critical|normal Component|c |target Keywords||

[Bug c/20957] New: Error while compiling kernel

The compile of the kernel (2.6.11) fails on linux m68k, the machine has a 68060 processor and options to use 68060 instructions were giver to the compile process. As it is the standard kernel tool I didn't have any access to the compile options, I know only the message and the module. CC d

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

--- Additional Comments From jconner at apple dot com 2005-04-11 21:10 --- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail On Apr 10, 2005, at 8:50 PM, Alexandre Oliva wrote: > On Apr 10, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >> Thanks for alerti

[Bug fortran/20120] real(kind=16) and sqrt, sin and other math functions cause ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 21:03 --- Sin has the same problem. -- What|Removed |Added Summary|real(kind=16) and sqrt

[Bug fortran/20120] real(kind=16) and sqrt function cause ICE

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

[Bug fortran/20956] gfortran - internal compiler error with -fdefault-real-8

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

[Bug fortran/20956] New: gfortran - internal compiler error with -fdefault-real-8

Here is a -fdefault-real-8 problem - [dranta:~/tests/gfortran] dir% gfortran -fdefault-real-8 -o prncp3 prncp3.f prncp3.f: In function 'prncp3': prncp3.f:1: internal compiler error: in gfc_get_intrinsic_lib_fndecl, at fortran/trans-intrinsic.c:499 Please submit a full bug report, with preprocessed

[Bug c++/20646] [4.0/4.1 Regression] ICE on illegal code: "extern static" struct member

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 20:50 --- Mark, this appeared with your patch http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00988.html -- What|Removed |Added --

[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11 20:43 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From prothonotar at tarnation dot dyndns dot org 2005-04-11 20:39 --- One more note about the log: the failures in libstdc++'s configure are because the options to xgcc (passed from the top-level makefile) are as I stated in my original comment. I don't have the c

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:35 --- Can you attach the config.log from libstdc++ subdirectory since that is where the failure should show up? checking for wcslen... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. -

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From prothonotar at tarnation dot dyndns dot org 2005-04-11 20:35 --- Apologies for the verbose log... I was using a build script :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From prothonotar at tarnation dot dyndns dot org 2005-04-11 20:32 --- Created an attachment (id=8599) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8599&action=view) Log showing complete configure->build failure in libstdc++ As requested, here is my log. As

[Bug c++/20789] [3.4/4.0/4.1 regression] ICE with incomplete type in template

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 20:24 --- Looks very similar to PR 20668. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789

[Bug c++/20668] [3.4/4.0/4.1 Regression] ICE on invalid code, value dependent but invalid wise

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 20:23 --- Even shorter testcase: = template struct A {}; template struct B { static const T i; static const int j = i; A a; }; B b; = -

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:20 --- In fact the code in gcc.c does this for you so your patch does not makes sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:18 --- Also --with-sysroot should set up the sysroot inside GCC itself so you don't need the flags you are adding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:17 --- Can you attach the full log, because I know people have built cross compilers before with --with- sysroot and they worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20955

[Bug other/20955] Top-level gcc configure/makefile does not handle --with-sysroot

--- Additional Comments From prothonotar at tarnation dot dyndns dot org 2005-04-11 20:16 --- Created an attachment (id=8598) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8598&action=view) Modifies top-level configure and Makefile.in to support sysroot I modified the configure sc

[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-11 20:15 --- Subject: Bug 20926 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-11 20:15:35 Modified files: gcc: ChangeLog tree-ssa-alias.c Log mess

[Bug c++/20789] [3.4/4.0/4.1 regression] ICE with incomplete type in template

-- What|Removed |Added Severity|normal |minor Target Milestone|3.4.4 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20789

[Bug other/20955] New: Top-level gcc configure/makefile does not handle --with-sysroot

The top-level gcc configure currently only passes the "--with-sysroot" to the subdirectories, and of these, the "gcc" subdir seems to be the only one that uses it. When I was configuring with languages c and c++, this meant that the libstdc++ package would not build, because it couldn't find my nat

[Bug c++/20789] [3.4/4.0/4.1 regression] ICE with incomplete type in template

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 20:14 --- Confirmed, happens since gcc 3.4.0. Reduced testcase: == template struct A; template struct B {}; template struct C { static const int i = A::i; static const

[Bug fortran/20954] gfortran - internal compiler error with -fdefault-integer-8

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:14 --- Confirmed, I might have a fix soon. -- What|Removed |Added CC|

[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:08 --- Note I think this is just the register allocator being stupid. See PR 18048 for another bug report about this. Though I note on ppc-darwin, I cannot reproduce the problem you see with your testcase. --

[Bug target/20953] Wrong assembler being used in gcc/config/i386/t-sol2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 20:07 --- Fixed in 4.0.0 and above. Closing as fixed as this is not a regression. -- What|Removed |Added --

[Bug fortran/20954] New: gfortran - internal compiler error with -fdefault-integer-8

Some programs really need "-fdefault-real-8 -fdefault-integer-8", but I get this error on the Macintosh - [dranta:~/tests] dir% gfortran -fdefault-integer-8 -o d8test2 d8test2.f d8test2.f: In function 'MAIN__': d8test2.f:4: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:152 P

[Bug target/20953] Wrong assembler being used in gcc/config/i386/t-sol2

--- Additional Comments From prothonotar at tarnation dot dyndns dot org 2005-04-11 20:05 --- Created an attachment (id=8597) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8597&action=view) Proposed patch to fix this. I believe the latest (gcc 4.0) version uses $(GCC_FOR_TARGET),

[Bug target/20953] Wrong assembler being used in gcc/config/i386/t-sol2

-- What|Removed |Added Component|c |target Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2095

[Bug c/20953] New: Wrong assembler being used in gcc/config/i386/t-sol2

For the gcrt1.o target in gcc/config/i386/t-sol2, the make macro $(AS) is used, but this should be $(AS_FOR_TARGET). -- Summary: Wrong assembler being used in gcc/config/i386/t-sol2 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: no

[Bug middle-end/20396] TRULY_NOOP_TRUNCATION ignored

--- Additional Comments From echristo at redhat dot com 2005-04-11 19:54 --- OK. I'm willing to fix up the mips backend for this if you hand me the patch ahead of time (and it's accepted as a good idea by the middle-end maintainers). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=203

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 19:49 --- Confirmed, the code which does this on the RTL level is in simplify_const_relational_operation. -- What|Removed |Added --

[Bug fortran/20935] failed assertion for maxloc(n, mask=.true.)

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

[Bug target/20927] [4.0/4.1 Regression] ICE in smallest_mode_for_size, at stor-layout.c:221 (s390x)

--- Additional Comments From uweigand at gcc dot gnu dot org 2005-04-11 19:40 --- Reduced testcase: struct point { double x, y; }; extern void use (struct point); void test (struct point *pc, struct point p1) { struct point p0 = *pc; if (p0.x == p1.x && p0.y == p1.y) use (p0);

[Bug tree-optimization/16611] Terrible code generated for vector

--- Additional Comments From sabre at nondot dot org 2005-04-11 19:40 --- This code from stl_bvector.h is the problem: void _M_incr(ptrdiff_t __i) { difference_type __n = __i + _M_offset; _M_p += __n / _M_word_bit; __n = __n % _M_word_bit; if (__n < 0) { _M_offse

Re: Fix tree-optimization/20920

On Sat, 2005-04-09 at 23:27 -0400, Diego Novillo wrote: > 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 opt

[Bug c++/20817] [4.0/4.1 Regression] ICE for tree check in build_offset_type

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-11 19:14 --- It's a 4.0 regression, too. -- What|Removed |Added CC|

[Bug tree-optimization/20612] ICE in verify_ssa for -ftree-loop-linear

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11 19:13 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug middle-end/20934] [4.1 Regression] Segmentation fault in gnat1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 19:05 --- Created an attachment (id=8595) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8595&action=view) new patch which Caroline sent me to attach Apparently there were two typo's in the patch I sent to you,

[Bug tree-optimization/20612] ICE in verify_ssa for -ftree-loop-linear

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-11 18:55 --- Subject: Bug 20612 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-11 18:55:47 Modified files: gcc: ChangeLog lambda-code.c Log message

[Bug target/20952] gmake -k check failures

-- What|Removed |Added Component|testsuite |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20952

[Bug testsuite/20952] New: gmake -k check failures

I'm building gcc-4.0.0-20050410 on Solaris 10 x86 on an AMD64 CPU. I bootstrapped successfully. This is what I got during the libstdc++ section of "gmake -k check": === libstdc++ tests === Schedule of variations: unix Running target unix Using /usr/local/share/dejagnu/baseb

[Bug libgcj/20693] javax-imageio.lo failed to build

--- Additional Comments From hjl at lucon dot org 2005-04-11 18:14 --- It also happened to gcc 4.0 on a P4 HT machine with "make -j4 bootstrap". -- What|Removed |Added

[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-04-11 18:00 --- Subject: Re: [4.1 Regressopm] ICE: tree check, in recent builds On Mon, 2005-04-11 at 17:49 +, paulthomas2 at wanadoo dot fr wrote: > --- Additional Comments From paulthomas2 at wanadoo dot

[Bug c/20951] bogus error passing &va_list to va_list*

--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:51 --- Yes, I read that comment but I still don't see anything in the standard the footnote is in conflict with and I don't see it on the WG14 DR list(*). If the footnote is bogus and va_list can't be universally imple

[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:51 --- (In reply to comment #7) > > The error existed before 04/01, AFAICT > > > I don't believe so - I have a gcc build of 20050129 that does not do this; see > my posting on the fortran list. He means April 1st

[Bug tree-optimization/20926] [4.1 Regressopm] ICE: tree check, in recent builds

--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-11 17:49 --- > The error existed before 04/01, AFAICT > I don't believe so - I have a gcc build of 20050129 that does not do this; see my posting on the fortran list. Further evidence, if it helps, is that the code comp

[Bug middle-end/20933] [4.1 Regression] gcc can no longer bootstrap itself

--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-11 17:41 --- Testing fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20933

[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing

--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-11 17:39 --- Subject: Re: -fno-second-underscore induces warning for fortran that needs preprocessing pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot

[Bug c/20951] bogus error passing &va_list to va_list*

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:35 --- (In reply to comment #2) > Do you happen to know whether there's a C99 issue to fix the footnote? If you read that bug's comment, you will see in comment #8: "My recollection from last time we were discuss

[Bug c/20951] bogus error passing &va_list to va_list*

--- Additional Comments From sebor at roguewave dot com 2005-04-11 17:33 --- (In reply to comment #1) Right. I understand why it doesn't compile and how to work around it (with gcc at least). What I'm still not convinced of is that it's not a strict conformance bug. The same point was r

[Bug middle-end/20934] [4.1 Regression] Segmentation fault in gnat1

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:24 --- Created an attachment (id=8594) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8594&action=view) patch which Caroline sent me to attach "I mistakenly assumed that if current_function_decl was defined,

[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:20 --- (In reply to comment #8) > We're using the traditional preprocessor. This is a separate executable, cpp, > which is built separately. So the question remains: why do we run cc1? cpp just calls cc1. There u

[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing

--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-04-11 17:16 --- Subject: Re: -fno-second-underscore induces warning for fortran that needs preprocessing pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot

[Bug middle-end/20946] --enable-checking=yes,fold fails on the mainline

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:16 --- Patch here: . -- What|Removed |Added

[Bug middle-end/20931] [4.0/4.1 Regression] fold checking failure

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:16 --- Patch here: . -- What|Removed |Added

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

--- Additional Comments From bkoz at redhat dot com 2005-04-11 17:14 --- Subject: Re: builtins for atomic operations needed > I'm working on atomic builtins, but this will *not* resolve the problem of > compiling for i386 and i486+. Indeed, it could easily make it worse because > you

[Bug c++/20949] [4.0/4.1 Regression] misscompilation of konqueror, artsd, STLport, libstdc++, ...

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:12 --- http://gcc.gnu.org/ml/gcc/2005-04/msg00514.html -- What|Removed |Added CC|

[Bug target/14557] va_list is automatically taken address-of when passed as argument

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

[Bug target/20951] bogus error passing &va_list to va_list*

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-11 17:07 --- Nope this is invalid, see PR 14557 for more discussion about this issue. &va is equivalent to &va[0] on x86_64 since va_list is defined as an array on x86_64. *** This bug has been marked as a duplicate of

  1   2   >