[Bug driver/35703] New: Internal compiler error in arm_dbx_register_number
Dear support, When i try to cross compile IMX31 BSP for LTIB with in build gcc version 3.4.3, i got the following error and get strucked arm-none-linux-gnueabi-ranlib ./libgcov.a arm-none-linux-gnueabi-gcc -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fomit-frame-pointer -fPIC -g0 -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -fexceptions -c ../../gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o ../../gcc/unwind-dw2.c: In function 'extract_cie_info': ../../gcc/unwind-dw2.c:328: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ../../gcc/unwind-dw2.c:381: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'execute_cfa_program': ../../gcc/unwind-dw2.c:844: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'uw_frame_state_for': ../../gcc/unwind-dw2.c:1060: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../gcc/unwind-dw2.c: In function 'init_dwarf_reg_size_table': ../../gcc/unwind-dw2.c:1272: internal compiler error: in arm_dbx_register_number, at config/arm/arm.c:15191 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Internal compiler error in arm_dbx_register_number Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rj dot sivakumar at dyansys dot com GCC build triplet: SUSE Linux GCC host triplet: SUSE Linux GCC target triplet: ARM1136j (IMX31) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35703
[Bug target/35703] Internal compiler error in arm_dbx_register_number
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|driver |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35703
[Bug target/29693] ICE while compiling gcc-3.4.3 with gcc-4.1.1
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-26 07:15 --- *** Bug 35703 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rj dot sivakumar at dyansys ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29693
[Bug target/35703] Internal compiler error in arm_dbx_register_number
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-26 07:15 --- *** This bug has been marked as a duplicate of 29693 *** -- 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=35703
[Bug ada/33688] Ada package Gnat.Sockets missing constant for IP_PKTINFO (patch)
--- Comment #6 from charlet at gcc dot gnu dot org 2008-03-26 07:35 --- Subject: Bug 33688 Author: charlet Date: Wed Mar 26 07:34:57 2008 New Revision: 133545 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133545 Log: 2008-03-26 Thomas Quinot <[EMAIL PROTECTED]> PR ada/33688 * g-socket.ads, g-socket.adb (Options, Set_Socket_Option, Get_Socket_Option): Add support for Receive_Packet_Info. * g-soccon.ads, g-soccon-tru64.ads, g-soccon-aix.ads, g-soccon-irix.ads, g-soccon-hpux.ads, g-soccon-solaris.ads, g-soccon-vms.ads, g-soccon-mingw.ads, g-soccon-freebsd.ads, g-soccon-hpux-ia64.ads, g-soccon-solaris-64.ads, g-soccon-darwin.ads, g-soccon-lynxos.ads, g-soccon-linux-64.ads, g-soccon-linux-x86.ads: Add new constants SO_REUSEPORT and IP_PKTINFO Modified: trunk/gcc/ada/g-soccon-aix.ads trunk/gcc/ada/g-soccon-darwin.ads trunk/gcc/ada/g-soccon-freebsd.ads trunk/gcc/ada/g-soccon-hpux-ia64.ads trunk/gcc/ada/g-soccon-hpux.ads trunk/gcc/ada/g-soccon-irix.ads trunk/gcc/ada/g-soccon-linux-64.ads trunk/gcc/ada/g-soccon-linux-x86.ads trunk/gcc/ada/g-soccon-lynxos.ads trunk/gcc/ada/g-soccon-mingw.ads trunk/gcc/ada/g-soccon-solaris-64.ads trunk/gcc/ada/g-soccon-solaris.ads trunk/gcc/ada/g-soccon-tru64.ads trunk/gcc/ada/g-soccon-vms.ads trunk/gcc/ada/g-soccon.ads trunk/gcc/ada/g-socket.adb trunk/gcc/ada/g-socket.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33688
[Bug ada/33688] Ada package Gnat.Sockets missing constant for IP_PKTINFO (patch)
--- Comment #7 from charlet at gcc dot gnu dot org 2008-03-26 07:58 --- This PR should now be addressed, please reopen if not, clarifying what's missing. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33688
[Bug bootstrap/35704] New: Bootstrap failure on i686-apple-darwin9 at revision 133519 (take 2).
The failure is: ... /gcc/objc -I../../gcc-4.4-work/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc-4.4-work/gcc -I../../gcc-4.4-work/gcc/objcp -I../../gcc-4.4-work/gcc/../include -I./../intl -I../../gcc-4.4-work/gcc/../libcpp/include -I/sw/include -I../../gcc-4.4-work/gcc/../libdecnumber -I../../gcc-4.4-work/gcc/../libdecnumber/dpd -I../libdecnumber-o objcp/objcp-act.o -MT objcp/objcp-act.o -MMD -MP -MF objcp/.deps/objcp-act.Po ../../gcc-4.4-work/gcc/objc/objc-act.c ../../gcc-4.4-work/gcc/objc/objc-act.c: In function 'objc_build_component_ref': ../../gcc-4.4-work/gcc/objc/objc-act.c:1258: error: too few arguments to function 'finish_class_member_access_expr' ../../gcc-4.4-work/gcc/objc/objc-act.c: In function 'objc_generate_cxx_ctor_or_dtor': ../../gcc-4.4-work/gcc/objc/objc-act.c:4496: error: too few arguments to function 'build_special_member_call' ../../gcc-4.4-work/gcc/objc/objc-act.c: In function 'generate_shared_structures': ../../gcc-4.4-work/gcc/objc/objc-act.c:5744: error: too few arguments to function 'build_c_cast' ../../gcc-4.4-work/gcc/objc/objc-act.c:5750: error: too few arguments to function 'build_c_cast' ../../gcc-4.4-work/gcc/objc/objc-act.c: In function 'build_objc_method_call': ../../gcc-4.4-work/gcc/objc/objc-act.c:6502: error: too few arguments to function 'build_c_cast' ../../gcc-4.4-work/gcc/objc/objc-act.c: In function 'get_super_receiver': ../../gcc-4.4-work/gcc/objc/objc-act.c:8746: error: too few arguments to function 'build_c_cast' ../../gcc-4.4-work/gcc/objc/objc-act.c:8767: error: too few arguments to function 'build_c_cast' ../../gcc-4.4-work/gcc/objc/objc-act.c:8770: error: too few arguments to function 'build_compound_expr' ../../gcc-4.4-work/gcc/objc/objc-act.c:8773: error: too few arguments to function 'build_compound_expr' make[3]: *** [objcp/objcp-act.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod gcov.pod build/genmodes.o gcj.pod fsf-funding.pod build/gengtype.o build/genchecksum.o jv-convert.pod gc-analyze.pod gfdl.pod build/gengenrtl.o cpp.pod jcf-dump.pod gij.pod gpl.pod grmic.pod gcc.pod gfortran.pod make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 This is the second time in less than a week that thefile gcc/objc/objc-act.c is forgotten in C++ changes. Would it be possible to find a way to not repeat it again? -- Summary: Bootstrap failure on i686-apple-darwin9 at revision 133519 (take 2). Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35704
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Summary|[4.3/4.4 regression] - |[4.3/4.4 Regression] - |funroll-loops breaks inline |funroll-loops breaks inline |float divide|float divide Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers
--- Comment #5 from victork at gcc dot gnu dot org 2008-03-26 10:27 --- I've managed to reproduce the problem with gcc from 4.2 branch on x86_64 machine. Note that the reduced testcase works with -m32 command line switch. -- victork at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |victork at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-11-08 14:04:26 |2008-03-26 10:27:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34006
[Bug c/35705] New: Regression: Symbol address check eliminated by C frontend.
Problem
The C frontend in GCC 4.3.1 appears to assume that the address of a function
pointer is always aligned, and optimizes away certain bitwise operations. This
breaks hppa-linux whose function pointers are either an OPD with a certain bit
set, or a plain function pointer. In GCC 4.3 hppa-linux can no longer check to
see if a function address is an OPD or not.
Background
~~~
The hppa-linux ABI supports non-OPD and OPDs. The difference is that OPDs' have
bit 2 set to 1.
The following testcase shows the change in behaviour between gcc-4_2-branch and
gcc-4_3-branch.
cat >> foo.c <
#include
int main (void) {
printf ("&printf = %x\n", (unsigned long)&printf);
if (((unsigned long) &printf) & 3)
{
printf ("printf is an OPD (PLABEL32)\n");
}
return 0;
}
EOF
[EMAIL PROTECTED]:~/fsrc/gcc-work$
/usr/local/tools/bin/hppa-linux-gcc-4.2.4 -o foo foo.c
[EMAIL PROTECTED]:~/fsrc/gcc-work$ ./foo
&printf = 119ea
printf is a PLABEL32
[EMAIL PROTECTED]:~/fsrc/gcc-work$
/usr/local/tools/bin/hppa-linux-gcc-4.3.1 -o foo foo.c
[EMAIL PROTECTED]:~/fsrc/gcc-work$ ./foo
&printf = 119ea
GCC 4.3, even at -O0, reduces "((unsigned long) &printf) & 3)" to "0".
~~~ foo.c.003t.original ~~~
;; Function main (main)
;; enabled by -tree-original
{
printf ((const char * restrict) (char *) "&printf = %x\n", (long
unsigned int) printf);
if (0)
{
printf ((const char * restrict) (char *) "printf is a PLABEL32\n");
}
return 0;
}
~~~
If the if condition is reduced to "0" as early as 003t.original, does
that mean it's the C frontend fault?
This issue is breaks glibc's detection of PLABEL32 symbols during startup
relocation processing. It also likely breaks unwind code in libjava.
Casting a pointer to an integer type is implementation defined, so the above
change is certainly a regression.
Why this didn't show up in the testing is another issue. Perhaps we just don't
have a test for this (I can correct that pretty easily).
Any ideas how to fix this? Pointers to the change that changed the behaviour?
--
Summary: Regression: Symbol address check eliminated by C
frontend.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlos at codesourcery dot com
GCC build triplet: hppa-linux
GCC host triplet: hppa-linux
GCC target triplet: hppa-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #2 from nickc at redhat dot com 2008-03-26 12:29 --- Created an attachment (id=15380) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15380&action=view) Do not allow INT+INT as a legitimate addressing mode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #3 from nickc at redhat dot com 2008-03-26 12:30 --- Hi Mike, The attached patch takes care of this. I will be applying it shortly. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #4 from nickc at gcc dot gnu dot org 2008-03-26 12:33 --- Subject: Bug 31232 Author: nickc Date: Wed Mar 26 12:32:22 2008 New Revision: 133598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133598 Log: PR target/31232 * config/stormy16/stormy16.c (xstormy16_legitimate_address_p): Do not allow INT+INT as a legitimate addressing mode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/stormy16/stormy16.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-26 12:45 --- This is caused by 2007-09-23 Ollie Wild <[EMAIL PROTECTED]> * fold-const.c (fold_binary): Fold BIT_AND_EXPR's with a pointer operand. (get_pointer_modulus_and_residue): New function. so I suppose you want to disable this optimization for addresses of functions. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.0 Known to work||4.2.3 Last reconfirmed|-00-00 00:00:00 |2008-03-26 12:45:51 date|| Summary|Regression: Symbol address |[4.3/4.4 Regression] Symbol |check eliminated by C |address check eliminated by |frontend. |C frontend. Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug c++/35332] [4.1/4.2/4.3/4.4 regression] Broken diagnostics for builtins
--- Comment #3 from jakub at gcc dot gnu dot org 2008-03-26 13:04 ---
Subject: Bug 35332
Author: jakub
Date: Wed Mar 26 13:03:30 2008
New Revision: 133600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133600
Log:
PR c++/35332
* error.c (dump_expr): Pass {,UN}ORDERED_EXPR, UN{LT,LE,GT,GE,EQ}_EXPR
and LTGT_EXPR to pp_expression.
* g++.dg/other/error27.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/other/error27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
[Bug c++/35332] [4.1/4.2/4.3/4.4 regression] Broken diagnostics for builtins
--- Comment #4 from jakub at gcc dot gnu dot org 2008-03-26 13:08 ---
Subject: Bug 35332
Author: jakub
Date: Wed Mar 26 13:07:24 2008
New Revision: 133601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133601
Log:
PR c++/35332
* error.c (dump_expr): Pass {,UN}ORDERED_EXPR, UN{LT,LE,GT,GE,EQ}_EXPR
and LTGT_EXPR to pp_expression.
* g++.dg/other/error27.C: New test.
Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/other/error27.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/error.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
[Bug c++/35332] [4.1/4.2/4.3/4.4 regression] Broken diagnostics for builtins
--- Comment #5 from jakub at gcc dot gnu dot org 2008-03-26 13:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #10 from jakub at gcc dot gnu dot org 2008-03-26 13:15 --- Joseph, do you have that build_unary_op patch still around? If that patch didn't cause any regressions but OpenMP, I could look at tweaking OpenMP... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #2 from carlos at codesourcery dot com 2008-03-26 13:33 --- Created an attachment (id=15381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15381&action=view) Regression test for bitwise operations on PLABEL32 address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #3 from carlos at codesourcery dot com 2008-03-26 13:34 --- Dave, What do you think of the attached regression test? Is this the right way to test for this behaviour? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug other/35618] [4.3 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #7 from bunk at stusta dot de 2008-03-26 13:54 --- Bug seems to be no longer present with svn HEAD. Bug is still present in 4.3 as of 4.3-20080320. -- bunk at stusta dot de changed: What|Removed |Added Status|WAITING |UNCONFIRMED Summary|[4.3/4.4 regression] ICE in |[4.3 regression] ICE in |cgraph_estimate_size_after_i|cgraph_estimate_size_after_i |nlining, at ipa-inline.c:188|nlining, at ipa-inline.c:188 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #4 from jakub at gcc dot gnu dot org 2008-03-26 13:41 --- If so, then the PA backend is lying with the definition of FUNCTION_BOUNDARY... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug bootstrap/35706] New: [4.4 Regression]: Gcc failed to bootstrap
Gcc 4.4 revision 133605 failed to bootstrap on Fedora 8 at stage 2: cc1: warnings being treated as errors insn-emit.c: In function gen_cmpdi_ccno_1_rex64: insn-emit.c:37: error: implicit declaration of function gen_rtx_SET insn-emit.c:40: error: implicit declaration of function gen_rtx_COMPARE insn-emit.c:42: error: return makes pointer from integer without a cast Many macros are changed at stage 2: bash-3.2$ diff -up prev-gcc/genrtl.h gcc --- prev-gcc/genrtl.h 2008-03-26 06:40:15.0 -0700 +++ gcc/genrtl.h2008-03-26 06:42:38.0 -0700 @@ -234,343 +234,343 @@ extern rtx gen_rtx_fmt_Ee_stat (RTX_COD gen_rtx_fmt_Ee_stat (c, m, p0, p1 MEM_STAT_INFO) -#define gen_rtx_EXPR_LIST(MODE, ARG0, ARG1) \ +#define gen_rtx_raw_EXPR_LIST(MODE, ARG0, ARG1) \ gen_rtx_fmt_ee (EXPR_LIST, (MODE), (ARG0), (ARG1)) -#define gen_rtx_INSN_LIST(MODE, ARG0, ARG1) \ +#define gen_rtx_raw_INSN_LIST(MODE, ARG0, ARG1) \ gen_rtx_fmt_ue (INSN_LIST, (MODE), (ARG0), (ARG1)) -#define gen_rtx_SEQUENCE(MODE, ARG0) \ +#define gen_rtx_raw_SEQUENCE(MODE, ARG0) \ gen_rtx_fmt_E (SEQUENCE, (MODE), (ARG0)) ... Revision 133533 is OK. -- Summary: [4.4 Regression]: Gcc failed to bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug bootstrap/35706] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #1 from dominiq at lps dot ens dot fr 2008-03-26 14:05 --- Confirmed on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug bootstrap/35706] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-26 14:06 --- I started regression hunt. I suspect this patch http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01572.html is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug bootstrap/35706] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #3 from hjl dot tools at gmail dot com 2008-03-26 14:08 ---
I think this function
/* Return nonzero if the RTL code given by index IDX is one that we should
generate a gen_rtx_raw_FOO macro for, not gen_rtx_FOO (because gen_rtx_FOO
is a wrapper in emit-rtl.c). */
static int
special_rtx (int idx)
{
return (strcmp (defs[idx].enumname, "CONST_INT") == 0
|| strcmp (defs[idx].enumname, "REG") == 0
|| strcmp (defs[idx].enumname, "SUBREG") == 0
|| strcmp (defs[idx].enumname, "MEM") == 0
|| strcmp (defs[idx].enumname, "CONST_VECTOR") == 0);
}
in gengenrtl.c is miscompiled at stage 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #5 from nickc at redhat dot com 2008-03-26 14:16 ---
Subject: Re: Problem while compiling gcc for mn10300-elf
Hi Jeff,
> What does CLASS, MODE and IN look like?
Err, presumably you are talking about these values when
default_secondary_reload() triggers the abort ?
The CLASS is DATA_OR_EXTENDED_REGS.
The MODE is SImode.
IN looks like this:
(plus:SI (reg/f:SI 9 sp)
(const_int 1100 [0x44c]))
> And more interesting, what are
> all the forms IN, CLASS & MODE might be at this point?
Hmm, well I only ever saw this problem for the case in
mn10300_secondary_reload_class() that handles additions to the stack
pointer, so I think that we can say that IN will always be:
(plus (reg sp) (...))
or (plus (...) (reg sp))
CLASS is going to be DATA_REGS or DATA_OR_EXTENDED_REGS depending upon
whether we are compiling for an AM33 or an MN10300. (I have seen the
problem for both targets). MODE I assume will always be SImode. Do we
ever make stack adjustments in other modes ?
> Given the way
> the code is written, we must have thought one particular case required a
> secondary register that was a DATA_REG, presumably because an
> ADDRESS_REG wouldn't work. Your change would likely break that case.
I think it was because the stack adjustment was too large for it to be
handled as part of the addressing mode, and so a data reg was needed in
order to be able to perform the arithmetic on the stack pointer.
> It's also unclear to me that this really solves the problem as opposed
> to just papering over the problem.
Well the other approach it seems to me would be to change the class of
the scratch register in the reload_insi pattern to be "=dx&" in order to
match the possible register classes returned by
mn10300_secondary_reload_class(). I did not try this as I was worried
about changing a pattern that is going to influence a lot of other code
generation, not just stack adjustments.
> Aren't DATA_OR_EXTENDED_REGS and DATA_REGS subclasses of GENERAL_REGS
Yes
> and thus ought to work just fine given the constraints of reload_insi's
> clobber operand? "=&r"
No because the assert at line 649 of targhooks.c says that the class of
the scratch register must be the same as the class from which we are
choosing a secondary reload register. But the class of the
reload_insi's clobbered operand is GENERAL_REGS whereas the class from
which we are selecting a register is DATA_OR_EXTENDED_REGS. I agree
that this class is a subset of GENERAL_REGS, but the assert does not
allow for this. Maybe it should, but I was very loath to change a piece
of generic reload code for what seemed to be a MN10300 specific problem.
I interpreted the assert as saying "if this assert is triggered, the
target has a discrepancy between the register class returned by
SECONDARY_RELOAD_CLASS and the reload_{in|out} pattern for that
target".
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug fortran/35707] New: Search /usr/local/include and /usr/include for .mod files
Other compilers such as g95, NAG f95 and ifort also search /usr/local/include and /usr/include for .mod files (and "INCLUDE"d files). I think gfortran should do the same, especially since #include searches these paths and "man gfortran"'s -Idir description implies #include and include search the same directories. g95 seems to use libcpp for reading almost all files and thus it searches also in /usr/include (cpp_create_reader, cpp_read_main_file etc.). That way one could also cpp-preprocess files included via "INCLUDE" rather than via "#include". The system include path is in the variable GCC_INCLUDE_DIR, which does not seem to be used outside of cpp unless I missed something. For CPP work, see wiki: http://gcc.gnu.org/wiki/GFortran44 -- Summary: Search /usr/local/include and /usr/include for .mod files Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug bootstrap/35706] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-26 15:07 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug bootstrap/35704] Bootstrap failure on i686-apple-darwin9 at revision 133519 (take 2).
--- Comment #1 from joseph at codesourcery dot com 2008-03-26 15:08 --- Subject: Re: New: Bootstrap failure on i686-apple-darwin9 at revision 133519 (take 2). On Wed, 26 Mar 2008, dominiq at lps dot ens dot fr wrote: > This is the second time in less than a week that thefile gcc/objc/objc-act.c > is > forgotten in C++ changes. Would it be possible to find a way to not repeat it > again? The basis on which ObjC++ support was accepted for inclusion in GCC was that it need not be tested when making C++ changes, reflecting "the expectation that Apple will be largely responsible for the maintenance of Objective-C++". http://gcc.gnu.org/ml/gcc/2004-06/msg00818.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35704
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-03-26 15:11 --- Created an attachment (id=15382) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15382&action=view) build_unary_op patch There may well be other regressions with this patch (in particular the vector ones may appear with this patch as well); I stopped testing when the OpenMP failures appeared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #5 from carlos at codesourcery dot com 2008-03-26 15:28 --- Jakub, Would changing FUNCTION_BOUNDARY to something less than a word alignment have disastrous results e.g. unaligned function start addresses? Functions should continue to be aligned at word boundaries. The address of a function has nothing to do with the location of the actual function code. In this case the address of the function is an OPD, and such an address requires special bits to be set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #6 from wilson at tuliptree dot org 2008-03-26 16:37 --- Subject: Re: [4.3/4.4 Regression] Symbol address check eliminated by C frontend. jakub at gcc dot gnu dot org wrote: > --- Comment #4 from jakub at gcc dot gnu dot org 2008-03-26 13:41 --- > If so, then the PA backend is lying with the definition of > FUNCTION_BOUNDARY... PA uses function descriptors like Itanium. A function pointer is actually a pointer to a descriptor, and the alignment of the descriptor has nothing at all to do with FUNCTION_BOUNDARY. Also, consider the arm/thumb and mips/mips16 cases, where we distinguish between the different types of functions by using the otherwise unused low order bits of the address. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug c/35430] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-26 17:38 --- This is a front-end issue. C++ calls it at: 3952 /* Do not warn if the comparison is an equality operation, 3953 the unsigned quantity is an integral constant and it does 3954 not use the most significant bit of result_type. */ 3955 else if ((resultcode == EQ_EXPR || resultcode == NE_EXPR) 3956 && ((op0_signed && TREE_CODE (orig_op1) == INTEGER_CST 3957&& int_fits_type_p (orig_op1, c_common_signed_type 3958(result_type))) While C does: 8499 /* Do not warn if the comparison is an equality operation, 8500 the unsigned quantity is an integral constant, and it 8501 would fit in the result if the result were signed. */ 8502 else if (TREE_CODE (uop) == INTEGER_CST 8503 && (resultcode == EQ_EXPR || resultcode == NE_EXPR) 8504 && int_fits_type_p 8505 (uop, c_common_signed_type (result_type))) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
[Bug c/35430] [4.1/4.2/4.3/4.4 regression] ICE with complex arithmetic
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-26 17:39 --- I am going to fix this bug but not until tonight. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-03-15 01:28:20 |2008-03-26 17:39:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-03-26 18:34 --- I think the same is true with PPC64-Linux and AIX with function descriptors there too. Though there is only OPDs function pointers. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug c++/35708] New: jump to label enters catch block
uname -a
SunOS neron 5.9 Generic_112233-08 sun4u sparc SUNW,Sun-Fire-480R
g++ --version
g++ (GCC) 4.2.1
the following program fails with the error
=== zot.cc =
int alloccount = 100;
struct object { int one_o; int allocstamp; };
struct gcv_object_t {
int one_o;
/* Conversion to object. */
operator object () const;
/* Conversion from object. */
gcv_object_t (object obj);
/* Conversion from fake_gcv_object. */
gcv_object_t (struct fake_gcv_object obj);
/* Uninitialized object. */
gcv_object_t ();
};
static inline int pgci_pointable (object obj) {
return obj.one_o;
}
static inline int pgci_pointable (gcv_object_t obj) {
return obj.one_o;
}
gcv_object_t STACK[1];
int main (int argc, char *argv[]) {
check_rehash_size: {
if ((pgci_pointable(STACK[0]) ==
pgci_pointableobject){one_o:(((int)(int)(((0 << 3) + 7UL)) << 0) +
((int)(int)(0) << 7)), allocstamp: alloccount}) {
bad_rehash_size:
goto check_rehash_size;
}
goto bad_rehash_size;
}
}
=== zot.cc =
$ g++ -c zot.cc
zot.cc: In function 'int main(int, char**)':
zot.cc:30: error: jump to label 'bad_rehash_size'
zot.cc:33: error: from here
zot.cc:29: error: enters catch block
I don't see any catch blocks here.
thanks.
--
Summary: jump to label enters catch block
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sds at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-26 18:30 --- Subject: Re: [4.3/4.4 Regression] Symbol address check eliminated by C frontend. > If so, then the PA backend is lying with the definition of > FUNCTION_BOUNDARY... Don't see how this matters as function pointers in the hppa runtime don't generally point at the entry point of the function. There are function descriptors and import/export stubs to traverse before you get to the function itself. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug c/35709] New: severe perfromance degradation with "float complex" type
Compiling and running the same test case with gcc-4.2.3 and gcc-4.3.0 shows that in the latter case performance takes an almost 3x hit: " [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave> /maxtor5/sergei/AppsFromScratchWD/install/gcc-4.2.3/binsh/gcc -Wall -mtune=native -march=native -O2 -msse -lm complex_multiplication_testcase.c -o complex_multiplication_testcase [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave> time ./complex_multiplication_testcase executions of straightforward_multiply_with_ptrs() took 6.77 seconds at line number 136 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply() took 6.74 seconds at line number 154 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply_2_signals() took 8.62 seconds at line number 172 of 'complex_multiplication_testcase.c' file real0m22.326s user0m22.121s sys 0m0.012s [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave> /maxtor5/sergei/AppsFromScratchWD/install/gcc-4.3.0/binsh/gcc -Wall -mtune=native -march=native -O2 -msse -lm complex_multiplication_testcase.c -o complex_multiplication_testcase [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave> time ./complex_multiplication_testcase executions of straightforward_multiply_with_ptrs() took 18.17 seconds at line number 136 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply() took 16.91 seconds at line number 154 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply_2_signals() took 30.64 seconds at line number 172 of 'complex_multiplication_testcase.c' file real1m6.306s user1m5.676s sys 0m0.056s [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave> " - see, for example, executions of straightforward_multiply() took 6.74 seconds vs executions of straightforward_multiply() took 16.91 seconds and user0m22.121s vs user1m5.676s . FWIW, gcc-3.4.6 shows comparable to gcc-4.2.3 results, albeit slightly worse, so it looks like the issue is very much gcc-4.3.0 specific. I'll upload the test case. -- Summary: severe perfromance degradation with "float complex" type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: i686-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=35709
[Bug c/35709] severe perfromance degradation with "float complex" type
--- Comment #1 from sergstesh at yahoo dot com 2008-03-26 19:23 --- Created an attachment (id=15383) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15383&action=view) the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with "float complex" type
--- Comment #2 from sergstesh at yahoo dot com 2008-03-26 19:40 --- My system: Linux amdam2 2.6.18.8-0.9-default #1 SMP Sun Feb 10 22:48:05 UTC 2008 i686 athlon i386 GNU/Linux - SUSE 10.2, the CPU is: "AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ stepping 02". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug testsuite/35710] New: FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
On powerpc-apple-darwin* we have the following failures (among others):
FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors)
This can be fixed by the following patch (borrowed from
gcc/testsuite/gcc.dg/pr26427.c):
diff -u /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/section-anchors-pr27770.c
/opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/vect/section-anchors-pr27770.c
--- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/section-anchors-pr27770.c
2007-11-07 10:20:18.0 +0100
+++ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/vect/section-anchors-pr27770.c
2008-03-26 18:46:12.0 +0100
@@ -1,3 +1,4 @@
+/* { dg-warning "this target does not support" "" { target {
powerpc-apple-darwin* } } 1 } */
/* { dg-require-effective-target section_anchors } */
#include
diff -u /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c
/opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c
--- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c
2007-11-07 10:20:17.0 +0100
+++ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/vect/section-anchors-vect-69.c
2008-03-26 18:45:01.0 +0100
@@ -1,3 +1,4 @@
+/* { dg-warning "this target does not support" "" { target {
powerpc-apple-darwin* } } 1 } */
/* { dg-require-effective-target section_anchors } */
#include
This fix the failures on powerpc-apple-darwin9 without regression on
i686-apple-darwin9. Note that I am not sure that '"" { target {
powerpc-apple-darwin* } } 1' is really needed. Could someone has a look before
I submit a patch?
--
Summary: FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for
excess errors)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710
[Bug c++/35711] New: bad text in -Wcast-qual warning (forgets volatile)
The text of the warning below is incorrect and misleading -- the cast
actually casts away the volatile qualifier, not constness. The warning
is misleading when the type of the source is both const and volatile
qualified.
$ cat t.cpp && g++ -c -Wcast-qual t.cpp
int* foo (volatile int *p)
{
return (int*)p;
}
t.cpp: In function int* foo(volatile int*):
t.cpp:3: warning: cast from type volatile int* to type int* casts away
constness
--
Summary: bad text in -Wcast-qual warning (forgets volatile)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35711
[Bug bootstrap/35704] Bootstrap failure on i686-apple-darwin9 at revision 133519 (take 2).
--- Comment #2 from dominiq at lps dot ens dot fr 2008-03-26 20:32 --- The patch in http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01497.html allowed to bootstrap again on i686-apple-darwin9 and g++ regtested without regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35704
[Bug middle-end/35709] severe perfromance degradation with "float complex" type
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-26 20:33 --- This was an intentional change for correctness. 4.3 uses the library implementation to handle the case of NaNs correctly. Use -fcx-limited-range if you want back the performance. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c++/35546] [4.3/4.4 Regression] __attribute__(format...) broken for members of template classes?
--- Comment #5 from jakub at gcc dot gnu dot org 2008-03-26 20:35 --- Subject: Bug 35546 Author: jakub Date: Wed Mar 26 20:34:14 2008 New Revision: 133615 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133615 Log: PR c++/35546 * pt.c (apply_late_template_attributes): Don't call tsubst on first attribute argument if it is IDENTIFIER_NODE. * g++.dg/ext/attrib33.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/attrib33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35546
[Bug c++/35546] [4.3/4.4 Regression] __attribute__(format...) broken for members of template classes?
--- Comment #6 from jakub at gcc dot gnu dot org 2008-03-26 20:37 --- Subject: Bug 35546 Author: jakub Date: Wed Mar 26 20:36:50 2008 New Revision: 133616 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133616 Log: PR c++/35546 * pt.c (apply_late_template_attributes): Don't call tsubst on first attribute argument if it is IDENTIFIER_NODE. * g++.dg/ext/attrib33.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/attrib33.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35546
[Bug c++/35708] jump to label enters catch block
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-26 20:39 --- I think this is invalid, you are entering a scope that has objects constructed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c++/35708] jump to label enters catch block
--- Comment #2 from sds at gnu dot org 2008-03-26 20:44 --- so? the objects are created, used and discarded on the fly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35708
[Bug c/35709] severe perfromance degradation with "float complex" type
--- Comment #4 from sergstesh at yahoo dot com 2008-03-26 20:44 --- (In reply to comment #3) > This was an intentional change for correctness. 4.3 uses the library > implementation to handle the case of NaNs correctly. Use -fcx-limited-range > if you want back the performance. > Well, I'm using "float complex" for real time audio, so correctness of NaNs is not an issue. I think the default should have been the opposite. Why to break existing applications ? When "float" rather than "double" is used, it's most likely for non-sicentific needs, so correctness in canse of NaNs most likely isn't an issue. -- sergstesh at yahoo dot com changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with "float complex" type
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-03-26 20:45 --- As mentioned, use -fcx-limited-range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with "float complex" type
--- Comment #6 from sergstesh at yahoo dot com 2008-03-26 20:58 --- (In reply to comment #5) > As mentioned, use -fcx-limited-range. > Can't you add just _one_ command line switch: -old_behavior ? Or -gcc_4_2_3_behavior ? For example, I need FFTW3 with "float" rather than "double", and I need its speed. I am not sure FFTW3 'configure' will add -fcx-limited-range. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
--- Comment #10 from tobi at gcc dot gnu dot org 2008-03-26 21:09 --- A lovely design by committee feature that is. An alternative implementation strategy would be to use the same calling convention as for pass-by-reference arguments and then copy on entry (if present, and as an optimization, only if it is indeed written to in the procedure body). -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203
[Bug bootstrap/35706] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-26 21:16 --- It is actually VRP that is confused: : # iftmp.10_86 = PHI <&"raw_"[0](37), &""[0](40), &"raw_"[0](83), &"raw_"[0](41), &"raw_"[0](39), &"raw_"[0](38)> - printf (&"#define gen_rtx_%s%s(MODE"[0], iftmp.10_86, D.4658_79); + printf (&"#define gen_rtx_%s%s(MODE"[0], &"raw_"[0], D.4658_79); -D.4342_1: ~[0B, 0B] +D.4342_1: [&"int "[0], &"struct basic_block_def *"[0]] huhm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug fortran/35019] Gfortran does not support "-J " only "-J"
--- Comment #4 from burnus at gcc dot gnu dot org 2008-03-26 21:34 --- This does not seem to work. While "-M ." indeed passes "." to gfc_handle_module_path_options, "-M." becomes the option "-M." which is not recognized. On the other hand: "-J." is passed as "." while "-J ." passes "-fintrinsic-modules-path" which is wrong. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35019
[Bug fortran/35702] [4.4, 4.3 regression]: structure character element with subscripts
--- Comment #3 from pault at gcc dot gnu dot org 2008-03-26 21:38 ---
> If I would hazard a guess, something is going wrong in
> trans-expr.c(gfc_trans_string_copy), where LEN=1 is treated separately.
Yes, this is correct. In this particular case, we have:
lhs => (void *) &(*(character(kind=1)[0:][1:1] *) atmp.4.data)[S.5]
rhs => (void *) &(*tda1l.0)[(S.5 + 1) * D.590 + D.578].c[1]{lb: 1 sz: 1}
which will clearly run afoul of the check in trans.c. Rather than mess around
casting and uncasting the rhs, which I know from experience is a pain in the
posterior, I propose the following:
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 133278)
--- gcc/fortran/trans-expr.c(working copy)
***
*** 2857,2864
if (dlength != NULL_TREE && POINTER_TYPE_P (TREE_TYPE (dest)))
dsc = gfc_to_single_character (dlen, dest);
!
! if (dsc != NULL_TREE && ssc != NULL_TREE)
{
gfc_add_modify_expr (block, dsc, ssc);
return;
--- 2840,2848
if (dlength != NULL_TREE && POINTER_TYPE_P (TREE_TYPE (dest)))
dsc = gfc_to_single_character (dlen, dest);
! /* Assign directly if the types are compatible. */
! if (dsc != NULL_TREE && ssc != NULL_TREE
! && TREE_TYPE (dsc) == TREE_TYPE (ssc))
{
gfc_add_modify_expr (block, dsc, ssc);
return;
It does not produce the most efficient code for this case but is guaranteed to
work. This has just gone on to regtest.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35702
[Bug bootstrap/35706] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-26 21:51 --- Hm, fold_binary_to_constant (LT_EXPR, boolean_type_node, &"raw_"[0], &""[0]) returns "raw_" < "" (which has TREE_CONSTANT set). tree-vrp.c:operand_less_p doesn't expect that, but only expects 0 or non-0: tcmp = fold_binary_to_constant (LT_EXPR, boolean_type_node, val, val2); if (!tcmp) return -2; if (!integer_zerop (tcmp)) return 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35706
[Bug fortran/35698] lbound and ubound wrong for allocated run-time zero size array
--- Comment #2 from pault at gcc dot gnu dot org 2008-03-26 22:20 --- This one is relatively easy: Index: gcc/fortran/trans-array.c === *** gcc/fortran/trans-array.c (revision 133278) --- gcc/fortran/trans-array.c (working copy) *** gfc_conv_loop_setup (gfc_loopinfo * loop *** 3506,3512 a.ubound[n] = specified_upper_bound; a.stride[n] = stride; size = ubound + size; //size = ubound + 1 - lbound ! stride = stride * size; } return (stride); } */ --- 3516,3522 a.ubound[n] = specified_upper_bound; a.stride[n] = stride; size = ubound + size; //size = ubound + 1 - lbound ! stride = size >= 0 ? stride * size : 0; } return (stride); } */ *** gfc_array_init_size (tree descriptor, in *** 3605,3610 --- 3615,3623 else or_expr = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, or_expr, cond); + size = fold_build3 (COND_EXPR, gfc_array_index_type, cond, + size, gfc_index_zero_node); + /* Multiply the stride by the number of elements in this dimension. */ stride = fold_build2 (MULT_EXPR, gfc_array_index_type, stride, size); stride = gfc_evaluate_now (stride, pblock); I'll put it on to regtest. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-25 23:52:07 |2008-03-26 22:20:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35698
[Bug c/35709] severe perfromance degradation with "float complex" type
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-26 22:22 --- I would suggest for real time audio you should use -ffast-math which will enable -fcx-limited-range as well. It also disables generally handling of NaNs, Infs and other optimization limiting things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
--- Comment #1 from ubizjak at gmail dot com 2008-03-26 22:55 ---
(In reply to comment #0)
> On powerpc-apple-darwin* we have the following failures (among others):
>
> FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
> FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors)
>
> This can be fixed by the following patch (borrowed from
> gcc/testsuite/gcc.dg/pr26427.c):
> /* { dg-require-effective-target section_anchors } */
Perhaps a better fix would be to exclude darwin from the list of supported
targets in procedure check_effective_target_section_anchors in
testsuite/lib/target-supports.exp?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-26 22:55 --- Subject: Re: [4.3/4.4 Regression] Symbol address check eliminated by C frontend. > so I suppose you want to disable this optimization for addresses of functions. Something like the following? Index: fold-const.c === --- fold-const.c(revision 133621) +++ fold-const.c(working copy) @@ -9065,7 +9065,7 @@ } } - if (DECL_P (expr)) + if (DECL_P (expr) && TREE_CODE (expr) != FUNCTION_DECL) return DECL_ALIGN_UNIT (expr); } else if (code == POINTER_PLUS_EXPR) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug tree-optimization/35653] [4.3/4.4 Regression]: gcc-4.3 -O3/-ftree-vectorize regression: incorrect code generation
--- Comment #17 from davids at webmaster dot com 2008-03-26 22:56 --- I wonder why -Wcast-align doesn't generate a warning in this case. It would seem that would be what it's for. I get a segfault in the reduced test case and no warning from -Wcast-align. The documentation seems to specifically suggest that this is the case where a warning is generated. -- davids at webmaster dot com changed: What|Removed |Added CC||davids at webmaster dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35653
[Bug middle-end/35705] [4.3/4.4 Regression] Symbol address check eliminated by C frontend.
--- Comment #10 from rguenther at suse dot de 2008-03-26 22:57 --- Subject: Re: [4.3/4.4 Regression] Symbol address check eliminated by C frontend. On Wed, 26 Mar 2008, dave at hiauly1 dot hia dot nrc dot ca wrote: > --- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-26 > 22:55 --- > Subject: Re: [4.3/4.4 Regression] Symbol address check eliminated by C > frontend. > > > so I suppose you want to disable this optimization for addresses of > > functions. > > Something like the following? Yes. Richard. > Index: fold-const.c > === > --- fold-const.c(revision 133621) > +++ fold-const.c(working copy) > @@ -9065,7 +9065,7 @@ > } > } > > - if (DECL_P (expr)) > + if (DECL_P (expr) && TREE_CODE (expr) != FUNCTION_DECL) > return DECL_ALIGN_UNIT (expr); > } >else if (code == POINTER_PLUS_EXPR) > > Dave > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35705
[Bug tree-optimization/32810] Not folding of const element for goto
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-26 23:37 --- Useless conversions get in the way here. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-19 18:08:04 |2008-03-26 23:37:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32810
[Bug tree-optimization/21636] Missed ccp optimization
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-26 23:43 --- Mine. I am in fix-CCP mood lately. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2006-03-01 02:53:04 |2008-03-26 23:43:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21636
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-03-26 23:47 --- All testcases in this PR are fully optimized by ccp1. I think Zdenek fixed this by properly handling undefined values. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.2.3 Known to work||4.3.0 Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug c/35712] New: decimal float literal constant zero loses significant trailing zeroes
Decimal floating point types support significant trailing zeroes to specify how much precision a value has. Trailing zeroes are relevant even for values of zero; for example, rounding 1.e-11dd to 10 places after the decimal point results in 0.e-10dd. The draft Technical Report N1241 for ISO/IEC TR 24732 doesn't specify this directly, but section 9.5 "Formatted input/output specifiers" shows expected output for five different representations of zero: 0, -0, 0.00, 0e-07, and 0e+02. Currently GCC converts all decimal float literal values of zero to 0.DF, 0.DD, or 0.DL. I'm testing a patch to fix this but want a PR to record the issue. -- Summary: decimal float literal constant zero loses significant trailing zeroes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c AssignedTo: janis at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35712
[Bug target/35713] New: invalid type for va_arg with _Decimal128
Using va_arg with _Decimal128 for powerpc-linux results in an error
message followed by an ICE, resulting in several new failing GCC
tests.
This testcase:
void
foo (int n, ...)
{
__builtin_va_list ap;
_Decimal128 x;
__builtin_va_start (ap, n);
x = __builtin_va_arg (ap, _Decimal128);
__builtin_va_end (ap);
}
results in these messages:
elm3b145% /opt/gcc-nightly/trunk/bin/gcc -c va.c
va.c: In function foo:
va.c:3: error: type mismatch in binary expression
unsigned char
unsigned char
unsigned int
D.1240 = D.1239 | 1
va.c:3: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The failure becomes apparent with r133479, but it also happens with earlier
GCC sources configured with --enable-checking=types.
I plan to continue investigating this problem.
--
Summary: invalid type for va_arg with _Decimal128
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: janis at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35713
[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
--- Comment #2 from dominiq at lps dot ens dot fr 2008-03-27 00:35 --- (In reply to comment #1) > Perhaps a better fix would be to exclude darwin from the list of supported > targets in procedure check_effective_target_section_anchors in > testsuite/lib/target-supports.exp? I don't know. The tests pass all the other checks excepted: FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times vect "Alignment of access forced using peeling" 4 (I kept it for another PR), so I don't see why the tests should be excluded for darwin. The patch just prevents a warning to give a failure for "(test for excess errors)". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #6 from law at redhat dot com 2008-03-27 00:35 --- Subject: Re: Problem while compiling gcc for mn10300-elf nickc at redhat dot com wrote: > --- Comment #5 from nickc at redhat dot com 2008-03-26 14:16 --- > Subject: Re: Problem while compiling gcc for mn10300-elf > > Hi Jeff, > >> What does CLASS, MODE and IN look like? > > Err, presumably you are talking about these values when > default_secondary_reload() triggers the abort ? Yea. > > The CLASS is DATA_OR_EXTENDED_REGS. > > The MODE is SImode. > > IN looks like this: > >(plus:SI (reg/f:SI 9 sp) >(const_int 1100 [0x44c])) Hmm, so why isn't this caught by this code in secondary_reload_class: /* We can't directly load sp + const_int into a data register; we must use an address register as an intermediate. */ if (class != SP_REGS && class != ADDRESS_REGS && class != SP_OR_ADDRESS_REGS && class != SP_OR_EXTENDED_REGS && class != ADDRESS_OR_EXTENDED_REGS && class != SP_OR_ADDRESS_OR_EXTENDED_REGS && (in == stack_pointer_rtx || (GET_CODE (in) == PLUS && (XEXP (in, 0) == stack_pointer_rtx || XEXP (in, 1) == stack_pointer_rtx return ADDRESS_REGS; In fact, I'm having trouble seeing why the clause which returns DATA_REGS/DATA_OR_EXTENDED_REGS exists at all. Am I being overly dense today? Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug target/35714] New: x86 poor code with pmaddwd
> /usr/local/gcc44/bin/gcc -v Using built-in specs. Target: i386-apple-darwin9.2.0 Configured with: ../gcc/configure --prefix=/usr/local/gcc44 --enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw --with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl CFLAGS=-g LDFLAGS=/usr/lib/libiconv.dylib --enable-languages=c,c++,objc Thread model: posix gcc version 4.4.0 20080326 (experimental) (GCC) > /usr/local/gcc44/bin/gcc -Os -march=core2 -fno-pic -fomit-frame-pointer > -flax-vector-conversions -S pmaddwd.c generates: _madd_swapped: subl$12, %esp movaps LC0, %xmm1 addl$12, %esp pmaddwd %xmm1, %xmm0 ret .globl _madd _madd: subl$12, %esp movaps LC0, %xmm1 addl$12, %esp pmaddwd %xmm0, %xmm1 movaps %xmm1, %xmm0 ret Both of these should be: _madd: pmaddwd LC0, %xmm0 ret since the stack isn't referenced and pmaddwd is commutative. (the variable being renamed LC0 is PR 31043) -- Summary: x86 poor code with pmaddwd Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: astrange at ithinksw dot com GCC build triplet: i386-apple-darwin9.2.0 GCC host triplet: i386-apple-darwin9.2.0 GCC target triplet: i386-apple-darwin9.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35714
[Bug target/35714] x86 poor code with pmaddwd
--- Comment #1 from astrange at ithinksw dot com 2008-03-27 01:02 --- Created an attachment (id=15384) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15384&action=view) source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35714
[Bug fortran/35699] [4.3/4.4 regression] run-time abort writing zero sized section to direct access file
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2008-03-27 05:45 --- A patch has been submitted to [EMAIL PROTECTED] for approval. http://gcc.gnu.org/ml/fortran/2008-03/msg00212.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35699
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
--- Comment #2 from wilson at tuliptree dot org 2008-03-27 05:52 --- Subject: Re: New: [4.3/4.4 regression] -funroll-loops breaks inline float divide On Tue, 2008-03-25 at 17:29 +, schwab at suse dot de wrote: > With -funroll-loops the insn that computes e = 1 - (b * y) is optimized in > cse2 > to e = 0. It seems that tree-ssa only partly unrolls and simplifies the loop. It isn't until the RTL loop optimization pass that we figure out that the entire loop disappears after unrolling. At that point, we have constant divides 1.0/1.0, 1.0/2.0, 1.0/2.0, and 1.0/3.0. Unfortunately, at RTL expansion time, we already emitted long recip approx sequences. The second cse pass tries to propagate the FP constants into the recip approx sequence and we get a mess. I think the main problem here is that the reciprocal approximation pattern is using div, which misleads the RTL optimizer into thinking that we have a divide result when we actually don't. Changing this to use an UNSPEC instead seems to solve the problem, as this prevents the cse optimization. I just fixed the one recip pattern in div.md, but the others should probably be fixed also. I only tested this with a cross compiler; I don't want to disturb the neighbors by turning my Itanium machine on this late in the evening. There is another problem here that we don't really need a long sequence to compute 1.0/2.0, but that is going to take some thought. Delaying the expansion of the recip approx sequence might help, but will probably also hurt in other cases. We do have REG_EQUAL notes at the end of the recip approx sequences, maybe we can do something with those, like pre-compute the constant divide result and place it in the constant pool. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
--- Comment #3 from wilson at gcc dot gnu dot org 2008-03-27 05:54 --- Created an attachment (id=15385) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15385&action=view) Itanium reciprocal approximation bug fix Untested patch produced with wrong (default) svn diff options. Should probably make the same change to the other recip approx patterns in ia64.md. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
