[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-08-07 07:04 --- > I think you meant to say, "not depend on the native compiler" :-) Yes, the bootstrap compiler is the compiler you start the bootstrap with. > Right, but... of course, whenever I say that I set such-and-such flags, I mean > before configure time. After that point, it usually doesn't matter what you > have set in the environment, because the standard variables are explicitly > assigned in the makefiles. Of course you can override them on the line of the "make" command. > (You didn't think I was asking for the build system to track variables in the > environment _after_ configure time... did you?) I thought you were setting CFLAGS on the "make" line. But then your build wouldn't have failed this early, you would probably have waited until stage2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug middle-end/28628] New: Not forcing alignment of arrays in structs with -fsection-anchors
Since the fix to PR27770, we now miss opportunities to align some arrays when -fsection-anchors is enabled. The patch for PR27770 increases the alignment of (global) arrays only. We have a few testcases though (e.g. section-anchors-vect-69.c) that have global structs that contain fields that are arrays. Aligning the beginning of these structs can sometime align one/some of their array fields. Since the new function cgraph_increase_alignment does notattempt to do that, we have cases that will be vectorized less efficiently. To solve this we need to extend the optimization to align global structs that have array fields that could become aligned as a result. -- Summary: Not forcing alignment of arrays in structs with - fsection-anchors Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28628
[Bug middle-end/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec
--- Comment #25 from dorit at il dot ibm dot com 2006-08-07 07:09 --- (In reply to comment #24) > Fixed, a new different bug for the missed optimization should be opened. It's PR28628. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
[Bug c++/28573] [4.0/4.1/4.2 Regression] incorrectly allowing non-constant expression to offsetof()
--- Comment #2 from bonzini at gnu dot org 2006-08-07 07:38 ---
This gives an ICE-on-invalid.
template struct A
{
char d[i];
char &operator [] ( int indx ) { return d[indx]; }
};
struct B
{
A<44> a;
};
int main()
{
return __builtin_offsetof(B, a[0]);
}
Here, fold_offsetof_1 does not expect a CALL_EXPR to be there and dies.
The reason for the reporter's bug is similar but we do not ICE because we have
another INDIRECT_REF because of dereferencing the "char&" reference, and the
tree is like
INDIRECT_REF( CALL_EXPR ( operator[], INDIRECT_REF(null), 0 ) )
fold_offsetof_1 does not expect anything inside the INDIRECT_REF, and blindly
returns 0.
Testing a patch.
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2006-08-06 22:12:50 |2006-08-07 07:38:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28573
[Bug middle-end/28628] Not forcing alignment of arrays in structs with -fsection-anchors
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 07:41 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 07:41:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28628
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #25 from skunk at iskunk dot org 2006-08-07 07:42 --- (In reply to comment #24) > Of course you can override them on the line of the "make" command. Right, but that's getting into mucking-with-the-build territory. (Hence my tongue-in-cheek reply to Andreas in comment #4... it's the moral equivalent of editing the makefiles. You wear the developer's hat once you do that.) All I'm concerned with is building via top-level make(1) invocations---single target, no overrides---like a good little end user. > I thought you were setting CFLAGS on the "make" line. But then your build > wouldn't have failed this early, you would probably have waited until stage2. It was Andreas who suggested doing that. I balked Recap: The build fails in stage 1 because libiberty was built with CFLAGS in the usual way, but stage 1 genmodes was built without, and it wants to link against libiberty, and the linker chokes on the ABI incompatibility. This inconsistency is the real bug, and it has two solutions (listed in comemnt #20), and I'd advocate resolving it in the way that brings about convention-compliant behavior (build genmodes and the rest of stage 1 with CFLAGS). Any caveats w.r.t. CFLAGS should be noted in the docs, and possibly checked in the configure script, rather than avoided by way of a gratuitously broken variable convention unique to GCC. Does all that sound good? Can we at least agree that the aforementioned inconsistency is a bug, even if the build system is too hopelessly complex to fix it, and 4.2 might not even have this issue anymore? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug target/25500] [4.0/4.1/4.2 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #18 from bonzini at gnu dot org 2006-08-07 07:54 --- One element, but with some additional complication because it is a vector. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug bootstrap/28515] CFLAGS not propagated, resulting in object mismatch
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-08-07 07:56 --- > Does all that sound good? Can we at least agree that the aforementioned > inconsistency is a bug, even if the build system is too hopelessly complex to > fix it, and 4.2 might not even have this issue anymore? It would be a real bug if solving it would lead to something interesting. But it will not, bootstrap will die during stage2 because of the discrepancy between the ABI of the bootstrap compiler and that of the target. It's simply unsupported. And I'm not sure this is specific to GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28515
[Bug bootstrap/28511] syntax error in gcc/opt-gather.awk
--- Comment #8 from pluto at agmk dot net 2006-08-07 07:56 --- (In reply to comment #7) > Firstly, using /bin/sh to build the compiler is unsupported on Solaris. > Please > read http://gcc.gnu.org/install/specific.html#x-x-solaris2 with /bin/bash and /bin/ksh it fails in the same way. > checking for gawk... no > checking for mawk... no > checking for nawk... nawk i see in my log only checking for awk. gcc/configure.in contains only AC_PROG_AWK. config.log:configure:7110: checking for awk config.log:configure:7126: found /usr/bin/awk config.log:configure:7136: result: awk > Could you please post the contents of your $PATH variable? /usr/bin: /usr/local/bin: /opt/sfw/bin: /opt/gcc41/bin: /usr/ccs/bin: /usr/ucb: /usr/dt/bin: /usr/openwin/bin: /usr/local/X11R6/bin: $ which awk /usr/bin/awk $ which gawk /opt/sfw/bin/gawk $ which mawk no mawk in (...) $ which nawk /usr/bin/nawk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug target/25500] [4.0/4.1/4.2 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #19 from bonzini at gnu dot org 2006-08-07 07:59 --- This patchlet makes GCC use element-copy for struct FF: Index: expr.c === --- expr.c (revision 115990) +++ expr.c (working copy) @@ -4763,7 +4763,7 @@ count_type_elements (tree type, bool all return 2; case VECTOR_TYPE: - return TYPE_VECTOR_SUBPARTS (type); + return TYPE_MODE (type) == BLKmode ? TYPE_VECTOR_SUBPARTS (type) : 1; case INTEGER_TYPE: case REAL_TYPE: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #14 from hubicka at gcc dot gnu dot org 2006-08-07 08:01 --- Created an attachment (id=12032) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12032&action=view) Patch in testing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #5 from bonzini at gnu dot org 2006-08-07 08:08 --- Dale Johannesen's patch for PR19653 would have fixed this, but it broke SH (it caused PR27117). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #6 from bonzini at gnu dot org 2006-08-07 08:12 --- Also, note that the problem is not only that SSE is used to store th. Even if we enable SSE2, we do not use the SSE register to do the thdb.l++ and instead do this: movsd %xmm2, -8(%ebp) movl-8(%ebp), %eax movl-4(%ebp), %edx addl$1, %eax adcl$0, %edx movl%eax, -8(%ebp) movl%edx, -4(%ebp) movsd -8(%ebp), %xmm0 We'd need SRA for unions (using VIEW_CONVERT_EXPR) in order to do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug c/28629] New: Segfault with --march=pentium-m -O2 when compiling faac
Error message: filtbank.c: ÔÚº¯Êý ¡®MDCT¡¯ ÖУº filtbank.c:498: ±àÒëÆ÷ÄÚ²¿´íÎó£ºSegmentation fault ÇëÌá½»Ò»·ÝÍêÕûµÄ´íÎ󱨸棬 ÈçÓпÉÄÜÇ븽ÉϾԤ´¦ÀíºóµÄÔ´Îļþ¡£ ¾ßÌå²½ÖèÇë²Î¼û http://gcc.gnu.org/bugs.html>¡£ Output from gcc -v: ´Ó c:/mingw/bin/../lib/gcc/mingw32/4.1.1/specs ¶ÁÈ¡ specs Ä¿±ê£ºmingw32 ÅäÖÃΪ£º../gcc-4.1.1/configure --prefix=/mingw --enable-threads --host=mingw32 - -target=mingw32 --disable-shared --disable-win32-registry --enable-cxx-flags=-fo mit-frame-pointer -mfpmath=sse,387 -march=pentium-m Ïß³ÌÄ£ÐÍ£ºwin32 gcc °æ±¾ 4.1.1 It only appears when using both --march=pentium-m and optimization level higher than or equal to -O2. -- Summary: Segfault with --march=pentium-m -O2 when compiling faac Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zuxy dot meng at gmail dot com GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug c/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #1 from zuxy dot meng at gmail dot com 2006-08-07 08:14 --- Created an attachment (id=12033) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12033&action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug target/27117] SH backend cheats to reload -- disables indexed addressing but uses it internally
--- Comment #12 from bonzini at gnu dot org 2006-08-07 08:16 --- The latent bug is blocking a pretty serious (P2) 4.x regression. "Lie to reload, and it will take its revenge." -- bonzini at gnu dot org changed: What|Removed |Added OtherBugsDependingO||26778 nThis|| Status|RESOLVED|REOPENED Keywords|ice-on-valid-code | Resolution|FIXED | Summary|[4.2 Regression] gcc fails |SH backend cheats to reload |to build on sh64-elf targets|-- disables indexed ||addressing but uses it ||internally http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #40 from hubicka at gcc dot gnu dot org 2006-08-07 08:18 --- Roger, the patch for advance loc seems sane solution to me (in my limited understanding of dwarf2). If I understand it right, we need the advance_loc only when crossing the section boundary, so we ought to be able to use NOTE_INSN_SWITCH_TEXT_SECTIONS and use the advance_loc only when tripping over it. Only anoying thing would be probably to get it passed out of final.c up to the offending place. Thanks for looking into this, Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug c/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #2 from zuxy dot meng at gmail dot com 2006-08-07 08:26 --- (In reply to comment #0) > It only appears when using both --march=pentium-m and optimization level > higher > than or equal to -O2. Sorry, forgot to mention that I use -mfpmath=sse,387 in my spec file. So, more precisely, the bug can be reproduced with a combination of --march=pentium-m (or --march=pentium3 -msse2), -mfpmath=sse,387, and any optimization level high than or equal to -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug target/25277] missed optimization for simple mmx code.
--- Comment #3 from pluto at agmk dot net 2006-08-07 08:27 --- gcc-4.1.2-20060712: foo:subl$36, %esp #, movq%mm0, (%esp)# x, movl%ebx, 24(%esp) #, movl(%esp), %ebx#, x movl%esi, 28(%esp) #, movl4(%esp), %esi #, x movq%mm1, (%esp)# y, movl(%esp), %eax#, y pxor%mm0, %mm0 # movl%edi, 32(%esp) #, movl%ebx, %edi # x, D.2268 movl4(%esp), %edx #, y movl%esi, %ebx # x, D.2276 movq%mm0, 16(%esp) #, movl%eax, %ecx # y, D.2269 movl%edi, %eax # D.2268, tmp71 andl$2139062143, %edi #, D.2268 xorl%ecx, %eax # D.2269, tmp71 andl$2139062143, %ecx #, D.2269 andl$2139062143, %ebx #, D.2276 addl%edi, %ecx # D.2268, tmp75 andl$-2139062144, %eax #, tmp71 movl32(%esp), %edi #, xorl%ecx, %eax # tmp75, tmp71 movl%esi, %ecx # D.2276, tmp77 movl28(%esp), %esi #, movl%eax, 16(%esp) # tmp71, xorl%edx, %ecx # D.2277, tmp77 movl16(%esp), %eax #, andl$2139062143, %edx #, D.2277 andl$-2139062144, %ecx #, tmp77 addl%ebx, %edx # D.2276, tmp81 movl24(%esp), %ebx #, xorl%edx, %ecx # tmp81, tmp77 movl%eax, 8(%esp) #, movl%ecx, 12(%esp) # tmp77, movq8(%esp), %mm0 #, addl$36, %esp #, ret -- pluto at agmk dot net changed: What|Removed |Added Known to fail||4.1.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25277
[Bug bootstrap/28511] syntax error in gcc/opt-gather.awk
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-08-07 08:30 --- > i see in my log only checking for awk. > gcc/configure.in contains only AC_PROG_AWK. Err... there is no gcc/configure.in in 4.1.2, only gcc/configure.ac. And the configure fragment generated from AC_PROG_AWK will check nawk: - Macro: AC_PROG_AWK Check for `gawk', `mawk', `nawk', and `awk', in that order, and set output variable `AWK' to the first one that is found. It tries `gawk' first because that is reported to be the best implementation. Where did you get your sources from? Did you regenerate the configure script? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug target/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-07 08:40 --- doesn't reproduce on i686-linux. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug bootstrap/28511] syntax error in gcc/opt-gather.awk
--- Comment #10 from pluto at agmk dot net 2006-08-07 08:51 ---
(In reply to comment #9)
> > i see in my log only checking for awk.
> > gcc/configure.in contains only AC_PROG_AWK.
>
> Err... there is no gcc/configure.in in 4.1.2, only gcc/configure.ac.
sorry, typo.
> And the configure fragment generated from AC_PROG_AWK will check nawk:
>
> - Macro: AC_PROG_AWK
> Check for `gawk', `mawk', `nawk', and `awk', in that order, and
> set output variable `AWK' to the first one that is found. It
> tries `gawk' first because that is reported to be the best
> implementation.
> Where did you get your sources from?
svn:gcc-4_1-branch.
> Did you regenerate the configure script?
yes, and here is the problem.
$ diff -u configure{.orig,}
+configure
+generated by GNU Autoconf 2.59
# Find some useful tools
-for ac_prog in gawk mawk nawk awk
+for ac_prog in awk mawk gawk nawk
it works silently on linux where awk is a symlink
to gawk but fails on solaris :/
--
pluto at agmk dot net changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #7 from bonzini at gnu dot org 2006-08-07 08:51 --- Created an attachment (id=12034) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12034&action=view) patch that would fix it, but breaks SH -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug bootstrap/28511] syntax error in gcc/opt-gather.awk
--- Comment #11 from pluto at agmk dot net 2006-08-07 08:58 --- i should note that autoconf-2.59 works fine. $ info autoconf (...) -- Macro: AC_PROG_AWK Check for `awk', `mawk', `gawk', and `nawk', in that order, and set output variable `AWK' to the first one that is found. It tries `awk' first because that is reported to be the implementation that our system usually runs. (...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug target/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #4 from bonzini at gnu dot org 2006-08-07 09:00 --- Please disable your locale momentarily, and copy/paste the output of gcc -### -O2 -march=pentium-m filtbank.i or something like that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug bootstrap/28511] syntax error in gcc/opt-gather.awk
--- Comment #12 from pluto at agmk dot net 2006-08-07 09:04 --- (In reply to comment #11) > i should note that autoconf-2.59 works fine. > > $ info autoconf > (...) > -- Macro: AC_PROG_AWK > Check for `awk', `mawk', `gawk', and `nawk', in that order, and > set output variable `AWK' to the first one that is found. It > tries `awk' first because that is reported to be the > implementation that our system usually runs. > (...) > arghh, sorry. this is a distro-bug. it contains a patched autoconf. gcc is fine, vanilla autoconf is fine. /closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28511
[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement
--- Comment #5 from hubicka at gcc dot gnu dot org 2006-08-07 09:09 ---
The IA-64 problem shall be fixed by my patch for PR target/26655.
The x86 problem is trickier. Reload is decided to merge all classes mentioned
in given alternative, so "ad" is equivalent to "A", while recog.c is working
the oposite way.
The best way to fix it I can think of is to make reload ignore the classes that
are too small to fit the register themselves. It does not fix the problem
quite in general but at least deals with the x86 cases.
(in general one can have multiple register mode, join together two multiple reg
classes but reload might place the result just on the boundary still making
recog unhappy.)
Better ideas?
Honza
Index: reload.c
===
-cp -L reload.c (revision 115987) -L reload.c (working copy)
.svn/text-base/reload.c.svn-base reload.c
*** reload.c(revision 115987)
--- reload.c(working copy)
*** find_reloads (rtx insn, int replace, int
*** 2913,2918
--- 2913,2919
operand. */
int constmemok = 0;
int earlyclobber = 0;
+ enum reg_class class = NO_REGS;
/* If the predicate accepts a unary operator, it means that
we need to reload the operand, but do not do this for
*** find_reloads (rtx insn, int replace, int
*** 3309,3314
--- 3310,3316
/* Drop through into 'r' case. */
case 'r':
+ class = GENERAL_REGS;
this_alternative[i]
= (int) reg_class_subunion[this_alternative[i]][(int)
GENERAL_REGS];
goto reg;
*** find_reloads (rtx insn, int replace, int
*** 3368,3384
break;
}
this_alternative[i]
= (int) (reg_class_subunion
[this_alternative[i]]
! [(int) REG_CLASS_FROM_CONSTRAINT (c, p)]);
reg:
if (GET_MODE (operand) == BLKmode)
break;
winreg = 1;
if (REG_P (operand)
! && reg_fits_class_p (operand, this_alternative[i],
!offset, GET_MODE
(recog_data.operand[i])))
win = 1;
break;
}
--- 3370,3409
break;
}
+ class = REG_CLASS_FROM_CONSTRAINT (c, p);
+ /* When class is too tiny to hold the operand, ignore it.
+ See PR21299. First quickly test if things looks slopy
+ and if they does try to look if register is really
+ available. */
+ if (CLASS_MAX_NREGS (class, GET_MODE (recog_data.operand[i]))
+ > (int)reg_class_size [class])
+ {
+ int regno;
+ enum machine_mode mode;
+ for (regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
+ if (TEST_HARD_REG_BIT (reg_class_contents[class], regno)
+ && HARD_REGNO_MODE_OK (regno, mode)
+ && (regno + hard_regno_nregs[regno][mode]
+ < FIRST_PSEUDO_REGISTER)
+ && TEST_HARD_REG_BIT
+(reg_class_contents[class],
+ regno + hard_regno_nregs[regno][mode]))
+break;
+ if (regno == FIRST_PSEUDO_REGISTER)
+break;
+ }
this_alternative[i]
= (int) (reg_class_subunion
[this_alternative[i]]
! [(int) class]);
reg:
if (GET_MODE (operand) == BLKmode)
break;
winreg = 1;
if (REG_P (operand)
! && reg_fits_class_p (operand, class,
!offset,
!GET_MODE (recog_data.operand[i])))
win = 1;
break;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21299
[Bug target/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #5 from zuxy dot meng at gmail dot com 2006-08-07 09:28 --- (In reply to comment #4) > Please disable your locale momentarily, and copy/paste the output of > gcc -### -O2 -march=pentium-m filtbank.i > or something like that. C:\MSYS\source\faac\libfaac>gcc -### -O2 -march=pentium-m -mfpmath=sse,387 filtbank.i Using built-in specs. Target: mingw32 Configured with: ../gcc-4.1.1/configure --prefix=/mingw --enable-threads --host=mingw32 --target=mingw32 --disable-shared --disable-win32-registry --enable-cxx-flags=-fomit-frame-pointer -mfpmath=sse,387 -march=pentium-m Thread model: win32 gcc version 4.1.1 "c:/mingw/bin/../libexec/gcc/mingw32/4.1.1/cc1.exe" "-fpreprocessed" "filtbank.i" "-quiet" "-dumpbase" "filtbank.i" "-march=pentium-m" "-mfpmath=sse,387" "-auxbase" "filtbank" "-O2" "-o" "C:\\DOCUME~1\\jimeng\\LOCALS~1\\Temp/cckHr6En.s" "c:/mingw/bin/../lib/gcc/mingw32/4.1.1/../../../../mingw32/bin/as.exe" "-o" "C:\\DOCUME~1\\jimeng\\LOCALS~1\\Temp/ccYVP0yD.o" "C:\\DOCUME~1\\jimeng\\LOCALS~1\\Temp/cckHr6En.s" "c:/mingw/bin/../libexec/gcc/mingw32/4.1.1/collect2.exe" "-Bdynamic" "c:/mingw/bin/../lib/gcc/mingw32/4.1.1/../../../crt2.o" "-Lc:/mingw/bin/../lib/gcc/mingw32/4.1.1" "-Lc:/mingw/bin/../lib/gcc" "-Lc:/MinGW/lib/gcc/mingw32/4.1.1" "-Lc:/mingw/bin/../lib/gcc/mingw32/4.1.1/../../../../mingw32/lib" "-Lc:/MinGW/lib/gcc/mingw32/4.1.1/../../../../mingw32/lib" "-Lc:/mingw/bin/../lib/gcc/mingw32/4.1.1/../../.." "-Lc:/MinGW/lib/gcc/mingw32/4.1.1/../../.." "-L/mingw/lib" "C:\\DOCUME~1\\jimeng\\LOCALS~1\\Temp/ccYVP0yD.o" "-lmingw32" "-lgcc" "-lmoldname" "-lmingwex" "-lmsvcrt" "-luser32" "-lkernel32" "-ladvapi32" "-shell32" "-lmingw32" "-lgcc" "-lmoldname" "-lmingwex" "-lmsvcrt" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug fortran/28630] New: ICE due to a module function returning a derived type
This was reported by Mark Hesselink http://gcc.gnu.org/ml/fortran/2006-08/msg00124.html This: MODULE types TYPE :: t INTEGER :: i END TYPE END MODULE types MODULE foo USE types CONTAINS FUNCTION bar (x) RESULT(r) USE types REAL, INTENT(IN) :: x TYPE(t) :: r r = t(0) END FUNCTION bar END MODULE LOGICAL FUNCTION foobar (x) USE foo REAL :: x TYPE(t) :: c foobar = .FALSE. c = bar (x) END FUNCTION foobar produces: $ /irun/bin/gfortran mark.f90 mark.f90: In function 'foobar': mark.f90:22: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This is essentially the same as PR25391 except that it is a function that is picking up the wrong derived type definition (look at foo.mod). I already have a very kludgy fix working. Paul -- Summary: ICE due to a module function returning a derived type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paul dot richard dot thomas at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28630
[Bug debug/26881] [4.1/4.2 Regression] internal compiler error in dwarf2out_finish
--- Comment #15 from stephan at s11n dot net 2006-08-07 09:47 --- (In reply to comment #12) > This bug prevents the current release of the Globus toolkit > (www.globus.org) from compiling. A semi-workaround for getting SpiderMonkey to build is to export the BUILD_OPT=1 environment variable. This tells the SpiderMonkey makefile to turn off debugging, which causes the error to disappear. The down-side is that the library is then built to another directory, so you may have to change your Makefiles to accommodate finding the .so file in another place. For example, on my machine it is output to js/Linux_All_OPT.OBJ/. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26881
[Bug java/28423] multianewarray not always evaluated when compiling from bytecode
--- Comment #3 from aph at gcc dot gnu dot org 2006-08-07 09:54 --- Sure, we should import the change. -- aph at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Last reconfirmed|2006-08-06 22:43:47 |2006-08-07 09:54:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28423
[Bug c++/28631] New: no candidate even when it exists, depends on position of the function
I have a code (usage of C++ binding for the Squirrel language in the
Code::Blocks IDE) that cannot be compiled with g++ from 4.1.1 (from FC devel)
and 4.2.0 (20060729), but can be compiled with 3.2, 3.4 and 4.0 (all on
Redhat/Fedora).
The output from the compiler is
--
scriptbindings.cc: In static member function static void
SqPlus::ReturnSpecialization::Call(Callee&, RT (Callee::*)(P1)const) [with
Callee = Base, P1 = const String&, RT = const String&]:
scriptbindings.cc:55: instantiated from void SqPlus::Call(Callee&, RT
(Callee::*)(P1)const) [with Callee = Base, RT = const String&, P1 = const
String&]
scriptbindings.cc:60: instantiated from void
SqPlus::RegisterInstance(Callee&, Func) [with Callee = Base, Func = const
String& (Base::*)(const String&)const]
scriptbindings.cc:69: instantiated from SqPlus::SQClassDef&
SqPlus::SQClassDef::func(Func) [with Func = const String&
(Base::*)(const String&)const, TClassType = Base]
scriptbindings.cc:84: instantiated from here
scriptbindings.cc:44: error: no matching function for call to Push(const
String&)
scriptbindings.cc:27: note: candidates are: void SqPlus::Push(bool)
scriptbindings.cc:30: note: void SqPlus::Push(int)
--
It compiles when
- I remove the SqPlus namespace
- move the Push(bool) and Push(int) down to the definition of Push(String)
- move the Push(String) up to the Push(bool) and Push(int)
The code is here (downsized from 80K+ lines and 2+ MB :-) )
class String
{
public:
String();
};
class Base
{
public:
Base();
const String& GetString(const String& key) const;
bool GetBool() const;
};
namespace SqPlus {
template
struct TypeWrapper {
};
template
T * GetInstance() {
return (T *)0;
}
inline void Push(bool value) { }
inline bool Get(TypeWrapper) { return *GetInstance(); }
inline void Push(int value) { }
template
struct ReturnSpecialization {
template
static void Call(Callee & callee,RT (Callee::*func)() const) {
RT ret = (callee.*func)();
Push(ret);
}
template
static void Call(Callee & callee,RT (Callee::*func)(P1) const)
{
RT ret = (callee.*func)(Get(TypeWrapper()));
Push(ret);
}
};
template
void Call(Callee & callee, RT (Callee::*func)() const) {
ReturnSpecialization::Call(callee,func);
}
template
void Call(Callee & callee,RT (Callee::*func)(P1) const) {
ReturnSpecialization::Call(callee,func);
}
template
inline void RegisterInstance(Callee & callee,Func func) {
Call(*(Callee *)0,*(Func *)0);
}
template
struct SQClassDef {
SQClassDef();
template
SQClassDef & func(Func pfunc) {
RegisterInstance(*(TClassType *)0,pfunc);
return *this;
}
};
inline void Push(const String & value) { }
inline const String & Get(TypeWrapper) { return
*GetInstance(); }
inline void Push(Base * value) { }
inline Base & Get(TypeWrapper) { return *GetInstance(); }
};
void RegisterBindings()
{
SqPlus::SQClassDef().
func(&Base::GetString).
func(&Base::GetBool);
}
References:
http://forums.codeblocks.org/index.php?topic=3766.0
http://forums.codeblocks.org/index.php?topic=3481.0
http://squirrel-lang.org/forums/thread/1015.aspx
--
Summary: no candidate even when it exists, depends on position of
the function
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dan at danny dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28631
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #4 from pcarlini at suse dot de 2006-08-07 10:04 --- I'm looking at C99, G.6/3 and it looks like the builtin (as implemented by glibc) is "correct", or at least C99 complex conforming: the expected result is (0, -1). indeed, this is also stated at the end of the mentioned C99 7.3.3/1. Frankly, I don't think there is much more to say. Gaby, can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug target/28621] [4.1/4.2 Regression] SEGSEGV at set_fast_math () at ../../gcc/config/i386/crtfastmath.c:97 when using the -Os flag
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-07 10:18 ---
Hi,
because of quite serve register pressure issues, I don't like much idea of GCC
realocating stack transparently (it is also dificult to teach reload to decide
when alignment is needed). Safe bugfix for 4.2 seems to be this:
PR target/28621
* crtfastmath.c (force_align_arg_pointer): Force stack alignment.
Index: config/i386/crtfastmath.c
===
-u -L config/i386/crtfastmath.c (revision 115987) -L config/i386/crtfastmath.c
(working copy) config/i386/.svn/text-base/crtfastmath.c.svn-base
config/i386/crtfastmath.c
--- config/i386/crtfastmath.c (revision 115987)
+++ config/i386/crtfastmath.c (working copy)
@@ -38,6 +38,9 @@
#define SSE(1 << 25)
static void __attribute__((constructor))
+#ifndef __x86_64__
+__attribute__ ((force_align_arg_pointer))
+#endif
set_fast_math (void)
{
#ifndef __x86_64__
Does it help?
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621
[Bug target/27117] SH backend cheats to reload -- disables indexed addressing but uses it internally
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-08-07 10:28 --- (In reply to comment #12) > The latent bug is blocking a pretty serious (P2) 4.x regression. > > "Lie to reload, and it will take its revenge." Have you tried the patch from comments 5 to 8 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug target/27117] SH backend cheats to reload -- disables indexed addressing but uses it internally
--- Comment #14 from bonzini at gnu dot org 2006-08-07 11:11 --- sure, and actually I have posted it to the GCC Patches mailing list to get approval for the target-independent part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug tree-optimization/28632] New: [PATCH] add VRP for bitwise OR and AND
This patch adds value range propagation for (a&b), (a|b) operations. I am not familiar with gcc internals, so please review carefully before applying. -- Summary: [PATCH] add VRP for bitwise OR and AND Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vda dot linux at googlemail dot com GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
[Bug tree-optimization/28632] [PATCH] add VRP for bitwise OR and AND
--- Comment #1 from vda dot linux at googlemail dot com 2006-08-07 11:13 --- Created an attachment (id=12035) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12035&action=view) The patch relative to 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
[Bug tree-optimization/28632] [PATCH] add VRP for bitwise OR and AND
--- Comment #2 from vda dot linux at googlemail dot com 2006-08-07 11:14 --- Created an attachment (id=12036) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12036&action=view) Test program which demonstrates how VRP generates simpler code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
[Bug tree-optimization/28632] [PATCH] add VRP for bitwise OR and AND
--- Comment #3 from vda dot linux at googlemail dot com 2006-08-07 11:26
---
Differences in *.vrp (-fdump-tree-vrp output) and assembly generated
with stock 4.1.1 and with patched one out of test program test_vrp.c
--- test_vrp.c.t36-411org.vrp 2006-08-06 22:40:04.0 +0200
+++ test_vrp.c.t36-411new.vrp 2006-08-06 22:40:20.0 +0200
@@ -26,12 +26,15 @@
Value ranges after VRP:
n_1: VARYING
-D.1286_2: VARYING
-D.1287_3: VARYING
+D.1286_2: [256, 256] EQUIVALENCES: { } (0 elements)
+D.1287_3: [0, 1] EQUIVALENCES: { } (0 elements)
n_5: [65793, 65809] EQUIVALENCES: { n_1 n_6 } (2 elements)
n_6: [0, 65809] EQUIVALENCES: { n_1 } (1 elements)
+Folding predicate D.1286_2 != 0 to 1
+Merging blocks 2 and 3
+Merging blocks 2 and 4
u4 (n)
{
_Bool D.1288;
@@ -46,12 +49,7 @@
:;
D.1286_2 = n_1 & 256;
- if (D.1286_2 != 0) goto ; else goto ;
-
-:;
f ();
-
-:;
D.1287_3 = n_1 & 1;
if (D.1287_3 != 0) goto ; else goto ;
@@ -95,16 +93,18 @@
a_1: VARYING
b_2: VARYING
-D.1282_3: VARYING
-D.1282_4: [D.1282_3, D.1282_3] EQUIVALENCES: { D.1282_3 } (1 elements)
+D.1282_3: [4096, +INF] EQUIVALENCES: { } (0 elements)
+D.1282_4: [4096, +INF] EQUIVALENCES: { D.1282_3 } (1 elements)
a_5: [4096, 4096] EQUIVALENCES: { a_1 a_6 } (2 elements)
a_6: [4096, +INF] EQUIVALENCES: { a_1 } (1 elements)
b_7: [272, +INF] EQUIVALENCES: { b_2 } (1 elements)
-D.1282_8: [0, 4095] EQUIVALENCES: { D.1282_3 } (1 elements)
Simplified relational a_6 > 4096 into a_6 != 4096
+Folding predicate D.1282_3 > 4095 to 1
Removing basic block 8
+Merging blocks 3 and 4
+Merging blocks 3 and 5
v4 (a, b)
{
unsigned int D.1282;
@@ -120,12 +120,7 @@
:;
D.1282_3 = b_2 | 4096;
- if (D.1282_3 > 4095) goto ; else goto ;
-
-:;
f ();
-
-:;
D.1282_4 = D.1282_3;
if (D.1282_3 > 65535) goto ; else goto ;
--- test_vrp-411org.s 2006-08-06 22:40:04.0 +0200
+++ test_vrp-411new.s 2006-08-06 22:40:20.0 +0200
@@ -7,24 +7,20 @@
subl$8, %esp
movl16(%esp), %ebx
cmpl$65809, %ebx
- ja .L8
+ ja .L6
cmpl$65792, %ebx
- jbe .L8
- testb $1, %bh
- jne .L10
-.L5:
- andl$1, %ebx
- je .L8
+ ja .L8
+.L6:
addl$8, %esp
popl%ebx
- jmp g
+ ret
.L8:
+ callf
+ andl$1, %ebx
+ je .L6
addl$8, %esp
popl%ebx
- ret
-.L10:
- callf
- jmp .L5
+ jmp g
.size u4, .-u4
.globl v4
.type v4, @function
@@ -32,31 +28,25 @@
pushl %ebx
subl$8, %esp
movl16(%esp), %eax
- movl20(%esp), %edx
+ movl20(%esp), %ebx
cmpl$4095, %eax
- jbe .L19
+ jbe .L15
cmpl$4096, %eax
- je .L20
-.L19:
+ je .L16
+.L15:
addl$8, %esp
popl%ebx
ret
-.L20:
- cmpl$271, %edx
- jbe .L19
- movl%edx, %ebx
- orb $16, %bh
- cmpl$4095, %ebx
- ja .L21
.L16:
+ cmpl$271, %ebx
+ jbe .L15
+ callf
+ orb $16, %bh
cmpl$65535, %ebx
- jbe .L19
+ jbe .L15
addl$8, %esp
popl%ebx
jmp g
-.L21:
- callf
- jmp .L16
.size v4, .-v4
.ident "GCC: (GNU) 4.1.1"
.section.note.GNU-stack,"",@progbits
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
[Bug tree-optimization/26969] [4.1/4.2 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #9 from victork at gcc dot gnu dot org 2006-08-07 11:28 --- Subject: Bug 26969 Author: victork Date: Mon Aug 7 11:28:31 2006 New Revision: 115995 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115995 Log: ChangeLog PR tree-optimization/26969 * tree-vect-analyze.c (vect_analyze_loop_form): Add check of latch witch an empty list of PHIs. testsuite/Changelog: PR tree-optimizations/26969 * gcc.dg/vect/vect.exp: Compile tests prefixed with "unswitch-loops" with -funswitch-loops. * gcc.dg/vect/unswitch-loops-pr26969.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/unswitch-loops-pr26969.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug c++/28573] [4.0/4.1/4.2 Regression] incorrectly allowing non-constant expression to offsetof()
--- Comment #3 from patchapp at dberlin dot org 2006-08-07 11:50 --- Subject: Bug number PR28573 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00170.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28573
[Bug c++/28633] New: CMOV accessing unmapped memory
The following code fragment accesses a variable X (at fixed virtual address
0xc000) which is only guaranteed to be mapped in virtual memory if esp is
within a specific 4K range (from 0xcfcf to 0xcfcf0fff).
extern char _KERN_STACK;
register mword __esp asm ("esp");
printf ("[%d]\n",
(__esp - 1 & ~0xfff) == reinterpret_cast(&_KERN_STACK) ? X : -1);
The following code is generated by gcc:
100242: 8d 44 24 ff lea0x(%esp),%eax
100246: 83 cb ffor $0x,%ebx
100249: 25 00 f0 ff ff and$0xf000,%eax
10024e: 3d 00 00 cf cf cmp$0xcfcf,%eax
100253: 89 d8 mov%ebx,%eax
100255: 0f 44 05 00 f0 ff cfcmove 0xc000,%eax
10025c: 50 push %eax
10025d: 68 30 0f 00 c0 push $0xcf30
100262: e8 af 0c f0 bf call cf16 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28633
[Bug tree-optimization/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #3 from hubicka at gcc dot gnu dot org 2006-08-07 11:59 --- Created an attachment (id=12037) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12037&action=view) patch It looks like we should bite the bullet and let cgraph code to output the debug info I am testing the attached patch Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug gcov/profile/26570] [4.1/4.2 Regression] -fprofile-generate -fprofile-use cause memory corruption immediately
-- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26570
[Bug tree-optimization/28634] New: [4.1/4.2 regression] rounding problem with -fdelayed-branch on hppa/mips
[ forwarded from http://bugs.debian.org/381710 ]
The following report has been submitted by Kurt Roeckx:
I've been looking at the perl testsuite failure on hppa. See
http://bugs.debian.org/374396
This code:
while (cdouble < 0.0)
cdouble += adouble;
Generated by gcc-4.1 with -O2 and -fdelayed-branch gives:
fadd,dbl %fr13,%fr22,%fr13
.L1447:
fcmp,dbl,!< %fr13,%fr0
ftest
b .L1447
fadd,dbl %fr13,%fr22,%fr13
fsub,dbl %fr13,%fr22,%fr13
With -O2 and -fno-delayed-branch:
.L1239:
fadd,dbl %fr13,%fr22,%fr13
fcmp,dbl,!< %fr13,%fr0
ftest
b,n .L1239
As you can see, in case of the delayed branches it always
executes an fadd at the start and fsub at the end, which it
doesn't do without the delayed branches.
This is causing unwanted rounding problems, since the mantisa
doesn't have enough bits to keep the the required information.
I think atleast in this case, it's not a good idea to do this
optimization with floating point numbers.
The same code on gcc-4.0 with -fdelayed-branch seems to generate
this code:
.L661:
fadd,dbl %fr12,%fr22,%fr12
fcmp,dbl,!< %fr12,%fr0
ftest
b .L661
ldo -256(%r30),%r20
With -fno-delayed-branch:
.L643:
fadd,dbl %fr12,%fr22,%fr12
fcmp,dbl,!< %fr12,%fr0
ftest
b,n .L643
So gcc-4.0 looks good.
gcc-snapshot 20060721-1 gives with -fdelayed-branch:
fadd,dbl %fr12,%fr22,%fr12
.L1449:
fcmp,dbl,!< %fr12,%fr0
ftest
b .L1449
fadd,dbl %fr12,%fr22,%fr12
fsub,dbl %fr12,%fr22,%fr12
So that has the same problem.
For those not familiar with hppa assembler, a branch normally
executes the instruction following it too, before branching.
The ",n" in "b,n" will prevent the next instruction from being
executed, so has the same effect as following it with a nop
instruction.
The following code has the same effect:
#include
double cdouble = -1;
int main()
{
double adouble;
adouble = 9007199254740992.0; /* 2^53 */
while (cdouble < 0.0)
cdouble += adouble;
printf("%lf\n", cdouble);
return 0;
}
With delayed branches it prints:
9007199254740992.00
without:
9007199254740991.00
--
Summary: [4.1/4.2 regression] rounding problem with -fdelayed-
branch on hppa/mips
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28634
[Bug libgcj/28340] gij ignores -Djava.security.manager
--- Comment #1 from gary at gcc dot gnu dot org 2006-08-07 14:49 --- Subject: Bug 28340 Author: gary Date: Mon Aug 7 14:48:59 2006 New Revision: 115999 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115999 Log: 2006-08-07 Gary Benson <[EMAIL PROTECTED]> PR libgcj/28340: * java/lang/ClassLoader.java (clinit): Install a default security manager if java.security.manager is defined. (getParent, getSystemClassLoader): Use the correct stack frame during security checks. * java/net/URLClassLoader.java (findClass): Avoid calling this.toString() during VM initialization. (runtimeInitialized): New method. * java/net/natURLClassLoader.cc: New file. * Makefile.am (nat_source_files): Added the above. * Makefile.in: Rebuilt. Added: trunk/libjava/java/net/natURLClassLoader.cc Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.am trunk/libjava/Makefile.in trunk/libjava/java/lang/ClassLoader.java trunk/libjava/java/net/URLClassLoader.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28340
[Bug c++/28631] no candidate even when it exists, depends on position of the function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 14:50 --- GCC 4.1.0 is actually the correct behavior. This is a dup of bug 2922 which changed the behavior to be what the standard says it should be. *** This bug has been marked as a duplicate of 2922 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28631
[Bug c++/2922] [DR 197] two-stage lookup for unqualified function calls with type-dependent arguments
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-08-07 14:50 --- *** Bug 28631 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dan at danny dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2922
[Bug libgcj/28340] gij ignores -Djava.security.manager
--- Comment #2 from gbenson at redhat dot com 2006-08-07 14:54 --- I fixed it now -- gbenson at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28340
[Bug tree-optimization/28632] [PATCH] add VRP for bitwise OR and AND
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-07 14:54 --- First patches should be off of the mainline. Second Patchs should be sent to [EMAIL PROTECTED] Third and this should be able to fix PR 18031 which I added a patch already (though not officially sent it because I had not tested it). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||18031 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
[Bug c++/28633] CMOV accessing unmapped memory
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 15:03 --- Two things: 1. don't file a bug with a code fragment. 2. this is not a bug as _KERN_STACK can never be unmapped memory at least to the compiler. Use the attribute weak and that should fix your issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28633
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #38 from whaley at cs dot utsa dot edu 2006-08-07 15:32 --- Paolo, Thanks for all the help. I'm not sure I understand everything perfectly though, so there's some questions below . . . >I don't see how the last fmul[sl] can be removed without increasing code size. Since the flags are asking for performance, not size optimization, this should only be an argument if the fmul[s,l]'s are performance-neutral. A lot of performance optimizations increase code size, after all . . . Obviously, no fmul[sl] is possible, since gcc 3 achieves it. However, I can see that the peephole phase might not be able to change the register usage. >Can you please try re-running the tests? It takes skill^W^W Yes, I found the results confusing as well, which is why I reran them 50 times before posting. I also posted the tarfile (wt Makefile and assemblies) that built them, so that my mistakes could be caught by someone with more skill. Just as a check, maybe you can confirm the .s you posted is the right one? I can't find the loads of the matrix C anywhere in its assembly, and I can find them in the double version . . . Anyway, I like your suggestion (below) of getting the compiler so we won't have to worry about assemblies, so that's probably the way to go. On this front, is there some reason you cannot post the patch(es) as attachments, just to rule out copy problems, as I've asked in last several messages? Note there's no need if I can grab your stuff from SVN, as below . . . >because my tests were run on a similar Prescott (P4e) You didn't post the gcc 3 performance numbers. What were those like? If you beat/tied gcc 3, then the remaining fmul[l,s] are probably not a big deal. If gcc 3 is still winning, on the other hand . . . >It also would be interesting to re-run your code generator on a compiler built >from svn trunk. Are your changes on a branch I could check out? If so, give me the commands to get that branch, as we are scoping assemblies only because of the patching problem. Having a full compiler would indeed enable more detailed investigations, including loosing the full code generator on the improved compiler. >Also, I strongly believe that you should implement vectorization, ATLAS implements vectorization, by writing the entire GEMM kernel in assembly and directly using SSE. However, there are cases where generated C code must be called, and that's where gcc comes in . . . >or at least find out *why* GCC does not vectorize your code. It may be simply >that it does not have any guarantee on the alignment. I'm all for this. info gcc says that w/o a guarantee of alignment, loops are duped, with an if selecting between vector and scalar loops, is this not accurate? I spent a day trying to get gcc to vectorize any of the generator's loops, and did not succeed (can you make it vectorize the provided benchmark code?). I also tried various unrollings of the inner loop, particularly no unrolling and unroll=2 (vector length). I was unable to truly decipher the warning messages explaining the lack of vectorization, and I would truly welcome some help in fixing this. This is a separate issue from the x87 code, and this tracker item is already fairly complex :) I'm assuming if I attempted to open a bug tracker of "gcc will not vectorize atlas's generated code" it would be closed pretty quickly. Maybe you can recommend how to approach this, or open another report that we can exchange info on? I would truly appreciate the opportunity to get some feedback from gcc authors to help guide me to solving this problem. Thanks for all the info, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/25500] [4.0/4.1/4.2 Regression]: SSE2 vectorized code is slower on 4.x.x than previous
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-08-07 15:35 --- (In reply to comment #19) > This patchlet makes GCC use element-copy for struct FF: You have to be careful when editing count_type_elements so that the elements of a constructor that are not explict are zeroed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug inline-asm/28635] New: Interaction between different asm statements
I was experimenting with the way gcc does register allocation depending on different flags. I encountered one strange test file where adding a second asm statement made a first one fail which did work before. Even stranger, when I have both parts as separate functions before, the combined version compiles as well. This interdependence between asm statements seems extremely counterintuitive to me, and might cause difficult to find bugs in larger projects. The fact that omitting optimization causes my code to fail even for the version including the single asm statements makes this bug seem related to bug 11203. But the behaviour that some code does not compile even with optimizations, and that adding some functions makes those parts compile as well, are strange things not mentioned in that bug, so don't be hasty about marking this a duplicate. My compiler is a Gentoo build. I know you would love to make me reproduce this with a plain vanilla compiler, but I beg you to simply compile my attached test case with your version. If you can't reproduce the bug, I'll happily take this to the gentoo bugzilla. But I expect the cause rather deep inside the sources, nothing likely to be changed by some distribution patch set. -- Summary: Interaction between different asm statements Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Martin dot vGagern at gmx dot net GCC build triplet: i686-pc-linux-gnu-gcc GCC host triplet: i686-pc-linux-gnu-gcc GCC target triplet: i686-pc-linux-gnu-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
[Bug inline-asm/28635] Interaction between different asm statements
--- Comment #1 from Martin dot vGagern at gmx dot net 2006-08-07 15:49 --- Created an attachment (id=12038) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12038&action=view) Testcase demonstrating interference between assembler statements This test case exhibits the following behaviour on 4.1.1 as well as 3.4.6: -O1 -fPIC -fomit-frame-pointer -DDO_SINGLE X--- works XX-- expected errors X-X- works XXXX works XXX- fails: error in both:54 -XXX fails: error in f1:25 In the two cases marked failures, the error message is the following: can't find a register in class `GENERAL_REGS' while reloading `asm' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
[Bug target/28635] Interaction between different asm statements
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-07 15:53 --- I bet this is not a bug. x86 is known to be very register starved. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|inline-asm |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
[Bug target/28635] Interaction between different asm statements
--- Comment #3 from Martin dot vGagern at gmx dot net 2006-08-07 16:02 --- One more observation: I tried adding the flags corresponding to -O1 according to the info page: -fdefer-pop -fdelayed-branch -fguess-branch-probability -fcprop-registers -floop-optimize -fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra -ftree-copyrename -ftree-fre -ftree-ch -fmerge-constants The effect for my example is the same as -O0, not -O1, so the cause for the different behaviour must be some optimization included in -O1 and not corresponding to one of the mentioned flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
[Bug target/28635] Interaction between different asm statements
--- Comment #4 from Martin dot vGagern at gmx dot net 2006-08-07 16:14 --- (In reply to comment #2) > I bet this is not a bug. x86 is known to be very register starved. Yes, I know that. But this situation does not explain, why adding two more functions containing the asm statements separately suddenly causes the combined version to work as expected. It's not like including those functions suddenly caused my x86 to grow additional registers, after all... :-) I still don't see why my code should not compile even for register starved x86. Including the -fomit-frame-pointer optimization should allow using the ebp register at least for leaf functions. So I should have six registers at hand to use as I please, and gcc should know about this and allow using them all, especially since the constraints are all the same, so that any mapping between variables and registers should work equally well. I forgot to mention, the combination without optimization and with neither -fPIC nor -fomit-frame-pointer works well enough. So why is ebp handled so different from ebx if the frame pointer can be omitted for the function in question? And I know I repeat myself, but why does adding the single functions help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28635
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #8 from tromey at gcc dot gnu dot org 2006-08-07 16:30 --- I think comment #3 explains the problem. So, this is either a more general GCC bug, or it is not a bug at all. In any case it isn't a gcj problem :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug middle-end/28636] New: [4.0/4.1 regression] Miscompiled loop
$ gcc -O2 input.c -o input $ ./input input: input.c:36: main: Assertion `s.buffer_position == s.buffer_end' failed. The loop loses the increment of s.buffer_position. -- Summary: [4.0/4.1 regression] Miscompiled loop Product: gcc Version: 4.1.2 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schwab at suse dot de GCC target triplet: ia64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug middle-end/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #1 from schwab at suse dot de 2006-08-07 16:34 --- Created an attachment (id=12039) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12039&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug java/28380] ICE compiling class implementing nested interface from class compiled from jar
-- tromey at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||28067 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 16:38:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28380
[Bug libgcj/28312] peer libraries are installed into gcjversionedlibdir, not into nativeexeclib
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-07 16:38 --- Is this fixed by that commit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28312
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #39 from whaley at cs dot utsa dot edu 2006-08-07 16:47 --- Paolo, OK, never mind about all the questions on assembly/patches/SVN/gcc3 perf: I checked out the main branch, and vi'd the patched file, and I see that your patch is there. I am presently building the SVN gcc on several machines, and will be posting results/issues as they come in . . . I would still be very interested in advice on approaching the vectorization problem as discussed at the end of the mail. Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #40 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07 16:58 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 >> I don't see how the last fmul[sl] can be removed without increasing code >> size. >> > However, I can see that the > peephole phase might not be able to change the register usage. Actually, the peephole phase may not change the register usage, but it could peruse a scratch register if available. But it would be much more controversial (even if backed by your hard numbers on ATLAS) to state that splitting fmul[sl] to fld[sl]+fmul is always beneficial, unless there is some manual telling us exactly that... for example it would be a different story if it could give higher scheduling freedom (stuff like VectorPath vs. DirectPath on Athlons), and if we could figure out on which platforms it improves performance. > On this front, is there some reason you cannot post > the patch(es) as attachments, just to rule out copy problems, as I've asked in > last several messages? Note there's no need if I can grab your stuff from > SVN, > as below . . . > You already found about this :-P Unfortunately I mistyped the PR number when I committed the patch; I meant the commit to appear in the audit trail, so that you'd have seen that I had committed it. >> because my tests were run on a similar Prescott (P4e) >> > You didn't post the gcc 3 performance numbers. What were those like? If > you beat/tied gcc 3, then the remaining fmul[l,s] are probably not a big > deal. If gcc 3 is still winning, on the other hand . . . > I don't have GCC 3 on that machine. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #5 from ian at airs dot com 2006-08-07 17:14 --- Insofar as I understand this issue, it seems that C99 and the C++ standard specify different results for the square root of (-1, -0). If that is correct, then we can decide that we want libstdc++ to follow C99 rather than the C++ standard, but I don't think we can settle that simply by looking at C99. -- ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #41 from whaley at cs dot utsa dot edu 2006-08-07 17:19 --- Paolo, >Actually, the peephole phase may not change the register usage, but it >could peruse a scratch register if available. But it would be much more >controversial (even if backed by your hard numbers on ATLAS) to state >that splitting fmul[sl] to fld[sl]+fmul is always beneficial, unless We'll have to see how this is in x87 code. I have experience with it in SSE, where doing it is fully a target issue. For instance, the P4E likes you to avoid the explicit load on the end, where the Hammer prefers the explicit load. If I recall right, there is a *slight* advantage on the intel to the from-mem instruction, but I can't remember how much difference doing the separate load/use made on the AMD. We should get some idea by comparing gcc3 vs. your patched compiler on the various platforms, though other gcc3/4 changes will cloud the picture somewhat . . . If this kind of machine difference in optimality holds true for x87 as well, I assume a new peephole phase that looks for the scratch register could be called if the appropriate -march were thrown? Speaking of -march issues, when I get a compiler build that gens your new code, I will pull the assembly trick to try it on the CoreDuo as well. If the new code is worse, you can probably not call your present peephole if that -march is thrown? Thanks, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/28637] New: [4.1/4.2 regression] ICE on invalid template parameter
The following invalid code snippet triggers a segfault on mainline
and 4.1 branch:
===
template struct A {};
A<0> a;
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
This is fallout from PR 27668.
--
Summary: [4.1/4.2 regression] ICE on invalid template parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 27668
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #6 from pcarlini at suse dot de 2006-08-07 17:24 --- (In reply to comment #5) > Insofar as I understand this issue, it seems that C99 and the C++ standard > specify different results for the square root of (-1, -0). > > If that is correct, then we can decide that we want libstdc++ to follow C99 > rather than the C++ standard, but I don't think we can settle that simply by > looking at C99. Well, I see where the C++ standard says, in 26.2.8/13, "..., the value returned lies on the positive imaginary axis", however, let's admit that the current C++ standard is *very* sloppy about these mathematical subtleties: for one, the *entire* C++ standard has *no* notion of signed zero (at issue here!), neither of NaNs, or infinity, for that matter. Also, more generally, when we decided to use builtins everywhere, thus, eventually, libc functions, we made the choice that consistency with the C library is a must, I don't think we want to change that decision. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug c++/28637] [4.1/4.2 regression] ICE on invalid template parameter
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-08-07 17:25 --- Lee, this is fallout from your patch for PR 27668. Would you mind having a look? -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #7 from pcarlini at suse dot de 2006-08-07 17:26 --- By the way, as I read the cited LIA-3 draft, it's also consisten with C99. To restate my point in a different way, if we believe there is an inconsistency between C99 and C++03, then the former can only win about this specific issue (and hopefully C++0x also). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug c++/28638] New: [4.1/4.2 regression] ICE on invalid template parameter
The following invalid code snippet triggers a ICE on mainline and 4.1 branch:
===
template struct A;
template class> struct B {};
B b;
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:5: internal compiler error: tree check: expected tree_list, have
error_mark in coerce_template_template_parms, at cp/pt.c:3792
Please submit a full bug report, [etc.]
This is fallout from PR 27668.
--
Summary: [4.1/4.2 regression] ICE on invalid template parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 27668
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug c++/28639] New: [4.1/4.2 regression] ICE trying to print error on invalid template parameter
The following invalid code snippet triggers a ICE on mainline and 4.1 branch:
===
template struct A
{
static const int i = 1;
char a[i];
};
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc:4: internal compiler error: tree check: expected tree_list, have
error_mark in dump_template_parms, at cp/error.c:1245
Please submit a full bug report, [etc.]
This is fallout from PR 27668.
--
Summary: [4.1/4.2 regression] ICE trying to print error on
invalid template parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 27668
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug middle-end/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-07 17:34 --- I bet this is a loop.c bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug c++/28640] New: [4.1/4.2 regression] ICE redeclaring template with invalid parameter
The following invalid code snippet triggers an ICE on mainline and 4.1 branch: === template struct A; template struct A; === bug.cc:1: error: 'void' is not a valid type for a template constant parameter bug.cc:2: internal compiler error: tree check: expected tree_list, have error_mark in redeclare_class_template, at cp/pt.c:3323 Please submit a full bug report, [etc.] This is fallout from PR 27668. -- Summary: [4.1/4.2 regression] ICE redeclaring template with invalid parameter Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org BugsThisDependsOn: 27668 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c++/28641] New: [4.1/4.2 regression] ICE calling template function with invalid template parameter
The following invalid code snippet triggers an ICE on mainline and 4.1 branch:
===
template void foo();
void bar() { foo<0>(); }
===
bug.cc:1: error: 'void' is not a valid type for a template constant parameter
bug.cc: In function 'void bar()':
bug.cc:2: internal compiler error: tree check: expected tree_list, have
error_mark in type_unification_real, at cp/pt.c:9791
Please submit a full bug report, [etc.]
This is fallout from PR 27668.
--
Summary: [4.1/4.2 regression] ICE calling template function with
invalid template parameter
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 27668
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/28641] [4.1/4.2 regression] ICE calling template function with invalid template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28641
[Bug c++/28640] [4.1/4.2 regression] ICE redeclaring template with invalid parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c++/28639] [4.1/4.2 regression] ICE trying to print error on invalid template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28639
[Bug c++/28638] [4.1/4.2 regression] ICE on invalid template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug middle-end/28636] [4.0/4.1 regression] Miscompiled loop
--- Comment #3 from schwab at suse dot de 2006-08-07 17:51 --- -floop-optimize2 doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28636
[Bug libstdc++/28406] What should be value of sqrt(complex(-1.0,-0.0))?
--- Comment #8 from pcarlini at suse dot de 2006-08-07 18:16 --- (In reply to comment #7) > By the way, as I read the cited LIA-3 draft, it's also consisten with C99. To > restate my point in a different way, if we believe there is an inconsistency > between C99 and C++03, then the former can only win about this specific issue > (and hopefully C++0x also). But, actually, I don't think there are any inconsistencis here: the C++03 standard has no notion of -0.0 and, I maintain, the return value of sqrt(-1.0, -0.0) is undefined in C++03. Moreover, the value which we are currently (in GCC 4.x) returning, is consistent with C99 and LIA-3, and that seems a good QoI to me. Really, after all, I think everything is fine, for now at least (in principle C++0x may decide to be inconsistent with C99 and LIA-3 ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #42 from paolo dot bonzini at lu dot unisi dot ch 2006-08-07 18:19 --- Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3 > We should get some idea by comparing gcc3 vs. your > patched compiler on the various platforms, though other gcc3/4 changes will > cloud the picture somewhat . . . > That's why you should compare 4.2 before and after my patch, instead. > If this kind of machine difference in optimality holds true for x87 as well, I > assume a new peephole phase that looks for the scratch register could be > called > if the appropriate -march were thrown? > Or you can disable the fmul[sl] instructions altogether. > Speaking of -march issues, when I get a compiler build that gens your new > code, > I will pull the assembly trick to try it on the CoreDuo as well. If the new > code is worse, you can probably not call your present peephole if that -march > is thrown? > I'd find it very strange. It is more likely that the Core Duo has a more powerful scheduler (maybe the micro-op fusion thing?) that does not dislike fmul[sl]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug target/28074] -mstackrealign generates very inefficient code
--- Comment #2 from hjl at lucon dot org 2006-08-07 18:24 --- Here is the debug info generated by icc The section .debug_info contains: Compilation Unit @ offset 0x0: Length:272 Version: 2 Abbrev Offset: 0 Pointer Size: 4 <0>: Abbrev Number: 1 (DW_TAG_compile_unit) DW_AT_comp_dir: /export/home/hjl/bugs/gcc/xmm DW_AT_language: 1 (ANSI C) DW_AT_name: x.c DW_AT_producer: Intel(R) C++ Compiler for 32-bit applications, Version 9.1Build 20060323Z %s Fixes RangesRelative DW_AT_stmt_list : 0 <1><9b>: Abbrev Number: 2 (DW_TAG_pointer_type) DW_AT_type: <1>: Abbrev Number: 3 (DW_TAG_base_type) DW_AT_byte_size : 1 DW_AT_encoding: 6 (signed char) DW_AT_name: char <1>: Abbrev Number: 4 (DW_TAG_subprogram) DW_AT_decl_line : 3 DW_AT_decl_column : 7 DW_AT_decl_file : 1 DW_AT_accessibility: 1 (public) DW_AT_name: e1 DW_AT_type: <9b> DW_AT_prototyped : 1 DW_AT_frame_base : 2 byte block: 74 0 (DW_OP_breg4: 0) DW_AT_high_pc : 0x1a DW_AT_low_pc : 0 DW_AT_external: 1 DW_AT_MIPS_linkage_name: e1 <2>: Abbrev Number: 5 (DW_TAG_variable) DW_AT_decl_line : 5 DW_AT_decl_column : 19 DW_AT_decl_file : 1 DW_AT_accessibility: 1 (public) DW_AT_name: dummy DW_AT_type: DW_AT_location: 2 byte block: 91 0 (DW_OP_fbreg: 0) DW_AT_external: 0 <1>: Abbrev Number: 6 (DW_TAG_volatile_type) DW_AT_type: <1>: Abbrev Number: 7 (DW_TAG_typedef) DW_AT_decl_line : 44 DW_AT_decl_column : 54 DW_AT_decl_file : 2 DW_AT_accessibility: 1 (public) DW_AT_name: __m128 DW_AT_type: <1>: Abbrev Number: 8 (DW_TAG_array_type) DW_AT_accessibility: 1 (public) DW_AT_name: __m128 DW_AT_type: <107> DW_AT_byte_size : 16 <2>: Abbrev Number: 9 (DW_TAG_subrange_type) DW_AT_accessibility: 1 (public) DW_AT_name: __m128 DW_AT_upper_bound : 3 DW_AT_lower_bound : 0 <1><107>: Abbrev Number: 3 (DW_TAG_base_type) DW_AT_byte_size : 4 DW_AT_encoding: 4 (float) DW_AT_name: float Dump of debug contents of section .debug_line: Length: 102 DWARF Version: 2 Prologue Length: 74 Minimum Instruction Length: 1 Initial value of 'is_stmt': 1 Line Base: -1 Line Range: 4 Opcode Base: 10 Opcodes: Opcode 1 has 0 args Opcode 2 has 1 args Opcode 3 has 1 args Opcode 4 has 1 args Opcode 5 has 1 args Opcode 6 has 0 args Opcode 7 has 0 args Opcode 8 has 0 args Opcode 9 has 1 args The Directory Table: /opt/intel/cc/9.1/include The File Name Table: Entry Dir TimeSizeName 1 0 1149695375 126 x.c 2 1 1144184578 18608 xmmintrin.h Line Number Statements: Extended opcode 2: set Address to 0x0 Advance Line by 3 to 4 Copy Special opcode 38: advance Address by 9 to 0x9 and Line by 1 to 5 Special opcode 34: advance Address by 8 to 0x11 and Line by 1 to 6 Extended opcode 2: set Address to 0x1a Extended opcode 1: End of Sequence Contents of the .debug_abbrev section: Number TAG 1 DW_TAG_compile_unit[has children] DW_AT_comp_dir DW_FORM_string DW_AT_language DW_FORM_data1 DW_AT_name DW_FORM_string DW_AT_producer DW_FORM_string DW_AT_stmt_listDW_FORM_data4 2 DW_TAG_pointer_type[no children] DW_AT_type DW_FORM_ref4 3 DW_TAG_base_type[no children] DW_AT_byte_sizeDW_FORM_data1 DW_AT_encoding DW_FORM_data1 DW_AT_name DW_FORM_string 4 DW_TAG_subprogram[has children] DW_AT_decl_lineDW_FORM_data1 DW_AT_decl_column DW_FORM_data1 DW_AT_decl_fileDW_FORM_data1 DW_AT_accessibility DW_FORM_data1 DW_AT_name DW_FORM_string DW_AT_type DW_FORM_ref4 DW_AT_prototyped DW_FORM_flag DW_AT_frame_base DW_FORM_block1 DW_AT_high_pc DW_FORM_addr DW_AT_low_pc DW_FORM_addr DW_AT_external DW_FORM_flag DW_AT_MIPS_linkage_name DW_FORM_string 5 DW_TAG_variable[no children] DW_AT_decl_lineDW_FORM_data1 DW_AT_decl_column DW_FORM_data1 DW_AT_decl_fileDW_FORM_data1 DW_AT_accessibility DW_FORM_data1 DW_AT_name DW_FORM_string DW_AT_type DW_FORM_ref4 DW_AT_location DW_FORM_block1 DW_AT_external DW_FORM_flag 6 DW_TAG_volatile_type[no children] DW_AT_type DW_FORM_ref4 7 DW_TAG_typedef[no children] DW_AT_decl_lineDW_FORM_data1 DW_AT_decl_column DW_FORM_data1 DW_AT_decl_fileDW_FORM_data1 DW_A
[Bug c++/28642] New: ICE in layout_type, at stor-layout.c:1851
attribute((maybe_aliased)) in a union causes ICE -- Summary: ICE in layout_type, at stor-layout.c:1851 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: apl at alum dot mit dot edu GCC build triplet: i6868-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28642
[Bug c++/28642] ICE in layout_type, at stor-layout.c:1851
--- Comment #1 from apl at alum dot mit dot edu 2006-08-07 18:27 --- Created an attachment (id=12040) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12040&action=view) test case causing ICE compiled with: g++ -c ice.cxx -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28642
[Bug libmudflap/28578] A most simple multithreaded program (practically any multithreaded one) causes mudflap violation
-- fche at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 18:30:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28578
[Bug c++/28642] ICE in layout_type, at stor-layout.c:1851
--- Comment #2 from apl at alum dot mit dot edu 2006-08-07 18:34 --- Amending the "description" attribute ((may_alias)) in a union causes ICE. I'm using the 7/15/2006 snapshot of 4.2 I realize that unions are implicitly 'aliased', but in fact this problem was encountered while I was trying to debug a more complex situation. I have a template class that tries to deposit smaller addressable units into a larger POD type. The alias analysis code in gcc3.4 thru 4.2 optimizes this code in ways that produce "wrong results". I've tried a number of workarounds, including use of volatile asm instructions to deal with that without any success - and since I'm in the realm of undefined behavior, I don't expect anything from GCC developers. But, regardless of the optimization issues, an ICE on what should be legal code is something that needs fixing... -- apl at alum dot mit dot edu changed: What|Removed |Added Known to fail||3.4.3 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28642
[Bug c++/28637] [4.1/4.2 regression] ICE on invalid template parameter
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 20:01:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28637
[Bug c++/28638] [4.1/4.2 regression] ICE on invalid template parameter
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 20:02:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28638
[Bug c++/28640] [4.1/4.2 regression] ICE redeclaring template with invalid parameter
-- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-07 20:02:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28640
[Bug c/17645] Add a warning for potentially unsafe unsigned operations
--- Comment #11 from mathieu at malaterre dot com 2006-08-07 20:25 --- Tested today (Aug 7, 2006) with: $ /usr/lib/gcc-snapshot/bin/g++ --version /tmp g++ (GCC) 4.2.0 20060721 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /usr/lib/gcc-snapshot/bin/g++ -Wall -ftrapv bla.cxx $ ./a.out [1]24229 abort ./a.out Marking the bug fixed. Thank you ! -- mathieu at malaterre dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17645
[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #43 from dorit at il dot ibm dot com 2006-08-07 20:35 --- > I'm all for this. info gcc says that w/o a guarantee of alignment, loops are > duped, with an if selecting between vector and scalar loops, is this not > accurate? yes >I spent a day trying to get gcc to vectorize any of the generator's > loops, and did not succeed (can you make it vectorize the provided benchmark > code?). The aggressive unrolling in the provided example seems to be the first obstacle to vectorize the code > I also tried various unrollings of the inner loop, particularly no > unrolling and unroll=2 (vector length). I was unable to truly decipher the > warning messages explaining the lack of vectorization, and I would truly > welcome some help in fixing this. I'd be happy to help decipher the vectorizer's dump file. please send the un-unrolled version and the dump file generated by -fdump-tree-vect-details, and I'll see if I can help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug libgcj/28609] make install broken in current trunk (svn 115947)
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-07 20:37 --- Subject: Bug 28609 Author: tromey Date: Mon Aug 7 20:37:50 2006 New Revision: 116003 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116003 Log: PR libgcj/28609: * ltconfig: Copied from gcc. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/ltconfig -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28609
[Bug libgcj/28609] make install broken in current trunk (svn 115947)
--- Comment #3 from tromey at gcc dot gnu dot org 2006-08-07 20:39 --- I took your advice and checked in the result of that cp. Thanks! -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28609
[Bug middle-end/28643] New: redundant phi-node in latch-block prevents vectorization
Since the fix for PR26969, we now fail to vectorize loops that have redundant phi-nodes in their (otherwise empty) latch block. The testcase committed with the PR fix is an example for such a case. See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00034.html for more details. -- Summary: redundant phi-node in latch-block prevents vectorization Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dorit at il dot ibm dot com GCC build triplet: powerpc-linux GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28643
[Bug target/28629] Segfault with --march=pentium-m -O2 when compiling faac
--- Comment #6 from dannysmith at users dot sourceforge dot net 2006-08-07 21:04 --- (In reply to comment #2) > (In reply to comment #0) > precisely, the bug can be reproduced with a combination of --march=pentium-m > (or --march=pentium3 -msse2), -mfpmath=sse,387, and any optimization level > high > than or equal to -O2. gcc -c -O2 -march=pentium-m -mfpmath=sse,387 filtbank.i compiles without error on trunk with native mingw32 Target: mingw32 Configured with: ../gcc/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --with-cpu=pentium2 --disable-werror --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,objc,fortran --disable-win32-registry --disable-sjlj-exceptions Thread model: win32 gcc version 4.2.0 20060803 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28629
[Bug c/28644] New: 400.perlbench never completes when compiled with -O3
Hi, I've been trying to run perlbench (speccpu 2006 benchmark) compiled with gcc 4.1.0 with "-O3 -ffast-math -funroll-all-loops -m64". But when I run this benchmark, it never completes (it goes on more than 3 hours) and I'd to kiil it. It completes when I added -fno-inline option. Just wanted to report this as a possible problem in the inliner. GCC has been configured as shown below. Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++ --disable-checking --libdir=/usr/lib64 --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 4.1.0 Processor: AMD Opteron -- Summary: 400.perlbench never completes when compiled with -O3 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uttam_p at yahoo dot com GCC build triplet: x86-64 GCC host triplet: x86-64 GCC target triplet: x86-64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28644
[Bug rtl-optimization/28644] 400.perlbench never completes when compiled with -O3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-07 21:52 --- 4.1.0 is getting old and 4.1.1 has been released with bugs fixed. And this bug really has no info about what the problem is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |rtl-optimization Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28644
