[Bug target/24367] [4.0/4.1/4.2 Regression] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #6 from krebbel at gcc dot gnu dot org 2006-08-31 07:43 ---
Subject: Bug 24367
Author: krebbel
Date: Thu Aug 31 07:43:36 2006
New Revision: 116599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116599
Log:
2006-08-31 Andreas Krebbel <[EMAIL PROTECTED]>
PR target/24367
* config/s390/s390.md ("movsi", "movdi" expander): Accept rtxes like
r12 + SYMBOLIC_CONST.
2006-08-31 Andreas Krebbel <[EMAIL PROTECTED]>
PR target/24367
* gcc.dg/pr24367.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/pr24367.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug target/24367] [4.0/4.1/4.2 Regression] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #7 from krebbel at gcc dot gnu dot org 2006-08-31 07:50 ---
Subject: Bug 24367
Author: krebbel
Date: Thu Aug 31 07:50:19 2006
New Revision: 116600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116600
Log:
2006-08-31 Andreas Krebbel <[EMAIL PROTECTED]>
PR target/24367
* config/s390/s390.md ("movsi", "movdi" expander): Accept rtxes like
r12 + SYMBOLIC_CONST.
2006-08-31 Andreas Krebbel <[EMAIL PROTECTED]>
PR target/24367
* gcc.dg/pr24367.c: New testcase.
Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr24367.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/s390/s390.md
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug target/24367] [4.0/4.1/4.2 Regression] unrecognizable insn with -fPIC -O2 -funroll-loops
--- Comment #8 from krebbel at gcc dot gnu dot org 2006-08-31 08:06 --- Although the bug is latent in gcc 4.0 as well I've applied the patch to 4.1 and 4.2 only. I could not reproduce a failure with gcc 4.0 so I've left it as is rather than risking new problems. -- krebbel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24367
[Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
--- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 --- I have been unsuccessful in reproducing this problem on a i386-redhat-linux. I don't get a failure compiling the testcase from comment 8. I tried to compile the testcase from comment 7 and got the following errors: g++ -O1 -g -ftree-vectorize -ftree-vectorizer-verbose=5 -S G2\[1].ii G2[1].ii:2154: error: integer constant is too large for âlongâ type G2[1].ii:2154: error: integer constant is too large for âlongâ type G2[1].ii:2156: error: integer constant is too large for âlongâ type G2[1].ii:425: warning: â__malloc__â attribute ignored G2[1].ii:1662: warning: no matching push for â#pragma GCC visibility popâ G2[1].ii:2065: error: âoperator newâ takes type âsize_tâ (âunsigned intâ) as first parameter G2[1].ii:2065: error: âoperator newâ takes type âsize_tâ (âunsigned intâ) as first parameter G2[1].ii:2065: error: âoperator newâ takes type âsize_tâ (âunsigned intâ) as first parameter G2[1].ii:2065: error: âoperator newâ takes type âsize_tâ (âunsigned intâ) as first parameter G2[1].ii:2065: error: âoperator newâ takes type âsize_tâ (âunsigned intâ) as first parameter G2[1].ii:2065: error: âoperator newâ takes type âsize_tâ (âunsigned intâ) as first parameter G2[1].ii: In static member function âstatic long int std::numeric_limits::min()â: G2[1].ii:2154: warning: overflow in implicit constant conversion G2[1].ii: In static member function âstatic long int std::numeric_limits::max()â: G2[1].ii:2154: warning: overflow in implicit constant conversion G2[1].ii: In static member function âstatic long unsigned int std::numeric_limits::max()â: G2[1].ii:2156: warning: overflow in implicit constant conversion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #10 from dorit at il dot ibm dot com 2006-08-31 08:22 --- I think this can be closed? (I opened a missed-optimization PR instead - PR28643) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-08-31 09:08 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-08-10 00:05:59 |2006-08-31 09:08:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug c++/28899] [4.2 regression] gimplification failed
--- Comment #4 from tbm at cyrius dot com 2006-08-31 09:55 --- (In reply to comment #3) > I almost think it was caused by the patch which fixed PR 27115. > Martin, can you try a newer gcc 4.1.2 to double check that it is not a > regression there also? No, 4.1.2 20060831 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
Re: [Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote: > > --- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 --- > I have been unsuccessful in reproducing this problem on a i386-redhat-linux. I think the failure can only reproduce on x86_64-linux-gnu and I could not get even the reduced testcase ICEing on i686-linux-gnu. Thanks, Andrew Pinski
[Bug tree-optimization/27742] [4.2 regression] ICE with -ftree-vectorizer-verbose
--- Comment #10 from pinskia at physics dot uc dot edu 2006-08-31 10:33 --- Subject: Re: [4.2 regression] ICE with -ftree-vectorizer-verbose On Thu, 2006-08-31 at 08:08 +, dorit at il dot ibm dot com wrote: > > --- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 --- > I have been unsuccessful in reproducing this problem on a i386-redhat-linux. I think the failure can only reproduce on x86_64-linux-gnu and I could not get even the reduced testcase ICEing on i686-linux-gnu. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27742
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-08-31 10:34 --- (In reply to comment #10) > I think this can be closed? Except we still crash on the 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-08-31 10:46 --- Subject: Bug 28671 Author: bkoz Date: Thu Aug 31 10:45:59 2006 New Revision: 116601 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116601 Log: 2006-08-31 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/28671 * include/bits/atomicity.h (__exchange_and_add): Declare only. (__atomic_add): Same. * config/cpu/generic/atomicity_builtins/atomicity.h: Remove comment. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/generic/atomicity_builtins/atomicity.h trunk/libstdc++-v3/include/bits/atomicity.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-31 10:59 --- Yes this was casued by that patch. Anyways we do: 1627 /* ??? The middle-end will error on us for building a VLA outside a 1628 function context. Methinks that's not it's purvey. So we'll do 1629 our own VLA layout later. */ 1630 vla_p = true; (gdb) l 1631 full_type = build_cplus_array_type (type, NULL_TREE); 1632 index = convert (sizetype, nelts); 1633 index = size_binop (MINUS_EXPR, index, size_one_node); 1634 TYPE_DOMAIN (full_type) = build_index_type (index); Which is the problem. I will look into this further either this long weekend or later today. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27184 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug c/27184] [4.0/4.1 Regression] Wrong code with pointers to arrays and types and strict aliasing
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-08-31 11:00 --- (In reply to comment #12) > So, how's this going for 4.1? Well a regression was found in 4.2 caused by this patch so I am going to fix that first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27184
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-31 11:06 --- Doing: Index: init.c === --- init.c (revision 116553) +++ init.c (working copy) @@ -1628,7 +1628,7 @@ build_new_1 (tree placement, tree type, function context. Methinks that's not it's purvey. So we'll do our own VLA layout later. */ vla_p = true; - full_type = build_cplus_array_type (type, NULL_TREE); + full_type = copy_node (build_cplus_array_type (type, NULL_TREE)); index = convert (sizetype, nelts); index = size_binop (MINUS_EXPR, index, size_one_node); TYPE_DOMAIN (full_type) = build_index_type (index); Will fix the problem but I don't know if this is the correct fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-31 11:18 --- Mine, we want/need to use build_distinct_type_copy instead but other than that it should be ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug c++/28906] [4.2 regression] rejects valid arrays
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-08-30 16:24:37 |2006-08-31 11:18:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug tree-optimization/28915] New: [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
ICE/tree check with ftree-vectorize -O2: (sid)44:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -ftree-vectorize -O2 -c xskat-xdial.c xskat-xdial.c: In function 'di_eigenertisch': xskat-xdial.c:9694: internal compiler error: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. zsh: exit 1 x86_64-unknown-linux-gnu-gcc -ftree-vectorize -O2 -c xskat-xdial.c (sid)45:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -ftree-vectorize -O1 -c xskat-xdial.c (sid)46:[EMAIL PROTECTED]: ~] x86_64-unknown-linux-gnu-gcc -O3 -c xskat-xdial.c (sid)47:[EMAIL PROTECTED]: ~] -- Summary: [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #1 from tbm at cyrius dot com 2006-08-31 12:30 --- Created an attachment (id=12160) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12160&action=view) test case Testcase from application "xskat". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug fortran/28916] New: Build of the head fails on Mac Intel
build of gfortran fails. Configure is ../configure --prefix=/opt/gcc-4_0 --with-gmp=/sw --enable-languages=fortran,c++ built fails with [...rwin8.7.1/libgfortran] /usr/local/gcc-4_0/build/./gcc/xgcc -B/usr/local/gcc-4_0/build/./gcc/ -B/opt/gcc-4_0/i686-apple-darwin8.7.1/bin/ -B/opt/gcc-4_0/i686-apple-darwin8.7.1/lib/ -isystem /opt/gcc-4_0/i686-apple-darwin8.7.1/include -isystem /opt/gcc-4_0/i686-apple-darwin8.7.1/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I. -iquote../../../libgfortran/io -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -c ../../../libgfortran/runtime/compile_options.c -o compile_options.o /var/tmp//ccWMI2VK.s:29:non-relocatable subtraction expression, "__gfortrani_compile_options" minus "L002$pb" /var/tmp//ccWMI2VK.s:29:symbol: "__gfortrani_compile_options" can't be undefined in a subtraction expression /var/tmp//ccWMI2VK.s:27:non-relocatable subtraction expression, "__gfortrani_compile_options" minus "L002$pb" /var/tmp//ccWMI2VK.s:27:symbol: "__gfortrani_compile_options" can't be undefined in a subtraction expression /var/tmp//ccWMI2VK.s:13:non-relocatable subtraction expression, "__gfortrani_compile_options" minus "L001$pb" /var/tmp//ccWMI2VK.s:13:symbol: "__gfortrani_compile_options" can't be undefined in a subtraction expression /var/tmp//ccWMI2VK.s:10:non-relocatable subtraction expression, "__gfortrani_compile_options" minus "L001$pb" /var/tmp//ccWMI2VK.s:10:symbol: "__gfortrani_compile_options" can't be undefined in a subtraction expression -- Summary: Build of the head fails on Mac Intel Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: federico dot carminati at cern dot ch GCC host triplet: Darwin Kernel Version 8.7.0 powerpc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #34 from dje at watson dot ibm dot com 2006-08-31 13:50 --- Subject: Re: [4.1/4.2 Regression] returning constant double > guenter at roeck-us dot net writes: guenter> Hmm ... what would be the point ? evlwwsplat copies 32 bit memory content into guenter> the upper and lower 32 bits of the target register. The upper part is not guenter> needed in the given case, so moving data into it would not provide any benefit. guenter> Am I missing something ? Because the pattern is emitting evmergelo/evmergehi for the r->r case, which is the equivalent data transfer and duplication, for no apparent reason. guenter> Would using evlwwsplat make subsequent optimizations more difficult ? That guenter> might be an argument against it. Other than that, I don't really care which guenter> opcodes to use, as long as the resulting code works. The choice of emitting mnemonics is performed as the very last stage, so the compiler does not have any knowledge of this if the RTL description does not express this. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug java/28891] [4.2 regression] ICE, segmentation fault
--- Comment #1 from aph at gcc dot gnu dot org 2006-08-31 13:58 --- -findirect-dispatch doesn't work with Java source. Compile to.class first. -- aph at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28891
[Bug target/27287] [4.1/4.2 Regression] returning constant double
--- Comment #35 from dje at watson dot ibm dot com 2006-08-31 14:23 --- Subject: Re: [4.1/4.2 Regression] returning constant double > guenter at roeck-us dot net writes: guenter> Hmm ... what would be the point ? evlwwsplat copies 32 bit memory content into guenter> the upper and lower 32 bits of the target register. The upper part is not guenter> needed in the given case, so moving data into it would not provide any benefit. guenter> Am I missing something ? Because the pattern is emitting evmergelo/evmergehi for the r->r case, which is the equivalent data transfer and duplication, for no apparent reason. guenter> Would using evlwwsplat make subsequent optimizations more difficult ? That guenter> might be an argument against it. Other than that, I don't really care which guenter> opcodes to use, as long as the resulting code works. The choice of emitting mnemonics is performed as the very last stage, so the compiler does not have any knowledge of this if the RTL description does not express this. David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27287
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #21 from eweddington at cso dot atmel dot com 2006-08-31 15:39 --- Created an attachment (id=12161) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12161&action=view) Patch to select 32 bit DWARF addresses for the AVR target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/19087] Overflowed address in dwarf debug line information
--- Comment #22 from eweddington at cso dot atmel dot com 2006-08-31 15:41 --- Created an attachment (id=12162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12162&action=view) Patch to add a note to the ELF file to notify the difference between old ELF files and new ELF files with different DWARF address sizes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug fortran/28916] Build of the head fails on Mac Intel
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 16:02 --- What version of gfortran are you trying to build? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Version|tree-ssa|4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-31 16:13 --- I cannot reproduce this on either a powerpc64-linux-gnu build or a i686-linux-gnu build. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC target triplet||x86-64-linux Keywords||ice-on-valid-code Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 --- It also fails with gcc 4.1 revision 116602. -- hjl at lucon dot org changed: What|Removed |Added Summary|[4.2 Regression]: |[4.1/4.2 Regression]: |fold_convert fails for |fold_convert fails for |Fortran operator|Fortran operator http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-31 16:59 --- 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=28671
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #8 from tromey at gcc dot gnu dot org 2006-08-31 17:24 --- Subject: Bug 28698 Author: tromey Date: Thu Aug 31 17:23:57 2006 New Revision: 116603 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116603 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. Modified: trunk/libjava/ChangeLog trunk/libjava/libgcj_bc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #41 from sayle at gcc dot gnu dot org 2006-08-31 17:35 --- Subject: Bug 22313 Author: sayle Date: Thu Aug 31 17:35:32 2006 New Revision: 116604 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116604 Log: PR other/22313 * dwarf2out.c (add_fde_cfi): Use a set_loc if the current label is NULL, otherwise use an advance_loc4 to adjust relative to the current label. (output_cfi) : Update the current label. (dwarf2out_switch_text_section): Reset the current label to avoid using advance_loc4 over section boundaries. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #13 from paulthomas2 at wanadoo dot fr 2006-08-31 17:41 --- Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: >--- Comment #12 from hjl at lucon dot org 2006-08-31 16:57 --- >It also fails with gcc 4.1 revision 116602. > > > > Yes, I know. I have a patch that seems to work but I do not like it very much; still, it is a sign of progress! I am rushing on this one, HJ, but I want to get it right. The problem is that operator interfaces is a part of gfortran that I have rarely touched and I do not know my way around. They have namespaces that do not have very much of anything attached to them, as far as I can see. That's why the simple fix causes a segfault. However, I cannot quite see how the symbols for the arguments are attached to the namespace. I'll be with you as soon as I have a solution - < 24hours now. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug other/22313] [4.2 Regression] profiledbootstrap is broken on the mainline
--- Comment #42 from pinskia at gcc dot gnu dot org 2006-08-31 17:53 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-31 17:57 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=116276 r116276 | mmitchel | 2006-08-20 23:53:10 + (Sun, 20 Aug 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #14 from hjl at lucon dot org 2006-08-31 18:08 ---
I don't think it is specific to operator. I got the same failure with function:
[EMAIL PROTECTED] wrf-1]$ cat yyy.f90
! { dg-do compile }
! Tests the fix for a further regression caused by the
! fix for PR28788 and posted as PR28908. The problem was
! caused by the patch preventing interface derived types
! from associating with identical derived types in the
! containing namespaces.
!
! Contributed by HJ Lu <[EMAIL PROTECTED]>
!
module bar
implicit none
public
type ESMF_Time
integer :: DD
end type
end module bar
module foo
use bar
implicit none
private
type ESMF_Clock
type(ESMF_Time) :: CurrTime
end type
interface
function add (x, y)
use bar
type(ESMF_Time) :: add
type(ESMF_Time), intent(in) :: x
type(ESMF_Time), intent(in) :: y
end function add
end interface
contains
subroutine ESMF_ClockAdvance(clock)
type(ESMF_Clock), intent(inout) :: clock
clock%CurrTime = add (clock%CurrTime, clock%CurrTime)
end subroutine ESMF_ClockAdvance
end module foo
! { dg-final { cleanup-modules "foo bar" } }
[EMAIL PROTECTED] wrf-1]$ make yyy.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -o yyy.s yyy.f90
yyy.f90: In function esmf_clockadvance:
yyy.f90:34: internal compiler error: in fold_convert, at fold-const.c:2098
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [yyy.s] Error 1
[EMAIL PROTECTED] wrf-1]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug libstdc++/24469] Possible race condition in mt_allocator causing SIGSEGV
--- Comment #8 from pcarlini at suse dot de 2006-08-31 18:08 --- Now I know how to fix it... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24469
[Bug c++/28903] [4.2 Regression] Rejects VLA in template class's member with using
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-31 18:09 --- Confirmed by Janis. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||28341 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-08-31 18:09:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28903
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #15 from hjl at lucon dot org 2006-08-31 18:11 --- I think the issue may be that gfc_get_derived_type creates a new TREE_TYPE for the same type when there is an existing one. type1 == type2 no longer works when type1 and type2 have different memory locations even if they are the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug tree-optimization/28839] [4.2 Regression] ICE in tree-vectorizer.c with -O2 -ftree-vectorize -funswitch-loops
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-08-31 18:16 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01171.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||08/msg01171.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28839
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #16 from paulthomas2 at wanadoo dot fr 2006-08-31 18:20 --- Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator HJ Yes, I think that function interfaces in general are of the same horrible kind. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ---
The previous gfc_get_derived_type tries to reuse the same TREE_TYPE:
/* In a module, if an equal derived type is already available in the
specification block, use its backend declaration and those of its
components, rather than building anew so that potential dummy and
actual arguments use the same TREE_TYPE. Non-module structures,
need to be built, if found, because the order of visits to the
namespaces is different. */
for (ns = derived->ns->parent; ns; ns = ns->parent)
{
for (dt = ns->derived_types; dt; dt = dt->next)
{
if (derived->module == NULL
&& dt->derived->backend_decl == NULL
&& gfc_compare_derived_types (dt->derived, derived))
gfc_get_derived_type (dt->derived);
if (copy_dt_decls_ifequal (dt->derived, derived))
break;
}
if (derived->backend_decl)
goto other_equal_dts;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #18 from paulthomas2 at wanadoo dot fr 2006-08-31 18:41 ---
Subject: Re: [4.1/4.2 Regression]: fold_convert fails
for Fortran operator
hjl,
>--- Comment #17 from hjl at lucon dot org 2006-08-31 18:28 ---
>The previous gfc_get_derived_type tries to reuse the same TREE_TYPE:
>
> /* In a module, if an equal derived type is already available in the
> specification block, use its backend declaration and those of its
> components, rather than building anew so that potential dummy and
> actual arguments use the same TREE_TYPE. Non-module structures,
> need to be built, if found, because the order of visits to the
> namespaces is different. */
>
> for (ns = derived->ns->parent; ns; ns = ns->parent)
>{
> for (dt = ns->derived_types; dt; dt = dt->next)
>{
> if (derived->module == NULL
>&& dt->derived->backend_decl == NULL
>&& gfc_compare_derived_types (dt->derived, derived))
>gfc_get_derived_type (dt->derived);
>
> if (copy_dt_decls_ifequal (dt->derived, derived))
>break;
>}
> if (derived->backend_decl)
>goto other_equal_dts;
>}
>
>
>
>
Yes, I was the author of that part of gfortran. Knowing it as well as I
did, I wanted to get rid of it.
Please find attached the patch (relative to trunk) that I am regtesting
now. It doesn't permit the host derived type to be renamed yet but it
does successfully deal with these problems of yours.
Thanks
Paul
Index: gcc/fortran/symbol.c
===
*** gcc/fortran/symbol.c(revision 116593)
--- gcc/fortran/symbol.c(working copy)
*** gfc_use_derived (gfc_symbol * sym)
*** 1460,1467
if (!(sym->attr.use_assoc || sym->attr.sequence))
return sym;
! /* Derived types must be defined within an interface. */
! if (gfc_current_ns->proc_name->attr.if_source == IFSRC_IFBODY)
return sym;
}
--- 1460,1469
if (!(sym->attr.use_assoc || sym->attr.sequence))
return sym;
! /* Derived types must be defined within an interface and are not
! associated until resolve.c (resolve_symbol). */
! if (gfc_current_ns->proc_name->attr.if_source
! == IFSRC_IFBODY)
return sym;
}
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 116593)
--- gcc/fortran/resolve.c (working copy)
*** resolve_symbol (gfc_symbol * sym)
*** 5681,5686
--- 5681,5715
}
}
+ if (sym->ts.type == BT_DERIVED
+ && sym->ns->proc_name->attr.if_source == IFSRC_IFBODY)
+ {
+ gfc_symbol *s;
+
+ /* Look in parent namespace for a derived type of the same name. */
+ if (gfc_find_symbol (sym->ts.derived->name, sym->ns->parent, 1, &s))
+ {
+ gfc_error ("Symbol '%s' at %C is ambiguous", sym->name);
+ return;
+ }
+
+ if (s != NULL && gfc_compare_derived_types (sym->ts.derived, s))
+ sym->ts.derived = s;
+ else
+ {
+ gfc_error ("Cannot associate type '%s' at %C", sym->name);
+ return;
+ }
+
+ if (sym->ns->proc_name->attr.function
+ && sym->ns->proc_name->ts.type == BT_DERIVED)
+ {
+ sym->ns->proc_name->ts.derived = s;
+ if (sym->ns->proc_name->result != NULL)
+ sym->ns->proc_name->result->ts.derived = s;
+ }
+ }
+
switch (sym->attr.flavor)
{
case FL_VARIABLE:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug other/28917] New: try/catch block removed. too optimistic optimization?
with fixed PR26208 we can throw exceptions from signal handlers.
catch() works pretty fine with complex call-chain but fails on
simple testcase.
#include
void signalHandler( int signalNumber )
{
throw 0;
}
int main()
{
signal( SIGSEGV, signalHandler );
try
{
int* p = 0;
*p = 0;
}
catch ( int )
{
}
return 0;
}
$ g++ throw_from_sighandler.cpp -O1 --save-temps && ./a.out
terminate called after throwing an instance of 'int'
zsh: abort ./a.out
main:
subq$8, %rsp
movl$_Z13signalHandleri, %esi
movl$11, %edi
callsignal
movl$0, 0
movl$0, %eax
addq$8, %rsp
ret
--
Summary: try/catch block removed. too optimistic optimization?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86-64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28917
[Bug other/28917] try/catch block removed. too optimistic optimization?
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 19:08 --- I think you forgot "-fnon-call-exceptions" which is need to be used if you want non calls to be able to throw. Can you try with that option and report if that fixes the problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28917
[Bug other/28917] try/catch block removed. too optimistic optimization?
--- Comment #2 from pluto at agmk dot net 2006-08-31 19:13 --- it doesn't help. `jmp .L2` skips catch block :) main: pushq %rbx movl$_Z13signalHandleri, %esi movl$11, %edi callsignal movl$0, 0 jmp .L2 .L8: cmpq$1, %rdx je .L3 movq%rax, %rdi call_Unwind_Resume .L3: movq%rax, %rdi call__cxa_begin_catch movl(%rax), %eax call__cxa_end_catch jmp .L2 .L7: movq%rax, %rbx .L4: call__cxa_end_catch movq%rbx, %rdi call_Unwind_Resume .L2: movl$0, %eax popq%rbx ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28917
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #3 from uros at kss-loka dot si 2006-08-31 19:15 ---
Confirmed on x86_64.
Backtrace:
(gdb) bt
#0 build_vector (type=0x2db3e6e0, vals=0x2db37cc0) at
../../gcc-svn/trunk/gcc/tree.c:973
#1 0x007b829d in force_const_mem (mode=V2DImode, x=0x2da089e0) at
../../gcc-svn/trunk/gcc/varasm.c:3229
#2 0x005d496a in emit_move_insn (x=0x2db309a0, y=0x2da089e0)
at ../../gcc-svn/trunk/gcc/expr.c:3288
#3 0x006b2ec6 in gen_vec_initv2di (operand0=0x2db309a0,
operand1=0x2da089d0) at ../../gcc-svn/trunk/gcc/config/i386/sse.md:3678
#4 0x005c9e37 in store_constructor (exp=0x2db37900,
target=0x2db309a0, cleared=0, size=16) at
../../gcc-svn/trunk/gcc/expr.c:5431
#5 0x005ce327 in expand_expr_real_1 (exp=0x2db37900,
target=0x2db309a0, tmode=V2DImode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fcf5800) at ../../gcc-svn/trunk/gcc/expr.c:7142
#6 0x005d40cf in expand_expr_real (exp=0x2db37900,
target=0x2db309a0, tmode=V2DImode, modifier=EXPAND_NORMAL,
alt_rtl=0x7fcf5800) at ../../gcc-svn/trunk/gcc/expr.c:6706
#7 0x005c7264 in store_expr (exp=0x2db37900,
target=0x2db309a0, call_param_p=0) at ../../gcc-svn/trunk/gcc/expr.c:4370
#8 0x005c8397 in expand_assignment (to=0x2db3e0b0,
from=0x2db37900) at ../../gcc-svn/trunk/gcc/expr.c:4249
#9 0x005cc403 in expand_expr_real_1 (exp=0x2db3c140, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:8603
#10 0x005d40cf in expand_expr_real (exp=0x2db3c140,
target=0x2d956400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at
../../gcc-svn/trunk/gcc/expr.c:6706
At the point of ICE, value dumps to:
unit size
align 64 symtab 0 alias set -1 precision 64 min max
pointer_to_this >
V2DI
size
unit size
align 128 symtab 0 alias set -1 nunits 2>
V2DI file xskat-xdial.c line 16 size unit
size
align 128
(const:DI (plus:DI (symbol_ref:DI ("lanip") [flags 0x40] )
(const_int 40 [0x28])))>
--
uros at kss-loka dot si changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-08-31 19:15:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-31 19:21 --- Can someone add the dump of -fdump-tree-final_cleanup ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug rtl-optimization/28917] try/catch block removed. too optimistic optimization?
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-31 19:27 --- Actually yes it is branched because it should be but movl$0, 0 Means store 0 into the address of 0 so it works. The branch over is ok because well this is the way zero overhead exceptions works. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|other |rtl-optimization Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28917
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #5 from tbm at cyrius dot com 2006-08-31 19:28 ---
(In reply to comment #4)
> Can someone add the dump of -fdump-tree-final_cleanup ?
;; Function set_names (set_names)
set_names (ob, idx)
{
char * * vect_ptt1.38;
vector char * vect_cst_.34;
static struct tx_typ tt1;
:
vect_cst_.34 = {&lanip[1][0], &lanip[1][0]};
vect_ptt1.38 = &tt1;
*(vector char * *) vect_ptt1.38 = vect_cst_.34;
return;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug tree-optimization/28839] [4.2 Regression] ICE in tree-vectorizer.c with -O2 -ftree-vectorize -funswitch-loops
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-08-31 19:34 --- Subject: Bug 28839 Author: rakdver Date: Thu Aug 31 19:33:56 2006 New Revision: 116605 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116605 Log: PR tree-optimization/28839 * tree-into-ssa.c (prune_unused_phi_nodes): Take into account kills in blocks in that phi arguments appear. * gcc.dg/pr28839.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr28839.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-into-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28839
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #8 from tbm at cyrius dot com 2006-08-31 20:10 ---
Is this the same bug?
(sid)59:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/g++ -c mini.c
mini.c:40: error: variable-size type declared outside of any function
mini.c:40: error: variable-size type declared outside of any function
Testcase:
extern "C"
{
typedef long unsigned int size_t;
extern size_t strlen (__const char *__s) throw () __attribute__ ((__pure__))
__attribute__ ((__nonnull__ (1)));
struct addrinfo
{
}
_G_fpos64_t;
typedef unsigned char cc_t;
}
extern char *hostname;
extern char NetTraceFile[];
void SetNetTrace (const char *);
typedef struct
{
}
Clocks;
char **genget (const char *, char **, int);
struct setlist
{
const char *name;
const char *help;
void (*handler) (const char *);
cc_t *charp;
};
static struct setlist Setlist[] = {
{
"tracefile", "file to write trace information to", SetNetTrace,
(cc_t *) NetTraceFile}
};
static struct setlist *
getset (const char *name)
{
return (struct setlist *) genget (name, (char **) Setlist,
sizeof (struct setlist));
char *hostp = __null;
{
hostname = new char[strlen (hostp) + 1];
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #9 from tbm at cyrius dot com 2006-08-31 20:21 --- Created an attachment (id=12163) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12163&action=view) preprocessed source Actually, can you please check when you get home if this is the same bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #7 from pluto at agmk dot net 2006-08-31 20:22 --- (In reply to comment #6) > The author didn't respond to my question about copyright assignment, so I > don't > think the patch can be applied. it's weird to waiting years for respond about such trivial patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-31 20:27 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=99691 r99691 | kazu | 2005-05-14 00:46:12 + (Sat, 14 May 2005) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||kazu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug tree-optimization/28900] [4.1/4.2 regression] ICE verify_stmts failed (invalid operand to unary operator)
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-31 20:28 --- (In reply to comment #5) > A regression hunt on powerpc-linux identified this patch: That means it is a latent bug :) oh well, nothing useful really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28900
[Bug tree-optimization/28905] [4.2 regression] ICE in compare_name_with_value, at tree-vrp.c:3557
--- Comment #4 from janis at gcc dot gnu dot org 2006-08-31 20:29 --- A regression hunt on powerpc-linux identified this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=116213 r116213 | rakdver | 2006-08-17 08:22:05 + (Thu, 17 Aug 2006) -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
[Bug c++/28918] New: [4.2 regression] rejects minimum/maximum operator in some c++ code
We're now rejecting the minimum/maximum operator in some c++ code.
This is a new regression. It works with 20060806.
(sid)106:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c orig.c
orig.c: In member function 'virtual void IBox::Rebuild()':
orig.c:10: error: expected primary-expression before '?' token
orig.c:10: error: expected `:' before ')' token
orig.c:10: error: expected primary-expression before ')' token
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c orig.c
(sid)107:[EMAIL PROTECTED]: ~] g++-4.1 -c orig.c
orig.c: In member function virtual void IBox::Rebuild():
orig.c:10: warning: minimum/maximum operators are deprecated
(sid)108:[EMAIL PROTECTED]: ~]
Testcase:
extern int XCopyArea (unsigned int);
class IBox
{
virtual void Rebuild ();
int Wlen, xsize;
};
void
IBox::Rebuild ()
{
XCopyArea(Wlenhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=28918
[Bug c++/28918] [4.2 regression] rejects minimum/maximum operator in some c++ code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-31 20:45 --- This extension was removed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28918
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #19 from hjl at lucon dot org 2006-08-31 21:00 --- The new patch works for the testcase. But wrf still fails: [EMAIL PROTECTED] build_base_o2.]$ /usr/gcc-4.2/bin/gfortran -c -o ESMF_Clock.fppized.o -I. -I./netcdf/include -O2 -ffast-math -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4ESMF_Clock.fppized.f90 ESMF_Clock.fppized.f90: In function esmf_clockadvance: ESMF_Clock.fppized.f90:752: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I am working on a small testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug middle-end/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #4 from luke dot powell at bjservices dot com 2006-08-31 21:59 --- (In reply to comment #3) > It is the SVN trunk, so a svn snapshot will be a snapshot of the mainline. > I attempted a rebuild with the trunk at SVN revision 116602. The compilation did get past the previous bug building __fixdfdi.o, but an almost identical bug occurred later: /home/lpowell/build-gcc/./gcc/xgcc -B/home/lpowell/build-gcc/./gcc/ -B/home/lpowell/m68k/m68k-elf/bin/ -B/home/lpowell/m68k/m68k-elf/lib/ -isystem /home/lpowell/m68k/m68k-elf/include -isystem /home/lpowell/m68k/m68k-elf/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/lpowell/gcc-trunk/gcc/gcc -I/home/lpowell/gcc-trunk/gcc/gcc/. -I/home/lpowell/gcc-trunk/gcc/gcc/../include -I/home/lpowell/gcc-trunk/gcc/gcc/../libcpp/include -I/home/lpowell/gcc-trunk/gcc/gcc/../libdecnumber -I../libdecnumber -m68000 -DL_mulsc3 -c /home/lpowell/gcc-trunk/gcc/gcc/libgcc2.c -o libgcc/m68000/_mulsc3.o /home/lpowell/gcc-trunk/gcc/gcc/libgcc2.c: In function __mulsc3: /home/lpowell/gcc-trunk/gcc/gcc/libgcc2.c:1854: internal compiler error: in do_SUBST, at combine.c:496 This error occurs at the same assertion in combine.c as the previous bug. -- luke dot powell at bjservices dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug libgcj/28698] [gcj] libgcj-bc only used when building shared libs, not executables
--- Comment #9 from tromey at gcc dot gnu dot org 2006-08-31 22:00 --- Subject: Bug 28698 Author: tromey Date: Thu Aug 31 22:00:06 2006 New Revision: 116607 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116607 Log: PR libgcj/28698: * libgcj_bc.c (DECLARE_PRIM_TYPE): New macro. Declare primitive classes. Modified: branches/redhat/gcc-4_1-branch/libjava/ChangeLog branches/redhat/gcc-4_1-branch/libjava/libgcj_bc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28698
[Bug bootstrap/26999] [4.2 Regression] bootstrap failure with --disable-libdecnumber or --disable-libcpp
--- Comment #7 from echristo at apple dot com 2006-08-31 22:14 --- After discussion with DJ I'm going to mark this as WONTFIX. We'll just allow people to shoot themselves in the foot if they try to disable a directory that they shouldn't. -- echristo at apple dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26999
[Bug libstdc++/28671] [4.2 regression] undefined reference to `__sync_fetch_and_add_4'
--- Comment #19 from bkoz at gcc dot gnu dot org 2006-08-31 22:20 --- Subject: Bug 28671 Author: bkoz Date: Thu Aug 31 22:20:09 2006 New Revision: 116608 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116608 Log: 2006-08-31 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/28671 continued * acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Don't use CXXFLAGS when checking for atomic builtins. * configure: Regenerate. * include/bits/atomicity.h: Revert. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/include/bits/atomicity.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #20 from hjl at lucon dot org 2006-08-31 22:24 --- Here it is: [EMAIL PROTECTED] wrf-1]$ cat zzz.f90 module bar implicit none public type ESMF_Time sequence integer :: MM end type public operator (+) private add interface operator (+) module procedure add end interface contains function add (x, y) type(ESMF_Time) :: add type(ESMF_Time), intent(in) :: x type(ESMF_Time), intent(in) :: y add = x end function add end module bar module foo use bar implicit none private type ESMF_Clock sequence type(ESMF_Time) :: CurrTime end type contains subroutine ESMF_ClockAdvance(clock) use bar type(ESMF_Clock), intent(inout) :: clock clock%CurrTime = clock%CurrTime + clock%CurrTime end subroutine ESMF_ClockAdvance end module foo [EMAIL PROTECTED] wrf-1]$ make zzz.s /usr/gcc-4.2/bin/gfortran -O2 -ffast-math -S -o zzz.s zzz.f90 zzz.f90: In function esmf_clockadvance: zzz.f90:31: internal compiler error: in fold_convert, at fold-const.c:2098 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [zzz.s] Error 1 [EMAIL PROTECTED] wrf-1]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #18 from jconner at gcc dot gnu dot org 2006-08-31 23:44 --- Subject: Bug 25505 Author: jconner Date: Thu Aug 31 23:44:00 2006 New Revision: 116613 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116613 Log: 2006-08-31 Josh Conner <[EMAIL PROTECTED]> PR c++/25505 * tree-gimple.c (is_gimple_mem_rhs): Recognize functions returning aggregates. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-gimple.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug target/28919] New: overzealous pointer coalescence leading to poor encoding
With code like this (see attachement for a complete silly test case),
unsigned int quad = 0;
for (unsigned int dec=node.count/4; dec; --dec) {
_mm_prefetch(1024+(const char *)&base[quad], _MM_HINT_NTA);
sampler.countl[0] = _mm_add_epi32(sampler.countl[0],
_mm_cmpgt_epi32(sampler.pos[0], base[quad+0]));
sampler.countl[1] = _mm_add_epi32(sampler.countl[1],
_mm_cmpgt_epi32(sampler.pos[1], base[quad+0]));
sampler.countl[0] = _mm_add_epi32(sampler.countl[0],
_mm_cmpgt_epi32(sampler.pos[0], base[quad+1]));
sampler.countl[1] = _mm_add_epi32(sampler.countl[1],
_mm_cmpgt_epi32(sampler.pos[1], base[quad+1]));
sampler.countl[0] = _mm_add_epi32(sampler.countl[0],
_mm_cmpgt_epi32(sampler.pos[0], base[quad+2]));
sampler.countl[1] = _mm_add_epi32(sampler.countl[1],
_mm_cmpgt_epi32(sampler.pos[1], base[quad+2]));
sampler.countl[0] = _mm_add_epi32(sampler.countl[0],
_mm_cmpgt_epi32(sampler.pos[0], base[quad+3]));
sampler.countl[1] = _mm_add_epi32(sampler.countl[1],
_mm_cmpgt_epi32(sampler.pos[1], base[quad+3]));
quad += 4;
}
g++ 4.2 insists to use the same register for addressing 'base[quad]' and
prefetching 1k away from it. Horrible encoding ensues.
With gcc-4.2-20060311/gcc-4.2-20060826 -O3 -march=k8 i get something like
401080: 66 0f 6f c2 movdqa %xmm2,%xmm0
401084: 0f 18 00prefetchnta (%eax)
401087: 66 0f 66 80 00 fc ff ff pcmpgtd 0xfc00(%eax),%xmm0
40108f: 66 0f fe 42 20 paddd 0x20(%edx),%xmm0
401094: 0f 29 42 20 movaps %xmm0,0x20(%edx)
401098: 66 0f 6f c1 movdqa %xmm1,%xmm0
40109c: 66 0f 66 80 00 fc ff ff pcmpgtd 0xfc00(%eax),%xmm0
4010a4: 66 0f fe 42 30 paddd 0x30(%edx),%xmm0
4010a9: 0f 29 42 30 movaps %xmm0,0x30(%edx)
4010ad: 66 0f 6f c2 movdqa %xmm2,%xmm0
4010b1: 66 0f 66 80 10 fc ff ff pcmpgtd 0xfc10(%eax),%xmm0
4010b9: 66 0f fe 42 20 paddd 0x20(%edx),%xmm0
4010be: 0f 29 42 20 movaps %xmm0,0x20(%edx)
4010c2: 66 0f 6f c1 movdqa %xmm1,%xmm0
etc...
There's other issues with the code produced, ie gcc writing back values instead
of just keeping them live, but i can kludge around them.
But i cannot fix that silly encoding.
msvc8, icc9.1 and g++ 3.4.4 do a much better job, here's g++ 3.4.4
401084: prefetchnta 0x400(%eax)
40108b: movdqa %xmm5,%xmm2
40108f: movdqa %xmm4,%xmm1
401093: movdqa %xmm3,%xmm0
401097: pcmpgtd (%eax),%xmm2
40109b: paddd %xmm2,%xmm6
40109f: movaps %xmm6,0x20(%edx)
4010a3: movdqa %xmm5,%xmm2
4010a7: pcmpgtd (%eax),%xmm1
4010ab: paddd %xmm1,%xmm0
4010af: movaps %xmm0,0x30(%edx)
4010b3: movdqa %xmm4,%xmm1
4010b7: pcmpgtd 0x10(%eax),%xmm2
4010bc: paddd %xmm2,%xmm6
4010c0: movaps %xmm6,0x20(%edx)
Note that -fprefetch-loop-arrays's heuristic is way off the mark and
counterproductive, even for that simplified testcase.
--
Summary: overzealous pointer coalescence leading to poor encoding
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbptbp at gmail dot com
GCC host triplet: x86*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug target/28919] overzealous pointer coalescence leading to poor encoding
--- Comment #1 from tbptbp at gmail dot com 2006-09-01 01:55 --- Created an attachment (id=12164) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12164&action=view) test case source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug target/28919] overzealous pointer coalescence leading to poor encoding
--- Comment #2 from tbptbp at gmail dot com 2006-09-01 01:56 --- Created an attachment (id=12165) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12165&action=view) test case preprocessed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug target/28919] overzealous pointer coalescence leading to poor encoding
--- Comment #3 from tbptbp at gmail dot com 2006-09-01 02:04 --- Hmm, that description is a bit wrong. What i really mean is that gcc trades x long encodings for 1 short instead of other way around. Bear with me, it's rather late here :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug target/28919] IV selection is messed up
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-09-01 02:46 --- Actually this is just a problem of IV selection, what is happening is the IV selection chooses the 1024+(const char *)&base[quad] as the IV instead of just &base[quad] which causes the bigger encoding. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|overzealous pointer |IV selection is messed up |coalescence leading to poor | |encoding| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug target/28919] IV selection is messed up
--- Comment #5 from tbptbp at gmail dot com 2006-09-01 02:53 --- (In reply to comment #4) > Actually this is just a problem of IV selection, what is happening is the IV > selection chooses the 1024+(const char *)&base[quad] as the IV instead of just > &base[quad] which causes the bigger encoding. Ok. I've tried many things but i totally fail to get that IV selection to take a pick the other way around; i'd apreciate a clue :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28919
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-01 04:01 --- (In reply to comment #9) > Actually, can you please check when you get home if this is the same bug? Yes this is the same bug as my patch (which I am about to submut) fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug tree-optimization/28839] [4.2 Regression] ICE in tree-vectorizer.c with -O2 -ftree-vectorize -funswitch-loops
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-01 04:02 --- 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=28839
[Bug fortran/28916] Build of the head fails on Mac Intel
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-01 04:20 --- Also what version of Xcode do you have installed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28916
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-09-01 04:49 --- I did not add a testcase for one that just ICE but I did add two testcases, one for the wrong code and one for the rejecting valid. The ICE is because of templates which I don't feel like needing a testcase for that really since the other two should be enough to detect the problem in the future. I also added a testcase to make sure that two seperate variables does change the shared incomplete shared type either. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||09/msg7.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug c++/28906] [4.2 regression] rejects valid arrays
--- Comment #12 from patchapp at dberlin dot org 2006-09-01 04:51 --- Subject: Bug number PR C++/28906 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-09/msg7.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28906
[Bug fortran/28908] [4.1/4.2 Regression]: fold_convert fails for Fortran operator
--- Comment #21 from paulthomas2 at wanadoo dot fr 2006-09-01 04:58 --- Subject: Re: [4.1/4.2 Regression]: fold_convert fails for Fortran operator hjl at lucon dot org wrote: Thanks HJ. It seems that I am going to have to revert this one; I have spent way too much time on it and wasted a load of yours as well. At least the testsuite is enormously improved! Paul >--- Comment #20 from hjl at lucon dot org 2006-08-31 22:24 --- >Here it is: > >[EMAIL PROTECTED] wrf-1]$ cat zzz.f90 >module bar > implicit none > public > type ESMF_Time > sequence >integer :: MM > end type > public operator (+) > private add > interface operator (+) > module procedure add > end interface >contains >function add (x, y) > type(ESMF_Time) :: add > type(ESMF_Time), intent(in) :: x > type(ESMF_Time), intent(in) :: y > add = x >end function add >end module bar > >module foo > use bar > implicit none > private > type ESMF_Clock > sequence >type(ESMF_Time) :: CurrTime > end type >contains > subroutine ESMF_ClockAdvance(clock) > use bar >type(ESMF_Clock), intent(inout) :: clock >clock%CurrTime = clock%CurrTime + clock%CurrTime > end subroutine ESMF_ClockAdvance >end module foo >[EMAIL PROTECTED] wrf-1]$ make zzz.s >/usr/gcc-4.2/bin/gfortran -O2 -ffast-math -S -o zzz.s zzz.f90 >zzz.f90: In function esmf_clockadvance: >zzz.f90:31: internal compiler error: in fold_convert, at fold-const.c:2098 >Please submit a full bug report, >with preprocessed source if appropriate. >See http://gcc.gnu.org/bugs.html> for instructions. >make: *** [zzz.s] Error 1 >[EMAIL PROTECTED] wrf-1]$ > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
[Bug tree-optimization/28905] [4.2 regression] ICE in compare_name_with_value, at tree-vrp.c:3557
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-01 05:14 ---
For 4.1, we get:
i_1: VARYING
size_2: VARYING
size_3: [size_2, size_2] EQUIVALENCES: { size_2 } (1 elements)
i_4: [0, +INF] EQUIVALENCES: { i_1 i_7 i_8 i_9 } (4 elements)
n_5: [0, size_2 - 1] EQUIVALENCES: { i_1 i_9 } (2 elements)
i_6: [1, +INF] EQUIVALENCES: { } (0 elements)
i_7: [0, +INF] EQUIVALENCES: { i_1 i_8 i_9 } (3 elements)
i_8: ~[0, 0] EQUIVALENCES: { i_1 i_9 } (2 elements)
i_9: [0, size_2 - 1] EQUIVALENCES: { i_1 } (1 elements)
While on the mainline, we get:
i_1: VARYING
size_2: VARYING
size_3: [size_2, size_2] EQUIVALENCES: { size_2 } (1 elements)
n_5: [0, size_2 - 1] EQUIVALENCES: { i_1 i_9 } (2 elements)
i_6: ~[0, 0] EQUIVALENCES: { } (0 elements)
i_7: [-INF, -1] EQUIVALENCES: { i_8 i_9 } (2 elements)
i_8: ~[0, 0] EQUIVALENCES: { i_9 } (1 elements)
i_9: [0, size_2 - 1] EQUIVALENCES: { i_1 } (1 elements)
Note the missing of i_4, yes it is there in the IR too really so maybe this is
a VRP problem. I have not looked at the dump before the patch to make sure it
was the same.
Anyways the ICE is because i_7 and i_7 are not equivalant as detected by VRP,
though I say it is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28905
[Bug tree-optimization/26969] [4.1 Regression] ICE with -O1 -funswitch-loops -ftree-vectorize
--- Comment #12 from dorit at il dot ibm dot com 2006-09-01 05:43 --- oops - I didn't notice it was open against 4.1. So hopefully porting Victor's patch to 4.1 would fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
[Bug c++/28899] [4.2 regression] gimplification failed
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-01 05:46 --- Janis, Could you run a regression hunt on this bug? Thanks, Andrew -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
[Bug c++/28899] [4.2 regression] gimplification failed
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-01 05:52 --- (In reply to comment #4) > No, 4.1.2 20060831 works. Well the ICE can only happen with checking turned on so it could still be a bug in 4.1.2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
[Bug c++/27115] [4.0/4.1 Regression] ICE in cp_expr_size or miscompilation with statement expressions and constructors (and ?: )
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug c++/28899] [/4.2 regression] gimplification failed
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-01 06:11 ---
Here is an even more reduced testcase:
void f(void)
{
unsigned l, l1;
l1 = l = ({unsigned __v; __v;});
}
Note the double use is required to ICE, otherwise we are ok.
There is no question about it after looking at the patch for PR 27115, that
patch caused this ICE. We used to create a temporary variable but now we
don't.
(In reply to comment #6)
> Well the ICE can only happen with checking turned on so it could still be a
> bug in 4.1.2.
Actually it cannot be as that patch was only applied to the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
BugsThisDependsOn||27115
Severity|normal |blocker
Known to work|4.0.3 4.1.1 |4.0.3 4.1.1 4.0.4 4.1.2
Summary|[4.2 regression]|[/4.2 regression]
|gimplification failed |gimplification failed
Target Milestone|4.2.0 |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28899
[Bug tree-optimization/28915] [4.2 regression] ICE: tree check: expected class 'constant', have 'declaration' (var_decl) in build_vector, at tree.c:973
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-09-01 06:27 ---
Here is a testcase which ICEs for i686-linux-gnu with -msse:
extern char lanip[3][40];
typedef struct
{
char *t[4];
}tx_typ;
int set_names (void)
{
static tx_typ tt1;
int ln;
for (ln = 0; ln < 4; ln++)
tt1.t[ln] = lanip[1];
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28915
[Bug tree-optimization/28920] New: vectorizer produces vector long long on powerpc-linux-gnu (and vector long on powerpc64)
Take the following testcase:
extern char lanip[3][40];
typedef struct
{
char *t[4];
}tx_typ;
int set_names (void)
{
static tx_typ tt1;
int ln;
for (ln = 0; ln < 4; ln++)
tt1.t[ln] = lanip[1];
}
-
With -O2 -ftree-vectorize -maltivec, we produce a vector long long and we get
worse code than just doing the scalar code as VMX does not have a vector long
long mode. We really should be asking the target if we support a vector mode.
I noticed this while looking into PR 28915.
--
Summary: vectorizer produces vector long long on powerpc-linux-
gnu (and vector long on powerpc64)
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: piowerpc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28920
[Bug c/28921] New: vector of a pointer type does not give a warning or error that we are ignoring vector
Testcase:
typedef char *cptr;
char *a;
__attribute__ ((vector_size(16))) cptr t;
int f(void)
{
__attribute__ ((vector_size(16))) int t1 =
(__attribute__ ((vector_size(16))) int )t;
}
We get an error about converting t to a vector int but t looks to me a vector
of a char pointer. This happens with both the C and C++ front-ends.
--
Summary: vector of a pointer type does not give a warning or
error that we are ignoring vector
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28921
[Bug c/28921] vector of a pointer type does not give a warning or error that we are ignoring vector
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-01 06:45 ---
Actually this is weird, we are applying the vector_size attribute to the inner
type instead of to the typedef type which seems more appropriate. It is
evident we are applying the attribute by adding * infront of t in the function
like:
int f(void)
{
__attribute__ ((vector_size(16))) int t1 =
(__attribute__ ((vector_size(16))) int )*t;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28921
[Bug c/28921] vector of a typedef applies the vector to the inner most type instead of erroring/warning out that vector does not apply
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-01 06:51 --- The same thing happens with arrays: typedef char cptr[2]; __attribute__ ((vector_size(16))) cptr t; -- And pointer to arrays: typedef char cptr[1]; typedef cptr *cptr1; extern __attribute__ ((vector_size(16))) cptr1 t; - This has been a bug since the begining of the vector_size attribute. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.2.3 3.4.0 3.3.3 4.1.0 ||4.2.0 4.0.0 Summary|vector of a pointer type|vector of a typedef applies |does not give a warning or |the vector to the inner most |error that we are ignoring |type instead of |vector |erroring/warning out that ||vector does not apply http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28921
