[Bug preprocessor/19475] [3.3/3.4/4.0 Regression] missing whitespace after macro name in C90 or C++
--- Additional Comments From janis187 at us dot ibm dot com 2005-04-05 22:37 --- Subject: Re: [PATCH] Fix PR preprocessor/19475 On Tue, Apr 05, 2005 at 03:12:08PM -0700, Per Bothner wrote: > Neil Booth wrote: > > >I think it gets confused by the column numbers; if you add > >-fno-columns (or whatever it is) the problem would probably > >go away. > > Or somebody could approve this patch: > > http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00183.html Looks good to me. Janis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19475
[Bug target/20814] ICE in extract_insn for test vmx/varargs-1.c
--- Additional Comments From janis187 at us dot ibm dot com 2005-04-07 22:30 --- Subject: Re: ICE in extract_insn for test vmx/varargs-1.c On Thu, Apr 07, 2005 at 10:09:14PM -, dje at watson dot ibm dot com wrote: > > --- Additional Comments From dje at watson dot ibm dot com 2005-04-07 > 22:09 --- > Subject: Re: New: ICE in extract_insn for test vmx/varargs-1.c > > Let me know if the appended patch fixes the ICE. The definition > of the "and" predicates was ignoring CONST_INT that matched predicate > logical_operand. No, this doesn't affect it. You ought to be able to debug this using a cross compiler, since all you need to build is cc1. Janis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20814
[Bug target/20814] [4.1 Regression] ICE in extract_insn for test vmx/varargs-1.c
--- Additional Comments From janis187 at us dot ibm dot com 2005-04-08 21:45 --- Subject: Re: [4.1 Regression] ICE in extract_insn for test vmx/varargs-1.c A simple build (C only, no bootstrap, no testsuite run) with the latest patch passes all of the gcc.dg/vmx tests on powerpc64-linux with -m32 and -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20814
[Bug rtl-optimization/23837] [4.0/4.1 regression] Wrong code with -fschedule-insns
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-19 19:42 --- A regression hunt on i686-linux showed the failure starting with this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00640.html -- What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug tree-optimization/23929] [4.1 Regression] segfault in expand_simple_operations, tree-ssa-loop-niter.c:637
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-19 21:08 --- It is not true that the function that contains a bug that causes a segfault is always in the backtrace for the failure; this isn't enough information to claim this is a latent bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23929
[Bug tree-optimization/23948] [4.1 Regression] internal compiler error: verify_stmts failed
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-20 21:28 --- The ICE begins with these patches (the second adds a missing file for the first) from bonzini: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00791.html http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00792.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23948
[Bug c++/23984] [4.0/4.1 Regression] second operand of PLUS_EXPR is NULL (in constructor)
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-21 17:07 --- Reghunt found this patch from nathan: http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01511.html -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23984
[Bug libstdc++/23871] [4.0 Regression] iostream operator<<(int) uses || on integral operands
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-27 17:18 --- This is fixed in 4.0.2. I forgot and checked it into the branch before RC2; Paolo said it was safe and to leave it in unless Mark said to yank it out. I've messed up my Bugzilla settings and can't change the PR to "fixed". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23871
[Bug gcov/profile/24093] New: cgraph exhausts virtual memory building 197.parser with -profile-use -O3
Beginning with mainline from 2005-09-25, GCC dies with "virtual memory
exhausted: cannot allocate memory" when building the SPEC CPU2000 test
197.parser with -O3 and -fprofile-generate/-fprofile-use. In my parallel
build of 197.parser the failures are for fast-match.c, build-disjuncts.c,
and post-process.c, using GCC for powerpc64-linux with -m32. The rest
of the CPU2000 programs build and run successfully using the same
options. I saw this on two systems where I do lots of testing and have
never run out of memory before, so it's not just that my memory size is
unreasonably small.
Function cgraph_clone_inlined_nodes is in the traceback for the abort.
There are two cgraph changes from Jan Hubicka on 2005-09-24 that seem
to be likely suspects.
--
Summary: cgraph exhausts virtual memory building 197.parser with
-profile-use -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gcov/profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org,hubicka at gcc dot gnu
dot org
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24093
[Bug middle-end/24095] New: use of garbage-collected memory with -ftree-vectorize
GCC mainline for powerpc-linux segfaults when compiling several of the SPEC CPU2000 tests with "-ftree-vectorize -maltivec -mabi=altivec". For most of them this happens with both -m32 and -m64. The minimized test case (to be attached) causes the failure when compiled with "-O2 -ftree-vectorize -maltivec --param ggc-min-expand=0 --param ggc-min-heapsize=0". The segfault is in fold_convert with orig having the value 0xa5a5a5a5. A reghunt identified the following patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00635.html This could be a latent bug, since on one of the systems I use regularly I was not able to reproduce the failure. -- Summary: use of garbage-collected memory with -ftree-vectorize Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis187 at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot org GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24095
[Bug middle-end/24095] use of garbage-collected memory with -ftree-vectorize
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-27 22:52 --- Created an attachment (id=9824) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9824&action=view) minimized test case Test case mentioned in the submittal message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24095
[Bug middle-end/24049] [4.1 regression] compiler error: Segmentation fault In function 'DESX_CBCUpdate'
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-27 23:52 --- The reghunt for 24095 (now a duplicate of this one) identified this patch: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00635.html which is the one prior to the one that Andrew suspected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24049
[Bug tree-optimization/24059] [4.1 Regression] ICE expand_expr_real_1 with -ftree-vectorize -O2
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:25 --- A regression hunt identified this patch from rth: http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00765.html -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24059
[Bug middle-end/23714] [4.1 Regression] ICE in expand_assignment
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:27 --- A regression hunt identified this patch from steven: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00294.html -- What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23714
[Bug c++/21383] [3.4/4.0/4.1 Regression] Crash when finding &a_templated_func<>
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:28 --- A regression hunt identified this patch from nathan: http://gcc.gnu.org/ml/gcc-cvs/2003-08/msg00349.html -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21383
[Bug c++/22352] [3.4/4.0/4.1 Regression] ICE in lookup_member
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:41 --- A regression hunt identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg00694.html -- What|Removed |Added CC||lerdsuwa at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22352
[Bug c++/23730] [4.0/4.1 Regression] ICE instead of reporting a call to a non-existent member function
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 16:48 --- A regression hunt identified these patches from nathan (the second adds a change missed in the first one): http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00663.html http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg00664.html -- What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23730
[Bug tree-optimization/23853] [4.1 regression] ICE: in tree_low_cst, at tree.c:4270
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 17:24 --- A regression hunt identified the following patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00537.html -- What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
[Bug c++/22618] [3.4/4.0/4.1 Regression] Template non-type arguments break class access protection
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 20:25 --- A regression hunt identified this patch from mmitchel: http://gcc.gnu.org/ml/gcc-cvs/2003-07/msg00404.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22618
[Bug c++/21685] [3.4/4.0/4.1 Regression] Internal compiler error on invalid code
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-28 20:27 --- A regression hunt identified this patch from mmitchel: http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00117.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21685
[Bug tree-optimization/23946] [4.1 regression] ICE: verify_ssa failed ("definition ... follows the use")
--- Additional Comments From janis187 at us dot ibm dot com 2005-09-30 22:47 --- A regression hunt identified this patch from dnovillo: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00644.html -- What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23946
[Bug c/24101] [3.4/4.0/4.1 Regression] Segfault with preprocessed source
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:15 --- A regression hunt identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg00236.html -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||bothner at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
[Bug c++/24103] [3.4 Regression] ICE in simple_cst_equal
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:20 --- A regression hunt for the patch that fixed this on mainline identified the merge of the tree-ssa branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24103
[Bug middle-end/24135] [4.0/4.1 Regression] nonlocal goto from nested function gets 'undefined symbol' in assembler
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-03 16:24 --- A regression hunt for powerpc-linux on mainline identified the merge of the tree-ssa branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24135
[Bug c++/23651] [4.1 Regression] ICE in GC
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-03 17:44 --- I can reproduce this reliably for powerpc64-linux with -m64 using the testcase in comment #3; using -m32 the results are intermittent. A regression hunt identified the following patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00665.html -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23651
[Bug tree-optimization/24172] [4.1 Regression] error: incorrect sharing of tree nodes
--- Comment #4 from janis187 at us dot ibm dot com 2005-10-03 21:59 --- A regression hunt using the testcase from comment #3 identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00624.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24172
[Bug rtl-optimization/24160] [4.1 Regression] ICE with -O1 -ftree-vectorize -msse
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-03 22:26 --- A regression hunt using an i686-linux cross compiler with the testcase from comment #3 identifies this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00534.html That doesn't fit with the submitter's information that it worked on 20050723 and the patch doesn't seem particularly relevant to this bug, so I tried several builds around the date of this patch and afterwards; there are rare intermittent passes after this patch, but no failures (that I saw) before it. -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||phython at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24160
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-04 19:20 --- My debugging sessions for this got bogged down, but I ran into a mainline fix for this problem while investigating something else: http://gcc.gnu.org/ml/gcc-cvs/2004-05/msg00133.html I'm testing a backport of that fix to the 3.4 branch and hope to submit it later today or tomorrow. Besides fixing the submitter's problem, the patch also fixes a problem with DWARF2 debug information for vector types that a neighboring gdb developer discovered yesterday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug c++/24199] [3.4 Regression] Segfault with -frepo -g
--- Comment #3 from janis187 at us dot ibm dot com 2005-10-04 22:23 --- It looks like it was fixed on mainline by this patch from mmitchel: http://gcc.gnu.org/ml/gcc-cvs/2004-08/msg01218.html It's hard to be sure because there are build failures at that time for powerpc-linux. -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24199
[Bug tree-optimization/24231] [4.1 Regression] ICE: SSA corruption
--- Comment #7 from janis187 at us dot ibm dot com 2005-10-06 19:25 --- A regression hunt using the testcase from comment #4 identified this patch from pinskia: http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00277.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24231
[Bug target/24230] [4.1 Regression] [altivec] ICE in extract_insn, at recog.c:2084
--- Comment #8 from janis187 at us dot ibm dot com 2005-10-06 20:17 --- A regression hunt on powerpc-linux using the testcase from comment #6 identified this patch from rth: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg01004.html -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug middle-end/24227] [4.1 Regression] ICE in compare_values, at tree-vrp.c:415
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-06 21:23 --- This is probably not very useful, but a regression hunt using the testcase from comment #4 identified this patch from dnovillo: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00069.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24227
[Bug preprocessor/24202] [4.1 Regression] Segfault with #pragma once
--- Comment #3 from janis187 at us dot ibm dot com 2005-10-06 22:21 --- The list of work/fail versions is very odd for this bug; it seems to have worked on mainline until sometime between 20050828 and 20050904. 3.3.5 passes, but all 3.4.x versions I tried fail. 4.0.0 passes but 4.0.2 fails. I fired off several mainline builds between the 3.3 branchpoint and early September to identify ranges on mainline where it passes and fails; those should help show if it's an intermittent failure or has definite fix and break points. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
[Bug tree-optimization/24226] [4.1 Regression] ICE: Segmentation fault in operand_equal_p (complete loop unrolling)
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-06 22:27 --- A regression hunt on powerpc-linux using the testcase from comment #5 identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00210.html -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24226
[Bug c++/24215] [4.0/4.1 Regression] pragma interface in included file with same name
--- Comment #2 from janis187 at us dot ibm dot com 2005-10-07 17:26 --- A regression hunt identified this large patch from Zack Weinberg and Matt Austern: http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00920.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24215
[Bug tree-optimization/24225] [4.1 Regression] ICE: segmentation fault in profile.c:branch_prob
--- Comment #6 from janis187 at us dot ibm dot com 2005-10-07 19:36 --- A regression hunt on powerpc-linux using the testcase from comment #4 identified this patch from [EMAIL PROTECTED]: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00101.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24225
[Bug preprocessor/24202] [4.1 Regression] Segfault with #pragma once
--- Comment #4 from janis187 at us dot ibm dot com 2005-10-07 19:45 --- The most recent break on mainline was by this patch from jakub: http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg00974.html The same patch was applied to the 4.0 branch, causing the failure in 4.0.2. That patch from Jakub reverted part of this patch from Zack, which had fixed this bug on mainline: http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00122.html Before that, the failure on mainline started sometime between 2003-07-16 and 2003-09-15. I can identify the patch if it would be useful to anyone. -- janis187 at us dot ibm dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
[Bug c/24137] __uint128_t missing for ppc32
--- Comment #5 from janis187 at us dot ibm dot com 2005-10-07 20:27 --- I bumped into this PR by accident and happen to have looked into this recently. __uint128_t is supported on a ppc64 system with a powerpc64-linux compiler using "-m32 -mpowerpc64". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24137
[Bug tree-optimization/21048] [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures
--- Additional Comments From janis187 at us dot ibm dot com 2005-04-25 19:18 --- Subject: Re: [4.1 Regression] use of poisoned ggc memory causes cpu2000 build failures Yes, I'll do a bootstrap and testrun and try the CPU2000 test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21048
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-12 19:25 --- Subject: Re: [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux > Would you please try the attached patch for 3.4? I have a similar patch > for 4.0 which I will attach soon. With GCC 3.4.4 RC1 the following on an 8-proc powerpc64-linux system: $src/configure --enable-languages=c++ ... make -j 8 bootstrap make install failed without the patch, succeeded with the patch. I'm running the same thing again for good measure and then will build all languages (except Ada) and run the testsuites. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug libstdc++/21523] [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-13 00:13 --- Subject: Re: [3.4/4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux Bootstrap with the patch went fine with -j 8, test results look good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug libstdc++/21523] [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-14 00:54 --- Subject: Re: [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on powerpc64-linux I tried the 4.0 patch on powerpc64-linux with "make -j 8 bootstrap" for c,c++,f95,objc,java, ran the testsuite, and installed; it all worked fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21523
[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-17 20:01 --- Subject: Re: wrong code in sixtrack for -fmodulo-sched The patch fixes the problem with sixtrack. I suspected that a latent problem was causing the earlier failures in lucas and apsi which have since gone away. They failed on 20050429, but with the patch applied to sources from that date they pass. Yea! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21138
[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-21
01:16 ---
We're not supposed to use TCL code in test cases, so the proper syntax is
/* { dg-require-effective-target keyword } */
I like the idea of running the vect tests multiple times for targets that have
multiple variants of vector support.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095
[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough on x86
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-22 17:53 --- I've been looking at how to restructure gcc.dg/vect/vect.exp to cycle through multiple options for vector instruction sets. -- What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095
[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough on x86
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-22 18:03 --- Oops, I wasn't done with that last comment. Anyway, while I'm looking at the testsuite framework mechanism, perhaps someone can determine which options are appropriate to run for various x86 targets and come up with tests to determine whether a particular instruction set is supported on the test hardware so we'll know whether the test should be "run" or "compile" for that set. I'm thinking of something like check_x86_vect_hw_available that takes as argument -mmmx/-msse/-msse2/-msse3/-m3dnow. There might also be a check_* proc that takes those arguments and says whether the option is supported at all for this target (e.g., does x86_64 accept them all?). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095
[Bug bootstrap/19135] New: build failure in libiberty multilibs
GCC builds are broken on powerpc64-unknown-linux-gnu since this patch to libiberty: http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00805.html. I configure with --build, --host, and --target=powerpc64-linux and --with-cpu=default32; see my recent test results for mainline for the complete set of configure options I use. This problem occurs even for simple builds of C only. The build in powerpc64-linux/64/libiberty tries to create libiberty.so.0.0.0 from 64-bit object files without specifying -m64. The build continues and eventually succeeds, but 'make install' tries the same thing and fails. -- Summary: build failure in libiberty multilibs Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis187 at us dot ibm dot com CC: gcc-bugs at gcc dot gnu dot org,hjl at gnu dot org GCC build triplet: powerpc64-linux GCC host triplet: powerpc64-linux GCC target triplet: powerpc64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-23 17:18 --- The patch doesn't work, the command to link 64-bit libiberty.so.0.0.0 still doesn't use -m64. This comment in libiberty/Makefile.in might provide a clue about the problem: # This is tricky. Even though CC in the Makefile contains # multilib-specific flags, it's overridden by FLAGS_TO_PASS from the # default multilib, so we have to take LIBCFLAGS into account as well, # since it will be passed the multilib flags. Let me know what additional information I can provide. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-23 18:50 --- There is no -rpath in the command to build 64-bit libiberty. It appears to be just $(CC) plus -shared, the list of object files, -Wl,-soname -Wl,libiberty.so.0 -o ././libs/libiberty.so.0.0.0. Where in the Makefile does this happen? I'm trying to follow it but can't figure out where the shared version is built so I can get more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-23 19:44 --- An easier question is: how does libmudflap do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-26 23:39 --- A build with the patch libiberty-multilib-3.patch applied to 20041222 sources succeeds, although it doesn't attempt to build libiberty as a shared object. I haven't tried libiberty-multilib-2.patch; is that still desired? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135
[Bug middle-end/19304] New: wrong code for spec test from emit_move_change_mode
Benchmark 197.parser from SPEC CPU2000 fails on powerpc64-linux when
compiled with "-m32 -O2 -maltivec" or "-m32 -O2 -funroll-loops",
producing incorrect results. The failures start with this patch:
2004-12-12 Richard Henderson <[EMAIL PROTECTED]>
* expr.c (emit_move_change_mode): New.
(emit_move_via_alt_mode): Use it.
I have no idea what's going on here but noticed that the original code
handled more conditions than does the new code. If simplify_gen_subreg,
rather than simplify_subreg, is called when reload_in_progress is true
but MEM_P(x) is false, the test case passes again. I'll attach the
diffs.
If this looks worth testing I'll do a bootstrap and testsuite run and
run the CPU2000 tests with the short test input using a variety of
compiler options.
--
Summary: wrong code for spec test from emit_move_change_mode
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org,rth at gcc dot gnu dot
org
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug middle-end/19304] wrong code for spec test from emit_move_change_mode
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-06 23:39 --- Created an attachment (id=7889) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7889&action=view) diffs that worked for me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug c/17662] testsuite for IMA testcases
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-11 18:22 --- Look at dg-additional-files and dg-additional-sources, defined in gcc-testsuite/lib/gcc-defs.exp and used in several tests. I'll take a closer look at them soon, but feel free to beat me to it and try them out on the IMA tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17662
[Bug c/17662] testsuite for IMA testcases
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-11
21:45 ---
Here's how two tests mentioned here can use dg-additional-sources. I ran
these in gcc.dg.special, which only treats files matching *[0-9].c as tests.
I don't yet know why, but 'dg-do compile' turns into 'dg-do assemble' and
vice versa when dg-additional-sources is used.
% cat combine-1a.c
extern int printf (const char *, ...);
struct x { int a; int b; };
bar (struct x* p)
{
printf ("%d\n", p->a);
}
% cat combine-1.c
/* { dg-do compile } */
/* { dg-options "-combine -O3" } */
/* { dg-additional-sources combine-1a.c } */
struct x;
foo (struct x* q)
{
bar (q);
}
% cat combine-2a.c
#include "combine-2.h"
int sentence[MAX_WORD];
% cat combine-2b.c
#include "combine-2.h"
% cat combine-2.c
/* { dg-do compile } */
/* { dg-options "-combine" } */
/* { dg-additional-sources "combine-2a.c combine-2b.c" } */
/* { dg-additional-files combine-2.h } */
#include "combine-2.h"
% cat combine-2.h
#define MAX_WORD 60
extern int sentence[];
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17662
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-12 16:48 --- I suspect that the patch is a clue to what's wrong rather than a real fix, but if nothing happens in a couple of days I'll post it anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-13 17:02 --- What does the "(like below)" in comment #4 refer to? I can try to come up with a minimized test case if that's necessary, I just didn't want to put the work into that if the problem was obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug middle-end/19304] [4.0 Regression] wrong code for spec test from emit_move_change_mode
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-13 18:57 --- Never mind the question in the last comment, I've bootstrapped C with that change and it aborts compiling the spec test. I'm doing more testing to find a test for which I can post the .i file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19304
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-15 01:24 --- Created an attachment (id=7963) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7963&action=view) example binary compatibility testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-15 01:27 --- Darn, I did my comments wrong. Yan, the testcase you attached doesn't match the output you show. For all compilers I have available on a RHEL3 system I get: Dumping array with size of 2 Character 0 is 1 Character 1 is 0 c1.m1=1, Please provide some examples of classes with bitfields that are not compatible between releases of GCC. I've attached an example testcase for binary compatibility tests in the format used by the GCC testsuite. Our binary compatibility tests are not at all complete and we need more tests to cover this kind of functionality; that's on my todo list already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
-- What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-17 18:14 --- I had not changed the size of the bitfield to 17 in my test case. When I do that I can see the binary compatibility breakage. I'll look into this to find out why this change was introduced. It appears to be a general C++ change not specific to powerpc-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19 02:01 --- There are two changes that affect this binary incompatibility: one changes the layout of the class, and the other changes how the bitfield is accessed. Mark, did this change on purpose and is it covered by the C++ ABI? The first change is: --- gcc/gcc/cp/ChangeLog --- 2003-04-29 Mark Mitchell <[EMAIL PROTECTED]> PR c++/10549 * class.c (layout_class_type): Mark overlong bitfields as having the maximum size permitted by their type, after layout. The second change is: --- gcc/gcc/ChangeLog --- 2003-12-23 Mark Mitchell <[EMAIL PROTECTED]> * c-common.c (flag_abi_version): Default to 2. * c-cppbuiltin.c (c_cpp_builtins): Define __GXX_ABI_VERSION uniformly for versions above 2. * doc/invoke.texi: Update documentation for -fabi-version. --- gcc/gcc/cp/ChangeLog --- 2003-12-23 Mark Mitchell <[EMAIL PROTECTED]> * cp-lang.c (cp_expr_size): Return zero for empty classes. * cp-tree.h (warn_if_uknown_interface): Remove unused function. * decl2.c (warn_if_unknown_interface): Likewise. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19 02:05 --- Created an attachment (id=7988) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7988&action=view) test case with script I get the following output from running the attached script using compilers I built before and after each of the patches listed in the previous comment. --- define with 3.2.3 use with2003-04-29 21:28 UTC PASSED define with 2003-04-29 21:28 UTC use with3.2.3 PASSED --- define with 2003-04-29 21:28 UTC use with2003-04-29 21:28 UTC PASSED --- define with 2003-04-29 21:28 UTC use with2003-04-29 21:30 UTC ./pr19448-2.sh: line 116: 26808 Aborted a.out define with 2003-04-29 21:30 UTC use with2003-04-29 21:28 UTC PASSED --- define with 2003-04-29 21:30 UTC use with2003-04-29 21:30 UTC ./pr19448-2.sh: line 118: 26832 Aborted a.out --- define with 2003-12-23 16:53 UTC use with2003-12-23 16:53 UTC ./pr19448-2.sh: line 120: 26852 Aborted a.out --- define with 2003-12-23 16:53 UTC use with2003-12-23 16:55 UTC ./pr19448-2.sh: line 122: 26872 Aborted a.out define with 2003-12-23 16:55 UTC use with2003-12-23 16:53 UTC PASSED --- define with 2003-12-23 16:55 UTC use with2003-12-23 16:55 UTC PASSED --- define with 2003-12-23 16:55 UTC use with3.4.3 PASSED define with 3.4.3 use with2003-12-23 16:55 UTC PASSED --- define with 3.2.3 use with3.4.3 ./pr19448-2.sh: line 128: 26940 Aborted a.out define with 3.4.3 use with3.2.3 ./pr19448-2.sh: line 128: 26944 Aborted a.out --- In file included from pr19448_define.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type bc.h:1: warning: the offset of `bc::m1' may not be ABI-compliant and may change in a future version of GCC In file included from pr19448_use.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type bc.h:1: warning: the offset of `bc::m1' may not be ABI-compliant and may change in a future version of GCC In file included from pr19448_define.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type In file included from pr19448_use.C:1: bc.h:3: warning: width of `bc::m1' exceeds its type define with 3.2.3 with -Wabi use with3.4.3 with -fabi-version=1 ./pr19448-2.sh: line 131: 26964 Aborted a.out define with 3.4.3 with -fabi-version=1 use with3.2.3 with -Wabi PASSED --- -- What
[Bug c++/19448] Different value representation for bitfield width exceeding its type size.
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19
17:04 ---
Mark, your response addresses the original message but not the later ones, and
not either of the attached test cases. In those the class is:
class bc {
public:
char m1 :17;
};
m1 is assigned a value of 1, which certainly fits.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
[Bug c/17957] New: vector type node used after garbage-collected
I'm writing a set of tests for functionality of GCC generic vectors.
Several very large tests result in internal compiler errors or seg
faults because a type node that is reused has been garbage-collected.
I'll leave it to someone who understands the garbage collector to
figure out how to fix this.
The node in question is allocated in build_word_node_vector_type.
It's easier to detect the problem with the following patch:
--- tree-complex.c.orig 2004-10-12 14:43:10.574920072 -0700
+++ tree-complex.c 2004-10-12 14:43:50.232015984 -0700
@@ -521,7 +521,10 @@ build_word_mode_vector_type (int nunits)
if (!innertype)
innertype = lang_hooks.types.type_for_mode (word_mode, 1);
else if (last_nunits == nunits)
-return last;
+{
+ gcc_assert (TREE_CODE (last) == VECTOR_TYPE);
+ return last;
+}
/* We build a new type, but we canonicalize it nevertheless,
because it still saves some memory. */
... and by forcing garbage collection to happen frequently, like so.
laptop% /home/janis/tools/gcc-mline-20041012/bin/gcc -c --param ggc-min-expand=0
--param ggc-min-heapsize=0 bug1.c
bug1.c: In function 'vsub':
bug1.c:17: internal compiler error: in build_word_mode_vector_type, at
/tree-complex.c:525
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
This happens for me on powerpc64-unknown-linux-gnu and i686-pc-linux-gnu
using today's mainline sources, with the patch above to detect the
problem more quickly.
--
Summary: vector type node used after garbage-collected
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug c/17957] vector type node used after garbage-collected
--- Additional Comments From janis187 at us dot ibm dot com 2004-10-12 22:00 --- Created an attachment (id=7331) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7331&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug c/17961] New: ICE for operation on small vector with altivec enabled
This test case causes two different internal compiler errors in GCC when
compiled with "-m32 -maltivec", with VECSIZE either 2 or 8:
__attribute__ ((vector_size (VECSIZE))) unsigned char v1, v2, v3;
void vxor (void) { v1 = v2 ^ v3; }
Using a cross compiler on i686-linux with today's mainline:
laptop% $XGCC -m32 -maltivec -DVECSIZE=2 -c bug2.c
bug2.c: In function 'vxor':
bug2.c:9: internal compiler error: in operand_subword_force, at
/emit-rtl.c:1384Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
laptop% $XGCC -m32 -maltivec -DVECSIZE=8 -c bug2.c
bug2.c: In function 'vxor':
bug2.c:10: internal compiler error: in simplify_subreg, at /simplify-rtx.c:3572
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
There is no ICE when VECSIZE is 4. Hardware-supported AltiVec vectors
are 16 bytes, so all of these are smaller than hardware-supported
vectors. The larger testcase compiles and runs as expected when hardware
vector support is not enabled.
--
Summary: ICE for operation on small vector with altivec enabled
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17961
[Bug target/17962] New: small fp vector uses sse/mmx vectors and is not aligned
The following test case is compiled to use hardware vector support
for -msse, -msse2, or -mmmx even though the vector type is smaller
than what the hardware supports for float elements. The vector
variables are given an alignment of 4 bytes, causing a seg fault at
runtime.
__attribute__ ((vector_size (8))) float v1, v2, v3;
int
main ()
{
v1 = v2 + v3;
return 0;
}
Last tested with a native i686-pc-linux-gnu compiler with today's
mainline.
--
Summary: small fp vector uses sse/mmx vectors and is not aligned
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17962
[Bug target/18004] New: ICE in output_constant_pool_2 for aligned(1) float in struct
This test causes GCC to ICE in output_constant_pool_2 on powerpc64-linux
with -m32. The ICE goes away without the typedef or if the variable
is local.
The test case is extracted from gcc.dg-struct-layout-1/t001.
typedef float Tal1float __attribute__((aligned (1)));
struct { Tal1float f; } s;
void foo (void) { s.f = 1.0; }
When compiled with powerpc64-unknown-linux-gnu from 20041013 mainline:
elm3b11% /opt/gcc-nightly/mline/bin/gcc -m32 bug.c
bug.c: In function 'foo':
bug.c:3: internal compiler error: in output_constant_pool_2, at /varasm.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
GCC for powerpc-eabisim gets the same ICE.
--
Summary: ICE in output_constant_pool_2 for aligned(1) float in
struct
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18004
[Bug other/18423] New: powerpc-eabisim build broken due to configure skipping fixincludes
There was a change to configure proposed by Paolo Bonzini in September,
checked into configure.in by Aaron LaFramboise in October, and configure
(when it was regenerated to include his own patch) by HJ Lu in November
that prevents fixincludes from being built for powerpc-eabisim, causing
a build for that target, as described in simtest-howto.html, to fail.
The following hack to configure fixes it, but I don't know if it's
appropriate to skip libgcj for that target:
Index: configure.in
===
RCS file: /opt/gcc-cvs/gcc/configure.in,v
retrieving revision 1.331
diff -u -p -r1.331 configure.in
--- configure.in8 Nov 2004 01:27:56 - 1.331
+++ configure.in11 Nov 2004 00:38:11 -
@@ -683,6 +683,9 @@ case "${target}" in
powerpc-*-eabi)
noconfigdirs="$noconfigdirs ${libgcj} build-fixincludes"
;;
+ powerpc-*-eabisim)
+noconfigdirs="$noconfigdirs ${libgcj}"
+;;
powerpc-*-eabi* | powerpcle-*-eabi* | powerpc-*-rtems* )
noconfigdirs="$noconfigdirs build-fixincludes"
;;
I submitting this as a problem report rather than as a patch because I don't
know what's going on here at all, and would like someone who understands
this stuff to take a look at it.
The bug exists in today's mainline and is a regression.
--
Summary: powerpc-eabisim build broken due to configure skipping
fixincludes
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-eabisim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug other/18423] [4.0 Regression] powerpc-eabisim build broken due to configure skipping fixincludes
--- Additional Comments From janis187 at us dot ibm dot com 2004-11-11 17:39 --- The powerpc-eabisim build THINKS it needs fixincludes, so perhaps that's a separate issue; the build fails at stmp-fixinc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18423
[Bug tree-optimization/18505] New: ICE in emit_move_insn in five vect tests with -m64
Sometime between 20041112 (my last successful bootstrap) and 20041115, five tests in gcc.dg/vect start getting an ICE for -m64 on powerpc64-linux-gnu: elm3b11% /home/janis/tools/gcc-mline-20041115-patches/bin/gcc -m64 -maltivec -O2 -ftree-vectorize vect-60.c vect-60.c: In function main1: vect-60.c:27: internal compiler error: in emit_move_insn, at expr.c:2590 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. This compiler is built from a tree with patches to testsuite files but no changes to source files. The other failing tests are vect-[46,50,52,58]. -- Summary: ICE in emit_move_insn in five vect tests with -m64 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis187 at us dot ibm dot com CC: dorit at il dot ibm dot com,gcc-bugs at gcc dot gnu dot org GCC host triplet: powerpc-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18505
[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux
--- Additional Comments From janis187 at us dot ibm dot com 2004-11-16
17:06 ---
GCC for powerpc64-*-linux* could be any of the following: (a) a compiler that
generates only LP64 code; (b) a biarch compiler that generates ILP32 code by
default; or (c) a biarch compiler that generates LP64 code by default. There's
currently no way to detect, in an xfail list, that a test is compiled for LP64
code on a powerpc64-*-linux* target. My nightly bootstrap and test run uses
(b) and Jon Grimm's uses (c).
If a test is unsupported for LP64 then it can always be skipped by using
{ dg-require-effective-target ilp32 }.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
[Bug c/17957] [4.0 regression] vector type node used after garbage-collected
--- Additional Comments From janis187 at us dot ibm dot com 2004-11-23
00:17 ---
An easy fix is for build_word_mode_vector_type to not try to reuse types.
The change to the garbage collector merely exposed a latent bug.
It works for me if build_word_mode_vector_type is cut down to this, although
there's probably a cleaner place to fix it:
static tree
build_word_mode_vector_type (int nunits)
{
static tree innertype;
if (!innertype)
innertype = lang_hooks.types.type_for_mode (word_mode, 1);
return build_vector_type (innertype, nunits);
}
--
What|Removed |Added
CC||bonzini at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug target/18631] New: missing error messages passing vectors with -mno-altivec -mabi=altivec
The AltiVec variant of the PowerPC 64-bit ABI specifies that types that
map to hardware vectors are passed in vector registers. There used to
be error messages for passing vectors by value or returning vectors
from functions if AltiVec support was on but the non-AltiVec ABI was
used. For this code:
typedef int __attribute__((vector_size(16))) vec;
extern vec v1;
vec ret (void) { return v1; }
void pass (vec v) { v1 = v; }
GCC 3.4.3 with -mno-altivec -mabi=altivec gives:
bug.c: In function `ret':
bug.c:3: error: Cannot return value in vector register because altivec
instructions are disabled, use -maltivec to enable them.
bug.c: In function `pass':
bug.c:4: error: Cannot pass argument in vector register because altivec
instructions are disabled, use -maltivec to enable them.
Mainline GCC no longer gives these errors, starting with this patch
from Paolo Bonzini on July 22:
http://gcc.gnu.org/ml/gcc-cvs/2004-07/msg0.html
At the time the checks are made for the error message, the type of the
argument or return value is TImode, not a vector type.
This is a regression from 3.4 compilers.
--
Summary: missing error messages passing vectors with -mno-altivec
-mabi=altivec
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: bonzini at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
GCC target triplet: powerpc*-*-linux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
[Bug middle-end/17957] [4.0 regression] vector type node used after garbage-collected
--- Additional Comments From janis187 at us dot ibm dot com 2004-11-24 00:09 --- The patch doesn't fix the test case, however nice it might be in other respects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
[Bug target/18631] [4.0 Regression] missing error messages passing vectors with -mno-altivec -mabi=altivec
--- Additional Comments From janis187 at us dot ibm dot com 2004-11-24 16:53 --- Oops, in the submission I said "There used to be error messages for passing vectors by value or returning vectors from functions if AltiVec support was on but the non-AltiVec ABI was used." That should be: There used to be error messages ... if AltiVec support was not on and the AltiVec ABI was used. The AltiVec ABI says that vectors that map to hardware vectors are passed in vector registers. That variant of the ABI is the default but can be turned off with -mabi=no-altivec, which is useful for binary compatibility with modules that will be used on multiple types of PowerPC-64 hardware. The ABI doesn't cover generic vectors that don't map to hardware vectors, but GCC passes them by reference for either variant of the ABI. It probably doesn't specifically cover the case of generic vectors that map to hardware vectors when AltiVec support isn't enabled, but that seems surprising enough that it ought to continue to be an error. I personally think it ought to be an error to pass any synthetic vector by value unless it is specifically covered by the ABI, but that's another mess that no one wants to touch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
[Bug debug/16792] [4.0 regression] ICE in gen_subprogram_die, at dwarf2out.c:11267
--- Additional Comments From janis187 at us dot ibm dot com 2004-12-04
01:19 ---
Current mainline g++ ICEs in the same place (now dwarf2out.c:11210) when
compiling 252.eon with -g on powerpc64-unknown-linux-gnu with either -m32
or -m64. Here's a testcase extracted from the eon code:
double foo (double);
void bar (double a)
{
double foo (double);
double x = foo (a);
}
double foo (double a)
{
return 0.0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16792
[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc
--- Comment #18 from janis187 at us dot ibm dot com 2006-11-09 17:34 --- Subject: Re: bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc On Thu, Nov 09, 2006 at 10:15:24AM -, irar at il dot ibm dot com wrote: > However, the failure in comment #3 still occurs in the later revisions. So, I > am going to hunt for a later patch that broke bootstrap with vectorization > (applying the above patch). I can do that with my regression hunt setup, if you'd like; it's set up to allow adding patches for each new version tested. Janis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
