[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-03 08:14 --- Isn't this just a user error though? I mean, for -mavx we also need an assembler that supports AVX instructions, we don't have a workaround for every AVX instruction. Even if you build with -march=native on SSSE3 capable CPU (i.e. core2 or later) GCC assumes your assembler supports SSSE3. Similarly for many other recently added instructions. lvlx insn is guarded with rs6000_cpu == PROCESSOR_CELL, how that got set? Are you configuring gcc with a cell arch eventhough your assembler lacks that support? Or is testing done with those flags? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #4 from dominiq at lps dot ens dot fr 2008-11-03 08:21 --- Isn't this just a user error though? I am just running the tests. Are you configuring gcc with a cell arch eventhough your assembler lacks that support? I use: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info --build=powerpc-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib If there is something about cell, it is not visible here. Or is testing done with those flags? I don't think I have anything special for these tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug middle-end/37858] [4.3/4.4 Regression] ICE when -fdump-ipa-all -dv is used
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-10-17 06:32:56 |2008-11-03 08:27:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37858
[Bug middle-end/37858] [4.3/4.4 Regression] ICE when -fdump-ipa-all -dv is used
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-03 08:43 --- Subject: Bug 37858 Author: jakub Date: Mon Nov 3 08:42:10 2008 New Revision: 141545 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141545 Log: PR middle-end/37858 * passes.c (execute_one_pass): Don't look at cfun-curr_properties for ipa and simple ipa passes. * gcc.dg/pr37858.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr37858.c Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37858
[Bug middle-end/37858] [4.3 Regression] ICE when -fdump-ipa-all -dv is used
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-03 08:48 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.2 4.4.0 |4.3.2 Known to work|4.1.2 4.2.4 |4.1.2 4.2.4 4.4.0 Summary|[4.3/4.4 Regression] ICE|[4.3 Regression] ICE when - |when -fdump-ipa-all -dv is|fdump-ipa-all -dv is used |used| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37858
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-03 09:07 --- Created an attachment (id=16615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16615action=view) gcc44-pr37812.patch Ah, I see, it is a testsuite bug then. altivec_check.h uses the lvlx insns inside of inline assembly unconditionally. There is no reason for that if not -mcpu=cell and when -mcpu=cell is used, the user and/or testcase should better make sure the assembler supports cell. Which leads to another bug, we need a new target-supports tcl function and guard all the -mcpu=cell tests with it (say powerpc_cell_ok or powerpc_ppu_ok, which would imply powerpc_altivec_ok and that these insns can be assembled). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug c++/38000] New: System header files not found once -isystem /usr/include is used
$ cat test.cpp #include cstdlib $ g++ -c -isystem /usr/include test.cpp In file included from test.cpp:1: /usr/include/c++/4.3/cstdlib:73:25: error: stdlib.h: No such file or directory ... This happens on two different system with 4.3.1 and 4.3.2. See also http://gcc.gnu.org/ml/gcc-help/2008-10/msg00338.html -- Summary: System header files not found once -isystem /usr/include is used Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jensseidel at users dot sf dot net GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug c/32643] [4.2/4.3/4.4 Regression] Wrong error message with unsigned char a = uchar512
--- Comment #9 from manu at gcc dot gnu dot org 2008-11-03 10:40 --- Andrew, what is the status of this? Joseph, Will this be fixed by your new code for 4.5? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
[Bug c++/23287] [4.2/4.3/4.4 regression] Explicitly invoking destructor of template class in a template and is dependent
--- Comment #21 from manu at gcc dot gnu dot org 2008-11-03 10:46 --- Nathan, are you working on this? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-03 11:02 --- The patch in comment #4 generate a lot of bus errors in my tests. Looking at it, I think there is something missing: gfc_current_ns-old_cl_list is only set to NULL, it should likely be set to gfc_current_ns-cl_list somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug libstdc++/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-03 12:41 --- 4.1.x used just #include, not #include_next in cstdio to include stdio.h, so I guess this is libstdc++-v3 regression, not driver. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Component|driver |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug target/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|hp at gcc dot gnu dot org |jakub at gcc dot gnu dot org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00063.html Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug c/38001] New: regression in 4.3: alignment checks wrongly optimized away (runtime failure)
For mpg123 I use __attribute__((aligned(16))) for variables that are possibly used by SSE code. Now, I also create a library containing that SSE code, which can be used from third party applications. The use case of linking gcc-compiled mpg123 code with another compiler that did _not_ align the stack at 16 bytes lead to the implementation of a runtime alignment check in the toplevel API calls of the library. I stripped this down to the example I am about to attach. Please note that I observed the issue in my library code first, so it should not be bound to problems with the stack in main() -- though the example has the code in main(). Basic code fragment: double __attribute__((aligned(16))) altest[1]; double __attribute__((aligned(16))) altest2[1]; if((size_t)altest % 16 != 0 || (size_t)altest2 % 16 != 0) printf(not aligned with %!\n); If the stack from the caller is not proper, I expected this check to fire. Now a specific user who had -mpreferred-stack-boundary=2 in his CFLAGS pointed me to reinvestigate the matter: Since that option apparently overrides the __attribute__((aligned(16))) (a bug or misfeature on its own, IMHO), the user encountered a segfault on using the misaligned memory in SSE code. That made me realize that I not just have to check for misaligned stack from the caller but also for the alignment working at all in one stack frame (hence, the two variables altest and altest2). Now, I updated the check and noticed that gcc-4.3.1 -mpreferred-stack-boundary=2 still produced a crashing program instead of triggering the check at runtime. I compared with gcc-3.3.6 and gcc-3.4.6; both versions correctly detected the bad alignment at runtime and stopped in a controlled way. This led to investigations with the stripped down code. Results: 1. gcc-4.3.1 optimizes away the altest % 16 or altest 15 to plain zero, under the wrong assumption that the alignment to 16 bytes works. 2. consequently, the if(altest % 16 != 0 ...) check is totally optimized away -- even with -O0! 2. additonally, the 15 check is miscompiled by gcc-3.4.6: it boils down to and $0x1,%eax instead of and $0xf,%eax ...please see the attached files, with disassembly. This is inconsistent, even... Actually, I am not sure how many bugs I am raising here. The main point is: GCC should not omptimize away a computation which has an unknown result at compile time -- or at least take into account that it actually does so against it's own actions that render the predicted result invalid (align the stack at a different boundary). Footnote: I know that it is a bad idea to have -mpreferred-stack-boundary=2 in this case, but this shows that the check is miscompiled and that insight also applies to the correctly compiled library being linked with other code that aligns stack differently. -- Summary: regression in 4.3: alignment checks wrongly optimized away (runtime failure) Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de 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=38001
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #1 from thomas dot orgis at awi dot de 2008-11-03 13:26 --- Created an attachment (id=16617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16617action=view) tar with the test source file, script to test the bug, example disassembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-03 13:31 --- The check is not miscompiled, gcc assumes __attribute__((aligned (16))) variables are 16 bytes aligned and uses this everywhere, including optimizing out unnecessary check. This is a user bug, you simply should never call -mpreferred-stack-boundary=4 routines from -mpreferred-stack-boundary=2 compiled code. GCC documentation even warns against this. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug driver/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-03 12:25 --- appending -v shows /usr/lib64/gcc/x86_64-suse-linux/4.3/cc1plus -quiet -v -D_GNU_SOURCE t.C -quiet -dumpbase t.C -mtune=generic -auxbase t -version -o t.s #include ... search starts here: #include ... search starts here: /usr/include/c++/4.3 /usr/include/c++/4.3/x86_64-suse-linux /usr/include/c++/4.3/backward /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.3/include /usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/include /usr/include End of search list. vs. /usr/lib64/gcc/x86_64-suse-linux/4.3/cc1plus -quiet -v -D_GNU_SOURCE -isystem /usr/include t.C -quiet -dumpbase t.C -mtune=generic -auxbase t -version -o t.s ignoring duplicate directory /usr/include #include ... search starts here: #include ... search starts here: /usr/include /usr/include/c++/4.3 /usr/include/c++/4.3/x86_64-suse-linux /usr/include/c++/4.3/backward /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/4.3/include /usr/lib64/gcc/x86_64-suse-linux/4.3/include-fixed /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/include End of search list. note the different ordering which will likely make #include_next fail? It works for me with 4.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |driver Ever Confirmed|0 |1 Known to fail||4.3.2 Known to work||4.2.4 Last reconfirmed|-00-00 00:00:00 |2008-11-03 12:25:17 date|| Summary|System header files not |[4.3/4.4 Regression] System |found once -isystem |header files not found once |/usr/include is used|-isystem /usr/include is ||used Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug c/32643] [4.2/4.3/4.4 Regression] Wrong error message with unsigned char a = uchar512
--- Comment #10 from joseph at codesourcery dot com 2008-11-03 12:58 --- Subject: Re: [4.2/4.3/4.4 Regression] Wrong error message with unsigned char a = uchar512 On Mon, 3 Nov 2008, manu at gcc dot gnu dot org wrote: Joseph, Will this be fixed by your new code for 4.5? As I said in http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01061.html, that patch does not fix this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32643
[Bug driver/38000] [4.3/4.4 Regression] System header files not found once -isystem /usr/include is used
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-03 12:39 --- The include_next doesn't make any sense in the cXXX headers, include_next is typically used when including the same header name, not when you are including unrelated header name, exactly because making assumptions whether it comes earlier or later in the search path is bad. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #3 from thomas dot orgis at awi dot de 2008-11-03 13:35 --- Are you saying that there is no way to protect my library from user programs that have misaligned stacks? The whole checking business is in vain, then? To sad that it working fine with older gccs made be believe that I do something usefule there in preventing segfaults. And: In any case, if -mpreferred-stack-boundary obviously contradicts the aligned attribute, couldn't gcc at least give a compile error on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-03 09:49 --- Updated patch with also target-supports posted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00054.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-03 09:49:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug c++/28513] [4.2/4.3/4.4 Regression] QOI: Diagnostic missing since 3.3.x when naming rule is violated
--- Comment #7 from manu at gcc dot gnu dot org 2008-11-03 10:43 --- Is this really accepts-invalid? As the original description says, a diagnostic is not even required by the standard... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
[Bug middle-end/37902] [4.3 Regression] in_system_header bug
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37902
[Bug tree-optimization/37868] [4.3 Regression] code that breaks TBAA is misoptimized even with -fno-strict-aliasing
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-11-03 09:55 --- Mine. -- 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|2008-09-18 19:14:33 |2008-11-03 09:55:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug middle-end/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537
--- Comment #9 from ubizjak at gmail dot com 2008-11-03 14:25 --- Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Component|rtl-optimization|middle-end Last reconfirmed|2008-08-30 14:05:31 |2008-11-03 14:25:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
[Bug middle-end/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537
--- Comment #10 from ubizjak at gmail dot com 2008-11-03 14:26 --- Not a RA issue. -- ubizjak at gmail dot com changed: What|Removed |Added CC|vmakarov at gcc dot gnu dot | |org | Keywords|ra | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-03 14:27 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected Does this cause a bootstrap failure anywhere, or just testsuite regressions and (ignored) gcj-dbtool failure? If the latter, this should be P4. It just causes testsuite regressions. As you note, the gcj-dbtool failure is ignored. Essentially, libgcj is broken and isn't usable. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug tree-optimization/37969] [4.3 Regression] -O2 -funswitch-loops causes ICE in build_int_cst_wide, at tree.c:891 (OpenOffice.org)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37969
[Bug c/37924] [4.2/4.3 Regression] ice in smallest_mode_for_size, at stor-layout.c:219
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37924
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-03 12:00 --- Created an attachment (id=16616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16616action=view) gcc44-pr37241.patch Please try attached testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c++/38002] New: gcc crash using -fvisibility-ms-compat
gcc version 4.3.2 (GCC) Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.2/configure --prefix=/usr/local/gcc-4.3.2 --enable-languages=c,c++ --with-gmp=/home/builder/4gcc43 --with-mpfr=/home/builder/4gcc43 --with-as=/usr/local/gcc-4.3.2/bin/as --with-gnu-as --with-ld=/usr/local/gcc-4.3.2/bin/ld --with-gnu-ld Thread model: posix system: Linux, Debian, 2.6.25 third party libraries: boost 1.33.1 command line: gcc error.cpp -I. -shared -o error.so -fvisibility-ms-compat -lstdc++ -I$BOOST_INCLUDE_DIR -save-temps gcc output: /usr/local/gcc-4.3.2/boost_1_33_1/include/boost/lexical_cast.hpp: In instantiation of 'Target boost::lexical_cast(const Source) [with Target = std::basic_stringchar, std::char_traitschar, std::allocatorchar , Source = int*]': error.cpp:6: instantiated from here /usr/local/gcc-4.3.2/boost_1_33_1/include/boost/lexical_cast.hpp:223: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. How to attach *.ii file??? -- Summary: gcc crash using -fvisibility-ms-compat Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bodzio131 at op dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38002
[Bug c++/38002] gcc crash using -fvisibility-ms-compat
--- Comment #1 from bodzio131 at op dot pl 2008-11-03 14:58 --- Created an attachment (id=16618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16618action=view) preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38002
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #3 from mikpe at it dot uu dot se 2008-11-03 13:49 --- (In reply to comment #2) Danny, I've tested the revised patch both with and without --disable-shared, and both configs build and work fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-03 15:02 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected --- Comment #13 from aph at gcc dot gnu dot org 2008-11-03 10:18 --- As a Java maintainer I'm happy to have a look at this, but I have no access to HP/UX hardware. I could provide access. However, debugging this with gdb is tricky. It can't set a breakpoint in a constructor in a shared library. There's some issue with load notifications. It's also not possible to link with -static. I'm willing to look at anything you suggest. There's a couple of other PRs related to gcj-dbtool that probably relate to this problem. The org-xml.list is one in which I see the same class registered twice (e.g., _ZN3org3xml3sax3ext14LexicalHandler6class$E). Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug middle-end/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537
--- Comment #11 from ubizjak at gmail dot com 2008-11-03 15:19 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00067.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00067.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #14 from jakub at gcc dot gnu dot org 2008-11-03 11:54 --- Does this cause a bootstrap failure anywhere, or just testsuite regressions and (ignored) gcj-dbtool failure? If the latter, this should be P4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c++/35334] [4.2/4.3/4.4 regression] Broken diagnostic for complex cast
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-03 11:04 --- I think the cannot be used as a function error should print the exact object only if it is a DECL_P, otherwise just print error: expression cannot be used as a function. Imagine if the object is a 100KB statement expression, do we want to print that? When we have to start/end location information, we'd just print a caret range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35334
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #18 from aph at redhat dot com 2008-11-03 15:12 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-03 15:02 --- Subject: Re: [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected --- Comment #13 from aph at gcc dot gnu dot org 2008-11-03 10:18 --- As a Java maintainer I'm happy to have a look at this, but I have no access to HP/UX hardware. I could provide access. However, debugging this with gdb is tricky. It can't set a breakpoint in a constructor in a shared library. There's some issue with load notifications. It's also not possible to link with -static. That doesn't matter, because it's not a runtime bug, it's a compiler bug. We have to debug the compiler. I'm willing to look at anything you suggest. There's a couple of other PRs related to gcj-dbtool that probably relate to this problem. The org-xml.list is one in which I see the same class registered twice (e.g., _ZN3org3xml3sax3ext14LexicalHandler6class$E). Okay, the question is why is cgraph_build_static_cdtor() being called twice, once from cgraph_optimize() and once from java_parse_file() ? And, if the FE should not call cgraph_build_static_cdtor(), why does the code generation fail if the call is removed ? The entire solution to this problem lies in that answer. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00068.html Status|NEW |ASSIGNED Last reconfirmed|2008-10-14 08:10:59 |2008-11-03 15:39:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-11-03 12:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #13 from aph at gcc dot gnu dot org 2008-11-03 10:18 --- As a Java maintainer I'm happy to have a look at this, but I have no access to HP/UX hardware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c++/28743] [4.2/4.3/4.4 regression] ICE with invalid specialization
--- Comment #15 from manu at gcc dot gnu dot org 2008-11-03 11:56 --- What was the problem with this patch? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #4 from tg at mirbsd dot org 2008-11-03 15:55 --- The aligned attribute is for data, not for the stack. The gcc texinfo page says that gcc does not re-align the stack once misaligned (it could do that though, or you could do that yourself). But optimising away the checks is something weâre used to from gcc4⦠-- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug c++/38002] gcc crash using -fvisibility-ms-compat
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-03 16:07 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38002
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #5 from thomas dot orgis at awi dot de 2008-11-03 16:08 --- Aren't we talking about data on the stack? And, actually gcc-4.2 can realign the stack, if you ask it to. But, well ... in any case it would be very helpful if a programmer had a way to deal devensively with stack issues for a library that is compiled separately from programs using it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-03 16:17 --- 4.2 doesn't realign stack except for main, only gcc 4.4 does and only for alignments larger than 16 bytes (and only on i386/x86_64). You can use an optimization barrier to force a check, but I think it is a bad idea to slow down a library just because users might call it with bad stack alignment, using -mpreferred-stack-boundary is an ABI switch, people who mix code with different ABIs get what they deserve. Say uintptr_t aladdr = (uintptr_t) altest; asm ( : +r (aladdr)); if ((aladdr 15) != 0) puts (stack not properly aligned); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38001
[Bug c/38003] New: ice with -O2
I just tried to compile the Suse Linux package tcpd-7.6-855.5 with gcc version 4.4.0 snapshot 20081031. percent_x.c:14: warning: 'sccsid' defined but not used percent_x.c: In function 'percent_x': percent_x.c:33: internal compiler error: in insert_into_preds_of_block, at tree-ssa-pre.c:3120 Please submit a full bug report, with preprocessed source if appropriate. Preprocessed source code attached. Flag -O2 required. -- Summary: ice with -O2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38003
[Bug c/38003] ice with -O2
--- Comment #1 from dcb314 at hotmail dot com 2008-11-03 16:31 --- Created an attachment (id=16619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16619action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38003
[Bug fortran/37999] Fortran shape and kind intrinsic
--- Comment #2 from carbess at swcp dot com 2008-11-03 16:32 --- Subject: Re: Fortran shape and kind intrinsic Thanks for the response. I will download the latest compiler, which I thought I had. I guess the autoupdate for my Mint Linux is not working promptly or this has been updated in the last two weeks. With the new version, I will check the second problem I reported as well and report back (kind intrinsic with character argument in a type declararation statement). Thanks again and appreciate you help -- you have saved me of creating a workaround for the GNU compilers for my large application code for the shape intrinsic -- the code I gave is the simplest extraction I could think of but your recommendation for this test is clearly better. - Original Message - From: kargl at gcc dot gnu dot org [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, November 02, 2008 5:00 PM Subject: [Bug fortran/37999] Fortran shape and kind intrinsic --- Comment #1 from kargl at gcc dot gnu dot org 2008-11-03 00:00 --- Code works with 4.3.2 and trunk. Note you probably want to 1) Update to a 4.3.2 or newer compiler. 2) Change the example to program test_shape integer :: i print *, size(shape(i)) ! Shape of a scalar allowed by f95 standards. end program test_shape because shape(i) is a zero sized array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37999 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37999
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #16 from aph at gcc dot gnu dot org 2008-11-03 14:45 --- Indeed. If that doesn't work, libjava is hosed on that platform. I'd like to get to the bottom of it. Should the FE be calling cgraph_build_static_cdtor() or not? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug bootstrap/36908] bootstrap forever with BOOT_CFLAGS=-O2 -ftree-loop-distribution
--- Comment #8 from spop at gcc dot gnu dot org 2008-11-03 16:36 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
[Bug c/38003] ice with -O2
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-03 16:38 --- *** This bug has been marked as a duplicate of 37976 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38003
[Bug middle-end/37976] [4.4 Regression] ICE in insert_into_preds_of_block
--- Comment #7 from jakub at gcc dot gnu dot org 2008-11-03 16:38 --- *** Bug 38003 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37976
[Bug middle-end/38002] gcc crash using -fvisibility-ms-compat
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-03 16:42 ---
Reduced testcase, not a regression.
namespace std __attribute__ ((__visibility__ (default))) {
class type_info { };
};
templateclass E
void throw_exception(E const e);
class bad_lexical_cast {
public:
bad_lexical_cast(const std::type_info target_type);
};
templatetypename Source
int lexical_cast(const Source arg)
{
throw_exception(bad_lexical_cast(typeid(Source)));
}
int i;
int test = lexical_cast( i );
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.3.0
Last reconfirmed|-00-00 00:00:00 |2008-11-03 16:42:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38002
[Bug bootstrap/36908] bootstrap forever with BOOT_CFLAGS=-O2 -ftree-loop-distribution
--- Comment #7 from spop at gcc dot gnu dot org 2008-11-03 16:36 --- Subject: Bug 36908 Author: spop Date: Mon Nov 3 16:35:13 2008 New Revision: 141550 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141550 Log: 2008-11-03 Sebastian Pop [EMAIL PROTECTED] PR tree-optimization/36908 * testsuite/gcc.dg/tree-ssa/pr36908.c: New. * tree-loop-distribution.c (number_of_rw_in_rdg): New. (number_of_rw_in_partition): New. (partition_contains_all_rw): New. (ldist_gen): Do not distribute when one of the partitions contains all the memory operations. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr36908.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-loop-distribution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
--- Comment #5 from spop at gcc dot gnu dot org 2008-11-03 16:44 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37684
[Bug tree-optimization/37684] [graphite] basic block containing VDEF of a scalar does not dominate basic block containing VUSE of the same scalar
--- Comment #6 from spop at gcc dot gnu dot org 2008-11-03 16:44 --- Subject: Bug 37684 Author: spop Date: Mon Nov 3 16:43:02 2008 New Revision: 141551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141551 Log: 2008-11-03 Harsha Jagasia [EMAIL PROTECTED] PR tree-optimization/37684 * gcc.dg/graphite/pr37684.c: New. * graphite.c (exclude_component_ref): New. (is_simple_operand): Call exclude_component_ref. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr37684.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37684
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-03 16:46 --- Patch preapproved by Alex: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01378.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug c++/35334] [4.2/4.3/4.4 regression] Broken diagnostic for complex cast
--- Comment #5 from manu at gcc dot gnu dot org 2008-11-03 10:38 --- What we want to do about this? Anyway, P2 is probably is too high severity. This obviously doesn't have a high priority. And I would argue that this is probably not a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35334
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-11-03 12:34 --- Subject: Bug 37573 Author: rguenth Date: Mon Nov 3 12:32:52 2008 New Revision: 141547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141547 Log: 2008-11-03 Richard Guenther [EMAIL PROTECTED] PR middle-end/37573 * tree-data-ref.c (split_constant_offset_1): Fix tuplification. * gcc.c-torture/execute/pr37573.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr37573.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug c++/28743] [4.2/4.3/4.4 regression] ICE with invalid specialization
--- Comment #16 from paolo dot carlini at oracle dot com 2008-11-03 17:10 --- It caused c++/35282... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug tree-optimization/36922] [4.4 Regression] ICE in tree-data-ref.c with -ftree-loop-linear
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-03 17:22 --- Sebastian, any ideas how to fix this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36922
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-03 17:31 --- Updated patch with also target-supports posted. With the updated patch I now get only three failures for the powerpc directory FAIL: gcc.target/powerpc/ppc64-abi-1.c (test for excess errors) -- 64 bit mode only Excess errors: /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:23:Parameter syntax error (parameter 2) /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:23:Invalid mnemonic 'got(r2)' /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:95:Parameter syntax error (parameter 2) /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:95:Invalid mnemonic 'got(r2)' /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:165:Parameter syntax error (parameter 2) /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:165:Invalid mnemonic 'got(r2)' /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:251:Parameter syntax error (parameter 2) /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:251:Invalid mnemonic 'got(r2)' /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:366:Parameter syntax error (parameter 2) /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:366:Invalid mnemonic 'got(r2)' /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:443:Parameter syntax error (parameter 2) /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cc3szi8j.s:443:Invalid mnemonic 'got(r2)' FAIL: gcc.target/powerpc/ppc64-double-1.c scan-assembler-not stfd -- 32 and 64 bit modes FAIL: gcc.target/powerpc/pr18096-1.c stack frame too large (test for errors, line 8) -- 32 bit mode FAIL: gcc.target/powerpc/pr18096-1.c (test for excess errors) /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.target/powerpc/pr18096-1.c: In function 'mkcatdefs': /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.target/powerpc/pr18096-1.c:7: error: total size of local objects too large Are these failures related to this PR or should I open a new one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #19 from dje at gcc dot gnu dot org 2008-11-03 17:35 --- Characterizing this as testsuite failures trivializes the problem. libgcj builds but does not work properly on the platforms. This PR should be categorized as P2, not P4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #20 from mmitchel at gcc dot gnu dot org 2008-11-03 17:38 --- Do we still think this is Java-specific, or do we have any evidence that this can happen in C/C++ as well? -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P4 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #21 from jakub at gcc dot gnu dot org 2008-11-03 17:41 --- Java is not a primary language, bugs that affect just Java and not C/C++ shouldn't be P1 or P2. Fortran FE bugs are P4 as well. That doesn't mean it can't be fixed, just that the release will not be delayed because of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug middle-end/38004] New: [4.4 Regression] g++.dg/vect/pr36648.cc
On Linux/ia64, revision 141547 gave: +FAIL: g++.dg/vect/pr36648.cc scan-tree-dump-times vect vectorized 1 loops 1 +FAIL: g++.dg/vect/pr36648.cc scan-tree-dump-times vect vectorizing stmts using SLP 1 Revision 141544 is OK. -- Summary: [4.4 Regression] g++.dg/vect/pr36648.cc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38004
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-03 17:43 --- Unrelated. For ppc64-double-1.c I think there is another PR open already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug c++/38005] New: inconsistent precedence of operators in namespaces
(see #1) G++ seems to use different rules than sun for determining which operator is called. G++ gives an operator in the current namespace priority over another with more specific parameters in the global scope. (see #2) G++ does something very strange. When the current namespace contains the same operator overloaded for completely different parameters, the precedence of other operators changes. In all cases Sun's compiler prints child. -- Summary: inconsistent precedence of operators in namespaces Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: c dot hite at rtsgroup dot net GCC build triplet: c24d5e9bda8759e6c069ef5eafbb8fe0 GCC host triplet: gcc version 4.2.3 GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #1 from c dot hite at rtsgroup dot net 2008-11-03 17:47 --- Created an attachment (id=16620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16620action=view) 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #22 from aph at gcc dot gnu dot org 2008-11-03 17:47 --- I think think this is Java-specific. It's quite likely that the Java FE should not be calling cgraph_build_static_cdtor(), but when that call is removed some test cases fail. Rather than arguing what priority this should be, all we need is someone who actually understands cgraph_build_static_cdtor(), and can tell me when it should be called. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #2 from c dot hite at rtsgroup dot net 2008-11-03 17:47 --- Created an attachment (id=16621) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16621action=view) 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #17 from edwintorok at gmail dot com 2008-11-03 17:50 --- Thanks. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug c++/38005] inconsistent precedence of operators in namespaces
--- Comment #3 from c dot hite at rtsgroup dot net 2008-11-03 17:51 --- The way in which the compiler finds operators has something is referred to as Koenig Lookup. -- c dot hite at rtsgroup dot net changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38005
[Bug libgcj/38006] New: Incorrect proplist on inherit.png
[EMAIL PROTECTED] gcc]$ svn proplist libjava/classpath/tools/resource/gnu/classpath/tools/gjdoc/htmldoclet/inherit.png [EMAIL PROTECTED] gcc]$ file libjava/classpath/tools/resource/gnu/classpath/tools/gjdoc/htmldoclet/inherit.png libjava/classpath/tools/resource/gnu/classpath/tools/gjdoc/htmldoclet/inherit.png: PNG image data, 12 x 12, 8-bit/color RGBA, non-interlaced The png file should have [EMAIL PROTECTED] gcc]$ svn proplist libjava/classpath/javax/swing/border/doc-files/LineBorder-1.png Properties on 'libjava/classpath/javax/swing/border/doc-files/LineBorder-1.png': svn:mime-type [EMAIL PROTECTED] gcc]$ -- Summary: Incorrect proplist on inherit.png Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38006
[Bug fortran/37999] Fortran shape and kind intrinsic
--- Comment #3 from kargl at gcc dot gnu dot org 2008-11-03 18:41 --- (In reply to comment #2) With the new version, I will check the second problem I reported as well and report back (kind intrinsic with character argument in a type declararation statement) The 2nd problem is also fixed in 4.3.2 and newer gfortran. character (len = 3, kind = kind(a ) c c = b print *, kind(a), c end program troutmask:kargl[203] ~/../sgk/work/4x/bin/gfortran -static -o z t.f90 t.f90:1.42: character (len = 3, kind = kind(a ) c 1 Error: Syntax error in CHARACTER declaration at (1) t.f90:2.7: c = b 1 Error: Can't convert CHARACTER(1) to REAL(4) at (1) The second error is a side effect of the first error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37999
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #16 from jakub at gcc dot gnu dot org 2008-11-03 17:06 --- It actually has been submitted: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01349.html but the regrename.c change has never been reviewed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/36315] [4.4 Regression] ICE with -fprofile-use (Invalid read of size 8)
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-03 17:01 --- Assuming it is fixed, if anyone can still reproduce it, please reopen with details. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36315
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-03 12:00 --- s/testcase/patch/, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #7 from dominiq at lps dot ens dot fr 2008-11-03 17:33 --- The failures disappear with the patch in comment #5. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug tree-optimization/37879] [4.3 Regression] ICE with wrong use of noreturn attribute and optimization
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37879
[Bug middle-end/37908] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-03 11:24 --- Removing regression flag, as this isn't a regression, the intrinsics worked that way forever. That doesn't mean it shouldn't be changed for 4.4, for 4.3 and earlier IMHO only a warning is acceptable, not changing semantics of it. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3/4.4 regression]|atomic NAND op generate |atomic NAND op generate |wrong code; |wrong code; |__sync_nand_and_fetch, |__sync_nand_and_fetch, |__sync_fetch_and_nand |__sync_fetch_and_nand | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37908
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #11 from ro at gcc dot gnu dot org 2008-11-03 19:04 --- Subject: Bug 37463 Author: ro Date: Mon Nov 3 19:03:28 2008 New Revision: 141555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141555 Log: PR other/37463 * configure.ac (gcc_cv_ld_ro_rw_mix): Move before gcc_cv_as_cfi_directive. (gcc_cv_as_cfi_directive) [*-*-solaris*]: Check if linker supports merging read-only and read-write sections or assembler emits read-write .eh_frame sections. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug c++/35334] [4.2/4.3/4.4 regression] Broken diagnostic for complex cast
--- Comment #7 from manu at gcc dot gnu dot org 2008-11-03 11:12 --- (In reply to comment #6) I think the cannot be used as a function error should print the exact object only if it is a DECL_P, otherwise just print error: expression cannot be used as a function. Imagine if the object is a 100KB statement expression, do we want to print that? When we have to start/end location information, we'd just print a caret range. This doesn't only apply to that particular error but anywhere that tries to print a complex_expr. So it cannot be solved at that level. It must be solved inside pretty-printer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35334
[Bug ada/37993] [4.4 Regression] missing Ada multilib support
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-03 19:17 --- a-direct.ads:426:09: alignment for Search_Typeb82s must be at least 8 a-direct.ads:426:09: alignment for Search_Typer80s must be at least 8 a-direct.ads:426:09: alignment for Search_Typet77s must be at least 8 You must add multilib support to gcc-interface/Makefile.in, see existing examples like x86_64/Linux or SPARC/Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-03 19:17:58 date|| Summary|[4.4 Regression] bootstrap |[4.4 Regression] missing Ada |with ada fails: a- |multilib support |direct.ads:426:09: alignment| |for Search_Typeb82s must | |be at least 8 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #12 from jakub at gcc dot gnu dot org 2008-11-03 19:23 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug c++/38007] New: g++ instantiate same operator twice due to bitfield in -O0 mode, causing symbol already defined assembler error
Following code produces symbol already defined assembler error when compiled
with g++ 4.2.4 with -O0 flag. It can compile without problem with g++ 4.1.1.
=== foo.hpp ===
class foo {
public:
template typename T operator T ();
};
template typename T
inline foo::operator T () {
return (T)0;
}
=== foo.cpp ===
#include foo.hpp
struct bar {
unsigned int _bar : 24;
};
int main() {
foo a;
unsigned int b = a;
bar c;
c._bar = a;
return 1;
}
compile with g++ -O0 foo.cpp
Regards,
Jeng-Liang
--
Summary: g++ instantiate same operator twice due to bitfield in -
O0 mode, causing symbol already defined assembler error
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jengliang at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38007
[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-11-03 20:01 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782
[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-11-03 20:02 --- Subject: Bug 37782 Author: pinskia Date: Mon Nov 3 20:01:11 2008 New Revision: 141558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141558 Log: 2008-11-03 Andrew Pinski [EMAIL PROTECTED] PR rtl-opt/37782 * loop-doloop.c (doloop_modify): Add from_mode argument that says what mode count is in. (doloop_optimize): Update call to doloop_modify. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-doloop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37782
[Bug c++/38007] [4.2/4.3/4.4 Regression] g++ instantiate same operator twice due to bitfield in -O0 mode, causing symbol already defined assembler error
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-03 20:07 ---
Confirmed, a regression from GCC 4.1.1.
Here is a self contained example :):
class foo {
public:
template typename T operator T ();
};
template typename T
inline foo::operator T () {
return (T)0;
}
struct bar {
unsigned int _bar : 24;
};
int main() {
foo a;
unsigned int b = a;
bar c;
c._bar = a;
return 1;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||assemble-failure
Known to fail||4.3.0 4.4.0
Known to work||4.1.1
Last reconfirmed|-00-00 00:00:00 |2008-11-03 20:07:32
date||
Summary|g++ instantiate same|[4.2/4.3/4.4 Regression] g++
|operator twice due to |instantiate same operator
|bitfield in -O0 mode, |twice due to bitfield in -O0
|causing symbol already |mode, causing symbol already
|defined assembler error |defined assembler error
Target Milestone|--- |4.2.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38007
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-14 05:03:55 |2008-11-03 20:27:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-03 22:01 --- Subject: Bug 37812 Author: jakub Date: Mon Nov 3 21:59:36 2008 New Revision: 141564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141564 Log: PR target/37812 * gcc.target/powerpc/altivec_check.h (altivec_cell_check): Abort if __PPU__ isn't defined. * lib/target-supports.exp (check_effective_target_powerpc_ppu_ok): New. * gcc.target/powerpc/altivec-cell-8.c: Use powerpc_ppu_ok. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/altivec-cell-8.c trunk/gcc/testsuite/gcc.target/powerpc/altivec_check.h trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #8 from jakub at gcc dot gnu dot org 2008-11-03 22:07 --- Subject: Bug 37241 Author: jakub Date: Mon Nov 3 22:05:57 2008 New Revision: 141565 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141565 Log: PR testsuite/37241 * g++.dg/abi/key2.C: Adjust regexps to allow __ZTV1f and __ZTI1f sharing one .section directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/key2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug target/37812] [4.4 Regression] Invalid mnemonic 'lvlx'
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-03 22:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37812
[Bug testsuite/37241] [4.4 Regression]: FAIL: g++.dg/abi/key2.C
--- Comment #9 from jakub at gcc dot gnu dot org 2008-11-03 22:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37241
[Bug pch/13675] #including a precompiled header more than once in the same unit fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13675
[Bug fortran/37999] Fortran shape and kind intrinsic
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-03 22:17 --- print *, shape( i ) That program works here with GCC 4.1.3, 4.2.1 and 4.3.3-20081002 of openSUSE, and with 4.3.3-20081103 and 4.4.0 of today. I not even get any valgrind error. Character tests: I can reproduce the ICE with 4.2, it works with 4.3/4.4. I will download the latest compiler, which I thought I had. I guess the autoupdate for my Mint Linux is not working promptly or this has been updated in the last two weeks. Note: Distributions are slow at updating the compiler as it is the core part and can cause a lot of problem. 4.3.0 was released 2008-03-05 and 4.3.x is said to be a very well working version from the C/middle-end part. Also the Fortran part is in a pretty good shape. 4.4.0 is not yet released but exists as developer version, which is daily updated but can only get regression fixes. Nightly Linux builds are available from: http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37999
[Bug pch/14933] missing pre-compiled header depends with -MD
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-11-03 22:33 --- Any news on this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933
[Bug c/37995] using stdio.h fails if gcc invoked in a directory which has a subdirectory called gcc
--- Comment #4 from brian at dessent dot net 2008-11-03 23:23 ---
Subject: Re: using stdio.h fails if gcc invoked in a directory
which has a subdirectory called gcc
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v -iprefix
/home/mvanier/tmp/../lib/gcc/i686-pc-linux-gnu/4.3.2/ hello.c -mtune=generic
-fpch-preprocess -o hello.i
That -iprefix is the problem. It should not be there. Do you have
GCC_EXEC_PREFIX set in your environment or something? You should not
need this set in normal use of the compiler; try with a clean env.
Also, you are not building a stock gcc because there are these patches
added by your build script:
if [ ${CARCH} = x86_64 ]; then
patch -Np1 -i ../gcc_pure64.patch || return 1
fi
patch -Np0 -i ${srcdir}/gcc-hash-style-both.patch || return 1
patch -Np0 -i ${srcdir}/gcc-java-driver.patch || return 1
It makes it really hard to triage bugs when you report problems against
software build with random unmentioned outside changes. Please try a
vanilla build.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37995
