[Bug target/32201] Can not allocate %xmm0 register for variable blend insn

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 07:22 --- How can this be a regression if the constraint is new? Also it seems like you could use register asm("xmm0") to get the correct register to be used. -- pinskia at gcc dot gnu dot org changed: What

[Bug target/32201] Can not allocate %xmm0 register for variable blend insn

--- Comment #2 from ubizjak at gmail dot com 2007-06-04 07:39 --- (In reply to comment #1) > How can this be a regression if the constraint is new? This is the same failure as PR32189, and that one is marked as a regression. > Also it seems like you could use register asm("xmm0") to ge

[Bug target/32201] Can not allocate %xmm0 register for variable blend insn

--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-04 07:50 --- > > Also it seems like you could use register asm("xmm0") to get the correct > > register to be used. > But please note that "c" argument is passed to the function via xmm2. So this is why GCC has register asm() exte

[Bug target/32201] Can not allocate %xmm0 register for variable blend insn

--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-04 07:58 --- Note local allocate should be able to figure the "z" constraint is only one register and assign it to that pesdu-register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201

[Bug target/32201] Can not allocate %xmm0 register for variable blend insn

--- Comment #5 from ubizjak at gmail dot com 2007-06-04 08:06 --- Created an attachment (id=13655) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13655&action=view) Local alloc RTL dump RTL dump of .c.163r.lreg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201

[Bug middle-end/30537] [4.3 regression] ICE with -fno-unit-at-a-time an inlining

--- Comment #4 from jbglaw at lug-owl dot de 2007-06-04 08:18 --- That was already known in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30563 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30537

[Bug libgomp/32193] Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given

--- Comment #4 from rob1weld at aol dot com 2007-06-04 08:30 --- Results: Results for 4.3.0 20070602 (libc6_2.3.6.ds1-13) testsuite on i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00168.html Results for 4.3.0 20070602 (libc6_2.6~20070518-2) testsuite on i686-pc-li

[Bug fortran/32202] New: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

Please read first portion of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193 to see the where and how of obtaining and installing new libc6, then come back here. After upgrading my library I did a diff of the "make -i check" test results of the build before I upgraded and after I upgraded. It wa

[Bug fortran/32202] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 --- No need because this failure is a random failure anyways. *** This bug has been marked as a duplicate of 32057 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Ad

[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f

--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-04 08:37 --- *** Bug 32202 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057

[Bug fortran/32202] Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f

--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-04 08:44 --- Subject: Re: Upgrading GNU/Linux to libc6_2.6~20070518-2 fails gfortran.dg/secnds.f > No need because this failure is a random failure anyways. Afterall not so random: most of the failures are due to the fact that

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

--- Comment #7 from rob1weld at aol dot com 2007-06-04 08:58 --- >> [EMAIL PROTECTED] >> IEEE 754 does not discuss any of the functions you list above. In fact, >> IEEE 754 places requirements on exactly one function in libm, and that is >> sqrt(), which must be exact in all rounding mo

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

--- Comment #8 from rob1weld at aol dot com 2007-06-04 09:07 --- > [EMAIL PROTECTED] > Can you suggest a download URL? Mine is from ATT. I didn't save the URL. Your output is certainly a few pages shorter than mine. There is a Paranoia test included in Ucbtest that has output similar to

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

--- Comment #9 from rob1weld at aol dot com 2007-06-04 09:16 --- There is a wiki here - your contributions are appreciated. http://en.wikipedia.org/wiki/IEEE_754r -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180

[Bug fortran/32203] New: Support the vendor intrinsic function timef()

As requested: http://gcc.gnu.org/ml/fortran/2007-06/msg00013.html timef() allows one easily to track elapsed time. It is supported by a couple of vendors such as IBM and Intel, but not by gfortran, g95, g77, sunf95, NAG f95. http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic

[Bug fortran/32195] [regression] ICE in get_array_ctor_strlen

--- Comment #1 from dominiq at lps dot ens dot fr 2007-06-04 11:25 --- As far as I can tell this bug seems to affect only darwin7. The ICE occurs with RESHAPE and EOSHIFT with character arrays and a third optional argument: The following code character(len=1) :: tempn(1,2) charact

[Bug c++/32204] New: friend from global namespace in template class ignored

X-Bugzilla-Reason: CC First: I apologize if this report is missing something but I did not find enough information in the guidelines to be more accurate. Furthermore, I have only gcc 4.1.2 prerelease available (from Suse Linux 10.2), so I will be glad if somebody tells me the bug has been fixed in

[Bug target/32191] ICE with complex __float128

--- Comment #8 from ubizjak at gmail dot com 2007-06-04 12:27 --- A bit of debugging leads to following findings: build_common_builtin_nodes() defines supported complex mul/div functions depending on lang_hooks.types.type_for_mode(). This langhook defaults to c_common_type_for_mode().

[Bug c++/32182] [4.2 Regression] -fstrict-aliasing optimizations cause constructor not to run for object causing segfault

-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182

[Bug c++/32205] New: "defined but not used" warning given or not depending on other errors

Consider the following code: % cat unused.cpp static int GetFoo() { return 17; } static int foo = GetFoo(); void bar() { } This compiles without warnings: % g++ -Wall -c unused.cpp % However if any error is introduced, like e.g. removing the closing brace of the bar() function, then we get bo

[Bug c++/32158] uninitialized_fill compile failure if no default assignment operator

--- Comment #12 from mec at google dot com 2007-06-04 13:35 --- Verified with my two test programs with snapshot gcc-4.3-20070601. Thanks for the fast fix! -- mec at google dot com changed: What|Removed |Added -

[Bug c++/32190] wrong error recovery on parsing template arguments

--- Comment #3 from manu at gcc dot gnu dot org 2007-06-04 13:51 --- Likely, the code for parsing template arguments is not clever enough to stop as soon as something goes awry and report it correctly. -- manu at gcc dot gnu dot org changed: What|Removed

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #165 from rguenth at gcc dot gnu dot org 2007-06-04 14:02 --- The lates patch fixes the FreePOOMA testsuite regressions. I'll give it a performance testing spin on vangelis tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286

[Bug c++/32190] wrong error recovery on parsing template arguments

--- Comment #4 from igodard at pacbell dot net 2007-06-04 14:27 --- Well, in my ignorance, I'd say that the symptoms are consistent with scanning forward to the next ">", regardless of what gets scanned over, such an unmatched "<" or statement-lists. -- http://gcc.gnu.org/bugzilla/s

[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing

--- Comment #28 from rguenth at gcc dot gnu dot org 2007-06-04 15:28 --- solution_set_add () looks like the culprit (thx micha). So, the following will fix it in case we have offsets only from COMPONENT_REFs, not from regular pointer arithmetic (which is not true): Index: tree-ssa-str

[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing

--- Comment #29 from rguenth at gcc dot gnu dot org 2007-06-04 15:45 --- We can make it safe if we only really handle + in pointer arithmetic. Like with @@ -3258,7 +3255,7 @@ handle_ptr_arith (VEC (ce_s, heap) *lhsc unsigned int i = 0; unsigned int j = 0; VEC (ce_s, heap) *te

[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)

--- Comment #15 from sje at gcc dot gnu dot org 2007-06-04 15:58 --- Subject: Bug 31733 Author: sje Date: Mon Jun 4 15:58:12 2007 New Revision: 125312 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125312 Log: PR target/31733 * cfgrtl.c (rtl_verify_flow_info): S

[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)

--- Comment #16 from sje at cup dot hp dot com 2007-06-04 16:03 --- Fixed now. All testcases are working with ToT. -- sje at cup dot hp dot com changed: What|Removed |Added --

[Bug fortran/32206] New: gfortran testsuite - unexpected failures

8 # of unsupported tests 46 /Users/dir/gfortran/ibin/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070604 (experimental) -- Summary: gfortran testsuite - unexpected failures Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severi

[Bug fortran/32206] gfortran testsuite - unexpected failures

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 16:11 --- Only semi unexpected, the issue hasto do with fp rounding, *** This bug has been marked as a duplicate of 32057 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Ad

[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f

--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-04 16:11 --- *** Bug 32206 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c/32207] New: inconsistent/missed warnings about address of 'x'.

the following testcase express one condition in three different ways. in fact, gcc produces only two different warnings. extern void z(); void f() { if ( z ) z(); } void g() { if ( z != 0 ) z(); } void h() { if ( z != (void*)0 ) z(); } t.c: In function 'f': t.c:2: warning: the address of 'z' will

[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options

--- Comment #4 from aldot at gcc dot gnu dot org 2007-06-04 17:20 --- fx, are you still working on this? yet another reason why "-M" as an alias for -J should be dropped and instead proper -M dependency handling should be added is this: $ echo end > foo.f90 && gfortran -o main foo.f90

[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-04 17:32 --- (In reply to comment #7) > >> [EMAIL PROTECTED] > >> IEEE 754 does not discuss any of the functions you list above. In fact, > >> IEEE 754 places requirements on exactly one function in libm, and that is > >> sqrt(),

[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options

--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-04 17:39 --- (In reply to comment #4) > fx, are you still working on this? Not actively. It's probably not so hard, though: read the file, like we do with -fsyntax-only mode, and parse #file headers. > yet another reason why

[Bug c/32191] ICE with complex __float128

--- Comment #9 from ubizjak at gmail dot com 2007-06-04 17:42 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00188.html (Please do not open new bugreport for missing _multc3 and _divtc3. These will be added as a follow-up patch). -- ubizjak at gmail dot com changed:

[Bug c/32191] ICE with complex __float128

-- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com

[Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp

--- Comment #11 from theodore dot papadopoulo at sophia dot inria dot fr 2007-06-04 18:12 --- (In reply to comment #8) I suspect (unless I'm overlooked something) that this problem cause wrong statistics when using jointly the -fopenmp and -profile-* flags. I tried that and seen messa

[Bug libstdc++/32208] New: Patch for 32158 has bad code in std::vector::_M_fill_initialize

[EMAIL PROTECTED]:~/exp-43-redux$ cat vector-fill.cc // Copyright 2007, Google Inc. All rights reserved. // Author: [EMAIL PROTECTED] (Michael Chastain) #include std::vector my_vector (117); === [EMAIL PROTECTED]:~/exp-43-redux$ /home/mec/gcc-4.3-20070601/install/bin/g++ -Wall -S vector-fi

[Bug c/32209] New: Boot failure Comparing stages 2 and 3

Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./cfgloopanal.o differs ./expmed.o differs ./df-problems.o differs ./combine.o differs ./ebitmap.o differs ./emit-rtl.o differs ./reload.o differs ./cgraphunit.o differs ./c-typeck.o differs ./recog.o differs .

[Bug c/32191] ICE with complex __float128

--- Comment #10 from uros at gcc dot gnu dot org 2007-06-04 20:07 --- Subject: Bug 32191 Author: uros Date: Mon Jun 4 20:07:37 2007 New Revision: 125314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125314 Log: PR c/32191 * gcc/c-common.c (c_define_builtins): C

[Bug c/32191] ICE with complex __float128

--- Comment #11 from ubizjak at gmail dot com 2007-06-04 20:08 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #1 from andreast at gcc dot gnu dot org 2007-06-04 20:09 --- can you post the config flags? Did you may use --disable-checking ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209

[Bug c++/32210] New: Wrong alignment of struct members where one member is bitfield exceeding its type.

In the following testcase: #include #include #include class c1 { public: char m1 : 17; //char m2; }; void printbytes(void * p, int size) { printf("Printing an object on %i bytes\n",size); for (int i=0; im1 = 1; //obj->m2 = 1; printbytes(obj,sizeof(c1)); } The output is: Her

[Bug c++/32211] New: Compile error

While compiling KDE 3.5.7, this appears: - Making all in interfaces make[5]: Entering directory `/initrd/mnt/dev_save/VBProjects/passwordlinux/kde/konstruct/kde/kdepim/work/kdepim-3.5.7/kmail/interfaces' make[5]: Nothing to be done for `all'. make[5]: Leaving directory

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #2 from malitzke at metronets dot com 2007-06-04 20:42 --- Confirmation on different architecture (powerpc-linux-gnu G4) doing an *.nm comparison as follows: on c-common.o 16c16 < 00017d5c t add_tlist --- > 00017d60 t add_tlist 60c60 < 00018ca0 T c_add_case_label --- > 00018

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #3 from malitzke at metronets dot com 2007-06-04 20:56 --- Took the liberty of adding Prof Sikora and the release manager, Could not add MR Zedenek Dvorak (refusla by [EMAIL PROTECTED] This seems to be a case Maintainers no doing the required bootstraps. I am amazed that nob

[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options

--- Comment #6 from rep dot dot dot nop at gmail dot com 2007-06-04 20:50 --- Subject: Re: gfortran should be able to output Makefile dependencies with -M* options On Mon, Jun 04, 2007 at 05:39:48PM -, fxcoudert at gcc dot gnu dot org wrote: > > >--- Comment #5 from fxcoudert

[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings

--- Comment #50 from manu at gcc dot gnu dot org 2007-06-04 21:12 --- Subject: Bug 25241 Author: manu Date: Mon Jun 4 21:11:51 2007 New Revision: 125317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125317 Log: 2007-06-04 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR t

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #18 from hjl at lucon dot org 2007-06-04 21:14 --- (In reply to comment #12) > Maybe someone should timings without the second reassoc. > Jeff mentioned the loop optimizers cause new reassociations: > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html > And Daniel Berlin

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #19 from hjl at lucon dot org 2007-06-04 21:39 --- Can anyone show that the newly added dce_loop anything useful? Can we disable it or move it after the second reassoc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #4 from malitzke at metronets dot com 2007-06-04 21:56 --- Here is the build machinery used on the powerpc: There were two changes made to prior runs that caused no boot failures: BUILD was incresed from 11 to 12 form enable-languages c++, fortran were removed as being poin

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #20 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 22:15 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop > Can anyone show that the newly added dce_loop anything useful? Yes, predictive commoning does not work as well if there is

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #21 from hjl at lucon dot org 2007-06-04 22:19 --- (In reply to comment #20) > Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a > loop > > > Can anyone show that the newly added dce_loop anything useful? > > Yes, predictive commoning does not work

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-04 22:01 --- So you found a bug that was only exposed with " --disable-checking" which usually means two thing, a gcc_assert really has side effects or something is being micompiled now. Also by the way since the trunk works wi

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #22 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 22:39 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop > > > Can anyone show that the newly added dce_loop anything useful? > > > > Yes, predictive commoning does not work as well

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #23 from dberlin at gcc dot gnu dot org 2007-06-04 23:01 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop On 4 Jun 2007 22:15:46 -, rakdver at kam dot mff dot cuni dot cz <[EMAIL PROTECTED]> wrote: > > > --- Comment #20 from rakdve

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #24 from rakdver at kam dot mff dot cuni dot cz 2007-06-04 23:23 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop > > > Can anyone show that the newly added dce_loop anything useful? > > > > Yes, predictive commoning does not work as well

[Bug c/32212] New: Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory

I want to build a gcc 4.3.0 fresh from svn for the fr30-elf target. Binutils 2.17 are already installed in /usr/local/fr30-elf-new/. In the gcc source directory I do: # ./configure --target=fr30-elf --prefix=/usr/local/fr30-elf-new/ [...] # make [...] The build fails with the followin

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #26 from rakdver at gcc dot gnu dot org 2007-06-04 23:35 --- Created an attachment (id=13656) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13656&action=view) patch preventing reassociation across loop boundaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3218

[Bug bootstrap/32212] Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-04 23:37 --- Building in the source directory is one of the least tested features of GCC, you should try building in a different directory as recommended by http://gcc.gnu.org/install . -- pinskia at gcc dot gnu dot org chang

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #25 from rakdver at gcc dot gnu dot org 2007-06-04 23:34 --- > > Reassoc should be fixed, we should not consider workarounds like this. > > Either fix or remove reassoc2 works for me :) One possible fix is attached; it prevents us from reassociating across loop boundaries.

[Bug other/32213] New: License for libiberty

The web page: http://gcc.gnu.org/onlinedocs/libiberty/ Indicates that libiberty is LGPL. The directory for libiberty also contain only a COPYING.LIB, again indicating it should be LGPL to me. However, at least make-relative-prefix.c indicates that it is "part of libiberty", but is GPL, not LGPL

[Bug bootstrap/32212] Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory

--- Comment #2 from tk at maintech dot de 2007-06-05 00:06 --- Ok, if I build outside the source tree, the problem doesn't appear. I'm not sure if this is still a bug or not, so I'm leaving the ticket open. Thanks for the hint! -- tk at maintech dot de changed: What

[Bug other/32213] License for libiberty

--- Comment #1 from joseph at codesourcery dot com 2007-06-05 00:07 --- Subject: Re: New: License for libiberty See ; I don't recall seeing the SC's/FSF's answer to this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32213

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #27 from dberlin at gcc dot gnu dot org 2007-06-05 00:12 --- Subject: Re: [4.3 Regression] reassoc2 can more extra calculations into a loop On 4 Jun 2007 23:35:19 -, rakdver at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #26 from rakdver at gcc

[Bug tree-optimization/32183] [4.3 Regression] reassoc2 can more extra calculations into a loop

--- Comment #28 from hjl at lucon dot org 2007-06-05 00:15 --- (In reply to comment #25) > So probably this restriction should be applied only in reassoc2 (or reassoc2 > should be removed, if Daniel believes it is not useful). > My SPEC CPU 2000 resutls in comment #18 shows reassoc2 i

[Bug c++/32214] New: summary test

description test -- Summary: summary test Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kineiyoshid

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #6 from malitzke at metronets dot com 2007-06-05 01:29 --- Fantastic; My stupidity in copying the disable-checking from one of the dozen top distributors (which make experimental gcc-4.x.y available, patched them with gcc-3.x.y stuff and referred users to contact gcc maintain

[Bug c++/32211] Compile error

--- Comment #1 from fang at csl dot cornell dot edu 2007-06-05 01:57 --- g++: Internal error: Killed (program cc1plus) ... suggests that some external force terminated g++. Did you perhaps run out of memory? (If so, try 'ulimit') -- fang at csl dot cornell dot edu changed:

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

--- Comment #7 from andreast at gcc dot gnu dot org 2007-06-05 04:48 --- still broken for disable-checking -- andreast at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/32209] Boot failure Comparing stages 2 and 3

-- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconf

[Bug tree-optimization/32215] New: [4.3 Regression] ICE in supportable_narrowing_operation, at tree-vectorizer.c:1907

I'm getting the following ICE with gcc 4.3 20070604: (sid)25247:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 -ftree-vectorize ~/ascpu-ascpu_x.c /home/tbm/ascpu-ascpu_x.c: In function 'real_average': /home/tbm/ascpu-ascpu_x.c:11: internal com

[Bug tree-optimization/32216] New: [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize

I'm getting the following ICE with -O2 -ftree-vectorize and gcc 4.3 20070604. PR30958 mentions a similar ICE but the testcase looks quite different. (sid)25289:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O2 -ftree-vectorize fceu-sound.c fceu-sound.c: In function 'SetSoun

[Bug tree-optimization/30958] [4.3 Regression] ice for legal code with -ftree-vectorize -Os (-m64)

--- Comment #5 from tbm at cyrius dot com 2007-06-05 06:48 --- (In reply to comment #0) > Preprocessed source code attached. Flags -ftree-vectorize -Os -mno-sse > required. I don't see this with gcc 4.3 20070604. Do you still get this failure? -- http://gcc.gnu.o

[Bug c++/31724] [4.3 Regression] More "same canonical type node" fun

--- Comment #10 from tbm at cyrius dot com 2007-06-05 06:54 --- I don't suppose you've come to an agreement yet as to which fix is correct? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31724