[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #2 from ubizjak at gmail dot com 2010-05-09 07:25 --- From config/driver-i386.c [...] case PROCESSOR_PENTIUMPRO: if (model == 28) cpu = atom; else if (model = 28 l2sizekb 2048) /* Assume it's a small core if there's less than 2MB cache */ cpu = atom; else if (has_longmode) cpu = core2; And from cpuid: cpu family : 6 model : 37 cache size : 3072 KB driver detects --param l2-cache-size=3072 and -march=atom ... WTF ? Can you please step through the driver with debugger and determine _exact_ values of model and l2sizekb in the above source? It is around line 540 in gcc/config/i386/driver-i386.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug fortran/31820] Warning if case label value exceeds maximum value for type
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-09 09:11 --- (In reply to comment #4) It should be sufficient to convert all case-selectors to the same kind as the case-expression. We should then be giving exactly the same error as g95, unless I'm missing something. This is directly contradicting the conclusion reached in PR19168 where it was decided that the case-expr should be promoted to the largest kind of the case-values (short summary: case values shall be of the same type, but only character expressions are required to be of same kind, hence apply the same conversion rules as for direct comparison; see F2003, C805 (R808); F2008, C832 (R838)). In the example below, the comparison done for the IF statement is promoted to default integer kind (see dump), no warning is generated for the unreachable branch. Same holds for the equivalent SELECT. INTEGER(KIND=1) i i = 100 IF (i == 200) THEN print *, unreachable! ELSE print *, default! END IF SELECT CASE (i) CASE (200) print *, unreachable! CASE DEFAULT print *, default! END SELECT END Nonetheless, I also think that it is counter-intuitive. The least that could be done: add a warning (-Wconversion? -Wsurprising?) before converting the case-expr, mentioning that at least one case-value has a kind larger than the case-expressions kind, which thus can not be reached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
[Bug fortran/44047] New: [OOP] SELECT TYPE with associate-name and allocatable selector
The following test case is a modified version of the one in http://gcc.gnu.org/ml/fortran/2009-10/msg00047.html: implicit none type t0 integer :: j = 42 end type t0 type t integer :: i class(t0), allocatable :: foo end type t type(t) :: m allocate(t0 :: m%foo) m%i = 5 select type(bar = m%foo) type is(t0) print *, bar end select end While the original version (using allocatable CLASS arrays) still ICEs, this one here compiles cleanly, but gives a double free runtime error. The reason for this error is that we generate a local temporary for bar, which is auto-deallocated at the end of the SELECT TYPE block, so that the auto-deallocation of m%foo fails. The auto-deallocation of bar should not happen, i.e. bar should not have the ALLOCATABLE attribute (currently the dump shows struct .class.t0.a bar). -- Summary: [OOP] SELECT TYPE with associate-name and allocatable selector Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44047
[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault
--- Comment #6 from lynczu at gmail dot com 2010-05-09 09:58 --- reopened then -- lynczu at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|libstdc++ |c++ Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
[Bug fortran/32817] MODULE functions are not inlined
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-09 10:02 --- With -fwhole-file I now get the same timings either way. I call that fixed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||40011 nThis|| Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #7 from alex dot pyattaev at gmail dot com 2010-05-09 10:29
---
I have encountered the bug with switch construct. And the problem is not the
error message, but the fact that it is still compiling just fine this code:
switch (chan_prop.model_type)
{
case CM_STATIC:
return static_channel_model(src, ntransmitters, dst,
chan_prop);
case CM_FRISS:
return friss_channel_model(src, ntransmitters, dst,
chan_prop);
default:
return -1;
}
There should be some consistency at least! I'd like to see this fixed properly.
The compiler should be perfectly predictable, and not like Sorry, i don't like
this construct here... put a semicolon please.
I'd like this bug to be reopened and FIXED PROPERLY
gcc --version = (Gentoo 4.4.3-r2 p1.2) 4.4.3
--
alex dot pyattaev at gmail dot com changed:
What|Removed |Added
CC||alex dot pyattaev at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug c/44042] [4.1/4.2/4.4/4.5/4.6 Regression] Missing warning for unitialized varaible in switch statement
--- Comment #4 from tkoenig at gcc dot gnu dot org 2010-05-09 11:12 --- Sorry, I cannot parse CCP exploits undefined behavior. Why should there be no warning for this, when this warning was present in gcc 3.x? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44042
[Bug c/44042] [4.1/4.2/4.4/4.5/4.6 Regression] Missing warning for unitialized varaible in switch statement
--- Comment #5 from rguenther at suse dot de 2010-05-09 11:13 --- Subject: Re: [4.1/4.2/4.4/4.5/4.6 Regression] Missing warning for unitialized varaible in switch statement On Sun, 9 May 2010, tkoenig at gcc dot gnu dot org wrote: --- Comment #4 from tkoenig at gcc dot gnu dot org 2010-05-09 11:12 --- Sorry, I cannot parse CCP exploits undefined behavior. Why should there be no warning for this, when this warning was present in gcc 3.x? because we optimize better now and the code has vanished before we get a chance to emit the warning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44042
[Bug rtl-optimization/44043] sorry, unimplemented: inlining failed in call to 'dst_output': optimizing for size and code size would grow
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-09 11:29 --- Created an attachment (id=20611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20611action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
[Bug fortran/44044] [OOP] SELECT TYPE with class-valued function
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-09 11:55:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44044
[Bug c/44048] New: dbxout.c:1870: error: NULLPTR_TYPE undeclared
When I attempt to compile the May 8 snapshot on any platform I get the following messages: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/home/mrichmon/gcc-4.6-20100508/gcc -I/home/mrichmon/gcc-4.6-20100508/gcc/. -I/home/mrichmon/gcc-4.6-20100508/gcc/../include -I/home/mrichmon/gcc-4.6-20100508/gcc/../libcpp/include -I/home/mrichmon/mpc-0.8.1/src -I/home/mrichmon/gcc-4.6-20100508/gcc/../libdecnumber -I/home/mrichmon/gcc-4.6-20100508/gcc/../libdecnumber/dpd -I../libdecnumber /home/mrichmon/gcc-4.6-20100508/gcc/dbxout.c -o dbxout.o /home/mrichmon/gcc-4.6-20100508/gcc/dbxout.c: In function âdbxout_typeâ: /home/mrichmon/gcc-4.6-20100508/gcc/dbxout.c:1870: error: âNULLPTR_TYPEâ undeclared (first use in this function) /home/mrichmon/gcc-4.6-20100508/gcc/dbxout.c:1870: error: (Each undeclared identifier is reported only once /home/mrichmon/gcc-4.6-20100508/gcc/dbxout.c:1870: error: for each function it appears in.) make[3]: *** [dbxout.o] Error 1 make[3]: Leaving directory `/home/mrichmon/gcc-4.6-20100508/g95/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/mrichmon/gcc-4.6-20100508/g95' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/mrichmon/gcc-4.6-20100508/g95' make: *** [all] Error 2 Error running make -- Summary: dbxout.c:1870: error: NULLPTR_TYPE undeclared Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44048
[Bug fortran/31820] Warning if case label value exceeds maximum value for type
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-09 12:59 --- (In reply to comment #5) Nonetheless, I also think that it is counter-intuitive. The least that could be done: add a warning (-Wconversion? -Wsurprising?) before converting the case-expr, mentioning that at least one case-value has a kind larger than the case-expressions kind, which thus can not be reached. Suggested patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00084.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31820
[Bug fortran/35161] Add warning about procedures with same C binding label and different interface
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-09 13:14 --- *** Bug 41704 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161
[Bug fortran/41704] [F2008?] Different local names in interfaces for same C-binding name/same procedure
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-09 13:14 --- *** This bug has been marked as a duplicate of 35161 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41704
[Bug fortran/35031] ELEMENTAL procedure with BIND(C)
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-09 13:34 --- (In reply to comment #1) Draft 2003 corrigendum 3: ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1727.pdf (Not yet sent to ISO and thus also not ISO approved.) See ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1731.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35031
[Bug rtl-optimization/42522] (zero_extract:SI (mem:QI) ...) misoptimized
--- Comment #14 from ami_stuff at o2 dot pl 2010-05-09 13:54 --- Any chance to see this bug fixed in the near future? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42522
[Bug target/43610] [4.5/4.6 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #10 from zsojka at seznam dot cz 2010-05-09 14:01 --- I hope my comment wasn't misunderstood - the patch from comment #5 fixes several FAILs and doesn't introduce any regressions (at least in r158150) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug fortran/38386] Update BIND(C,name=) checking for Fortran 2008
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-09 14:08 --- *** This bug has been marked as a duplicate of 35161 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38386
[Bug fortran/35161] Add warning about procedures with same C binding label and different interface
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-09 14:08 --- *** Bug 38386 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161
[Bug fortran/35161] [F2008] allow procedures with same binding label (invalid in F2003)
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-09 14:10 --- Adjusted summary to match information given in dupes. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||39627 nThis|| Summary|Add warning about procedures|[F2008] allow procedures |with same C binding label |with same binding label |and different interface |(invalid in F2003) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161
[Bug rtl-optimization/44043] sorry, unimplemented: inlining failed in call to 'dst_output': optimizing for size and code size would grow
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-09 14:13 --- Subject: Bug 44043 Author: rguenth Date: Sun May 9 14:13:25 2010 New Revision: 159200 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159200 Log: 2010-05-09 Richard Guenther rguent...@suse.de PR middle-end/44043 * ipa-inline.c (estimate_function_body_sizes): Return after disregarding inline limits. * gcc.c-torture/compile/pr44043.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr44043.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
[Bug target/43610] [4.5/4.6 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #11 from bonzini at gnu dot org 2010-05-09 14:14 --- Patch posted now. Sorry, I was busy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug rtl-optimization/44043] sorry, unimplemented: inlining failed in call to 'dst_output': optimizing for size and code size would grow
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-09 14:14 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #27 from dominiq at lps dot ens dot fr 2010-05-09 14:19 --- VEC_safe_push is quite safe, actually. But it may re-allocate the VEC. If you really believe that VEC_safe_push is the problem here, then you should perhaps look if a VEC is being passed around incorrectly somewhere, so that reallocating it would make things disappear. Could you give me more precise idea about what I am supposed to do to look if a VEC is being passed around incorrectly somewhere? BTW I would think the problem is not before some reallocation, but after it, see: ... . The latter will reallocate the vector, if needed. Reallocation causes an exponential increase in vector size. I have found a long comment at the beginning of gcc/vec.h, is VEC_safe_push documented elsewhere? I have done the following changes in the subroutine s9.f90: (1) --- s9.f90 2010-04-18 22:04:36.0 +0200 +++ s9_yy.f90 2010-05-09 15:19:43.0 +0200 @@ -45,6 +45,7 @@ NDPdt , NDBsor , NHSor DOUBLE PRECISION M , cc(22,2) coef = 144.D+00/778.D+00 + zzz = 1.0/VVFs DO i = 2 , NC1 j = i - 1 ity = ITYp(i) and I get the same assembly compared with the original one (for both revision 159105 and 159106). (2) --- s9.f90 2010-04-18 22:04:36.0 +0200 +++ s9_xx.f90 2010-05-09 15:22:25.0 +0200 @@ -45,6 +45,7 @@ NDPdt , NDBsor , NHSor DOUBLE PRECISION M , cc(22,2) coef = 144.D+00/778.D+00 + zzz = 1.0/VVFs DO i = 2 , NC1 j = i - 1 ity = ITYp(i) @@ -76,7 +77,7 @@ AA(i,k) = VV(i,k)*DM(i,k) + DVVh(i,k)*cc(i,k) DV(i,k) = AA(i,k) + BB(i,k)*DPDt IF ( DABS(DV(i,k)).LT.1.D-10 ) DV(i,k) = 0.D+00 - epsm = DELm*VC(i)/VVFs + epsm = DELm*VC(i)*zzz ym = M(i,k) IF ( ym.LT.epsm ) ym = epsm DH(i,k) = (cc(i,k)+coef*V(i,k)*DPDt)/ym i.e., I have replaced the division with the multiplication by the inverse (if I am not mistaken, this optimization is done with revision 159105 but not with 159106). The assembly is very different and the executable does not crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-09 14:43 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00606.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||05/msg00606.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-09 14:43:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #4 from hjl at gcc dot gnu dot org 2010-05-09 14:50 --- Subject: Bug 44046 Author: hjl Date: Sun May 9 14:49:53 2010 New Revision: 159202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159202 Log: Properly detect Atom, Core 2 and Core i7. 2010-05-09 H.J. Lu hongjiu...@intel.com PR target/44046 * config/i386/driver-i386.c (host_detect_local_cpu): Properly detect Atom, Core 2 and Core i7. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #5 from hjl at gcc dot gnu dot org 2010-05-09 14:53 --- Subject: Bug 44046 Author: hjl Date: Sun May 9 14:53:00 2010 New Revision: 159203 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159203 Log: Properly detect Atom, Core 2 and Core i7. 2010-05-09 H.J. Lu hongjiu...@intel.com Backport from mainline 2010-05-09 H.J. Lu hongjiu...@intel.com PR target/44046 * config/i386/driver-i386.c (host_detect_local_cpu): Properly detect Atom, Core 2 and Core i7. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/driver-i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #17 from dougmencken at gmail dot com 2010-05-09 14:56 --- ../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber ../.././gcc/rtlhooks.c -o rtlhooks.o /root/build-farm/gcc-4.5.0.srcpkg/host-powerpc-gnu-linux-uclibc/prev-gcc/xgcc -B/root/build-farm/gcc-4.5.0.srcpkg/host-powerpc-gnu-linux-uclibc/prev-gcc/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -B/usr/powerpc-gnu-linux-uclibc/lib/ -isystem /usr/powerpc-gnu-linux-uclibc/include -isystem /usr/powerpc-gnu-linux-uclibc/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber ../.././gcc/sbitmap.c -o sbitmap.o /root/build-farm/gcc-4.5.0.srcpkg/host-powerpc-gnu-linux-uclibc/prev-gcc/xgcc -B/root/build-farm/gcc-4.5.0.srcpkg/host-powerpc-gnu-linux-uclibc/prev-gcc/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -B/usr/powerpc-gnu-linux-uclibc/lib/ -isystem /usr/powerpc-gnu-linux-uclibc/include -isystem /usr/powerpc-gnu-linux-uclibc/sys-include-c -g -O2 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/dpd -I../libdecnumber ../.././gcc/sched-deps.c -o sched-deps.o ../.././gcc/sched-deps.c: In function 'get_dep_weak_1': ../.././gcc/sched-deps.c:3841:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [sched-deps.o] Error 1 make[3]: Leaving directory `/root/build-farm/gcc-4.5.0.srcpkg/host-powerpc-gnu-linux-uclibc/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/root/build-farm/gcc-4.5.0.srcpkg' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/root/build-farm/gcc-4.5.0.srcpkg' make: *** [all] Error 2 Command exited with non-zero status 2 real7h 47m 02s user5h 39m 43s sys 13m 48.43s Tried to bootstrap GCC 4.5.0. Again. How TO REPRODUCE IT WITH CROSS COMPILER? No way. Just try to build it native. And not on x86 (i386, i486, i586, i586mmx, i686, , x86_64, x86_64_4cores, ..). AGAIN: NOT ON intel compatible x86 or 100% compatible amd or intel compatible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #8 from manu at gcc dot gnu dot org 2010-05-09 15:26 --- (In reply to comment #7) There should be some consistency at least! I'd like to see this fixed properly. The compiler should be perfectly predictable, and not like Sorry, i don't like It is predictable: a label can only be part of a statement and a declaration is not a statement. Now return x; is a statement, so it compiles fine. This is mandated by the C standard, it is not the compiler's decision. Does it work different with any other compiler? Please, tell us what is difficult to understand in the error message and how could it be better explained. On the other hand, I don't know whether if GCC adds an empty statement before the declaration and just emits a warning with -pedantic, then it still complies with the C standard. I don't have time to investigate this, sorry. this construct here... put a semicolon please. I'd like this bug to be reopened and FIXED PROPERLY gcc --version = (Gentoo 4.4.3-r2 p1.2) 4.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
-- hjl dot tools at gmail dot com changed: What|Removed |Added Known to work||4.5.1 4.6.0 Target Milestone|--- |4.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-05-09 16:10 --- It appears that r159202 (for gcc trunk) and r159203 (for gcc-4_5-branch) has escalated this problem by defaulting some chipsets to the core2 tuning. PR34501 should be bumped to a P1 for both gcc trunk and gcc-4_5-branch to make sure it gets fixed before the next releases. Otherwise users of Nehalem, Westmere, Penryn and Merom class processors will find their default code generation pessimized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34501
[Bug c/4784] Anonymous structs issues
--- Comment #7 from jsm28 at gcc dot gnu dot org 2010-05-09 16:20 --- Subject: Bug 4784 Author: jsm28 Date: Sun May 9 16:19:28 2010 New Revision: 159204 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159204 Log: PR c/4784 * c-decl.c (detect_field_duplicates_hash): New. Handle anonymous structures and unions recursively. (detect_field_duplicates): Move duplicate detection with a hash to detect_field_duplicates_hash. Always use a hash if anonymous structures or unions are present. * doc/extend.texi (Unnamed Fields): Document that duplicate fields give errors. testsuite: * gcc.dg/anon-struct-9.c: New test. Added: trunk/gcc/testsuite/gcc.dg/anon-struct-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-decl.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4784
[Bug c/4784] Anonymous structs issues
--- Comment #8 from jsm28 at gcc dot gnu dot org 2010-05-09 16:21 --- Fixed for 4.6. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4784
[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault
--- Comment #7 from dougsemler at gmail dot com 2010-05-09 16:24 ---
Reduced test case:
# 1 gcc_bug2.cc
# 1 built-in
# 1 command-line
# 1 gcc_bug2.cc
struct base
{
virtual ~base() { }
};
int main()
{
base ptr_array[1];
ptr_array = { base() };
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
[Bug rtl-optimization/44043] sorry, unimplemented: inlining failed in call to 'dst_output': optimizing for size and code size would grow
--- Comment #8 from justinmattock at gmail dot com 2010-05-09 16:25 --- o.k... First Thank you vary much for helping me on this. and second: I added your patch: PR middle-end/44043 * ipa-inline.c (estimate_function_body_sizes): Return after disregarding inline limits. and am in the process of building gcc(should take about an hour or so), then I'll see if the kernel compiles. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-09 16:47 --- Many thanks, this will help the debugging a lot. CC-ing Jason... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
[Bug middle-end/25140] aliases, including weakref, break alias analysis
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-09 16:49 --- For globals we could track this properly by using the varpool nodes instead of the DECL_UID to do disambiguation. Queued. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-09-26 10:09:53 |2010-05-09 16:49:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25140
[Bug middle-end/24332] asm label declaration may be missing aliasing info
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-09 16:51 --- If we'd have a symbol table we could detect the clash and emit a diagnostic. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24332
[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-09 16:51:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
[Bug middle-end/21602] builtin memmove could be memcpy if src and dst don't alias
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-09 16:54 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-30 03:12:56 |2010-05-09 16:54:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21602
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #24 from paolo dot carlini at oracle dot com 2010-05-09 16:57 --- Silvius, can you prepare a simple patch vs current gcc-4_5-branch? We have time for mainline, but it is also safe to apply at the same time something simple to mainline too and then improve it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-05-09 17:09 --- alias-export is now merged so the RTL level should have the same alias information as the tree level. And thus scheduling should be fixed.(?) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20367
[Bug driver/44049] New: Empty dependencies left may cause invalid builds
Gcc lefts empty dependency files around if the preprocessor exits with an error. In some cases, when used in conjunction with gnu make, (and probably other tools), this can lead to inconsistent builds. The following shows a build succeeding where it should have failed, thus potentially resulting to an invalid executable (or whatever). Consider the following legitimate (GNU) makefile: --- Makefile - all: x.o x.d:# Generate dependency file gcc -E x.c -MP -MMD -MF x.d -MT x.o /dev/null x.o:# and compile gcc -c x.c include x.d # Include dep file, to have it generated and used end of Makefile - x.c - #include myheader.h end of x.c myheader.h (empty) --- end of myheader.h --- Now run the following commands: $ make Makefile:8: x.d: No such file or directory # OK, expected (could have used -include to avoid the warning) gcc -E x.c -MP -MMD -MF x.d -MT x.o /dev/null # Make builds x.d before including it gcc -c x.c # And compiles x.c without error $ rm myheader.h # just say the file was moved... $ rm x.d # someone suspected a problem with the dependencies $ make Makefile:8: x.d: No such file or directory # OK, expected as previously gcc -E x.c -MP -MMD -MF x.d -MT x.o /dev/null x.c:1:22: error: myheader.h: No such file or directory # OK, expected make: *** [x.d] Error 1 # OK, gcc returned non-zero $ ls -l x.d -rw-r--r-- 1 steve steve 0 9 mai 18:19 x.d# BAD: Strange 0-sized file !! $ make make: Nothing to be done for `all'. # ERROR: should have failed !!! (because make included the empty x.d, and considered the previously generated x.o as up-to-date) This can be illustrated by the following script, without using make, which I hope could easily be integrated as a unit test: --- test.sh - exit 0 if working as expected - #! /bin/sh # setup files: x.c includes iexist.h rm x.* # cleanup echo #include \myheader.h\ x.c rm -f myheader.h # gcc must exit non-zero gcc -E x.c -MP -MMD -MF x.d -MT x.o /dev/null if [ $? -eq 0 ]; then echo failed(1): gcc should have exited non-zero exit 1; fi # but x.d must not exist if test -f x.d; then ls -l x.d echo failed(2): x.d should not exist; exit 2 fi echo test passed; exit 0 # ok -- end of test.sh - Illustration: $ ./test.sh x.c:1:22: error: myheader.h: No such file or directory -rw-r--r-- 1 steve steve 0 9 mai 18:57 x.d failed(2): x.d should not exist == Additional notes This is related to following bugs: #9517 (fixed) states that if the compiler fails, the .d file should not be deleted if the .o file is kept. (In that case the error was triggered by the compiler, not the preprocessor) #35697 (enhancement) asking for .d files to be created atomically. In the current case, we are just considering the preprocessor, which lefts incoherent files around, even if it is not interrupted. Solving #35697 will solve that bug, but the discussion is still open. I will also consider filing a bug on Gnu make after investigating a bit more its strange behaviour. Sincerely -- Summary: Empty dependencies left may cause invalid builds Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: major Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eric dot estievenart at free dot fr GCC build triplet: 4.4.4 (Debian 4.4.4-1) GCC host triplet: i686 debian GNU/Linux GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44049
[Bug driver/44049] Empty dependencies left may cause invalid builds
--- Comment #1 from eric dot estievenart at free dot fr 2010-05-09 17:48 --- For those reading on, this can be worked-around by adding .DELETE_ON_ERROR: my dependencies in the makefile. I find it ugly, but it works... (but does not mean that gcc leaving corrupted files around is not a bug ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44049
[Bug fortran/40568] F2008: C_SIZEOF is in the wrong scope, rejected as initialization expression
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-09 18:11 --- Created an attachment (id=20612) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20612action=view) first steps to bring C_SIZEOF to the ISO_C_BINDING Attached patch is a start only. Comments: * symbol.c (build_formal_args): wrong parameter generated, probably needs a new gen_*_param function * on -std=f2003 there's only a linker error (undefined reference), no F2008-only warning * simplification/translation needs to be hijacked from sizeof -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568
[Bug c/44024] missed optimization
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-09 18:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44024
[Bug c/44024] missed optimization
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-09 18:17 --- Subject: Bug 44024 Author: rguenth Date: Sun May 9 18:17:33 2010 New Revision: 159205 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159205 Log: 2010-05-09 Richard Guenther rguent...@suse.de PR middle-end/44024 * fold-const.c (tree_single_nonzero_warnv_p): Properly handle FUNCTION_DECL. * gcc.dg/pr44024.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr44024.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44024
[Bug fortran/33341] array temporaries for array constructors (unnecessary stores)
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-09 18:31 ---
This improved at some point. We still create the temporary array, but the
optimizer got smarter:
$ gfortran-svn -O3 -fdump-tree-optimized -Warray-temporaries -c pr33341.f90
pr33341.f90:5.8:
foo = all((/ a, b, c /) /= d)
1
Warning: Creating array temporary at (1)
$ cat pr33341.f90.142t.optimized
;; Function foo (foo_)
foo (integer(kind=4) restrict a, integer(kind=4) restrict b,
integer(kind=4) restrict c, integer(kind=4) restrict d)
{
logical(kind=4) test.0;
integer(kind=4) D.1525;
integer(kind=4) D.1533;
integer(kind=4) D.1532;
integer(kind=4) D.1531;
bb 2:
D.1531_7 = *a_6(D);
D.1532_11 = *b_10(D);
D.1533_15 = *c_14(D);
D.1525_17 = *d_16(D);
if (D.1531_7 == D.1525_17)
goto bb 5;
else
goto bb 3;
bb 3:
if (D.1532_11 == D.1525_17)
goto bb 5;
else
goto bb 4;
bb 4:
test.0_32 = D.1533_15 != D.1525_17;
bb 5:
# test.0_1 = PHI 0(2), 0(3), test.0_32(4)
return test.0_1;
}
Should we keep the PR open to (eventually) eliminate the temporary or does this
count as fixed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
[Bug tree-optimization/44050] New: Wrong code is produced with -fipa-pta -fno-tree-pta
Tested revisions: r159202 - fail r159152 - fail Compiler output: $ gcc -O1 -fipa-cp -fipa-pta -fno-tree-pta testcase.c -DDEBUG ./a.out res = 0 Aborted Corrent coutput: $ gcc testcase.c -DDEBUG ./a.out res = 500500 -- Summary: Wrong code is produced with -fipa-pta -fno-tree-pta Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44050
[Bug tree-optimization/44050] Wrong code is produced with -fipa-pta -fno-tree-pta
--- Comment #1 from zsojka at seznam dot cz 2010-05-09 18:34 --- Created an attachment (id=20613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20613action=view) reduced testcase (from testsuite/gcc.dg/graphite/interchange-10.c) Command line: $ gcc -O1 -fipa-cp -fipa-pta -fno-tree-pta testcase.c ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44050
[Bug fortran/34159] Checkbound could warn about unallocated arrays
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-09 18:34 --- *** This bug has been marked as a duplicate of 20520 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34159
[Bug fortran/20520] allocatable arrays used uninitialized without a warning
--- Comment #16 from dfranke at gcc dot gnu dot org 2010-05-09 18:34 --- *** Bug 34159 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20520
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #6 from dirtyepic at gentoo dot org 2010-05-09 18:39 --- Created an attachment (id=20614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20614action=view) gcc45-PR44046-core2.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug tree-optimization/44050] Wrong code is produced with -fipa-pta -fno-tree-pta
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-09 18:41 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-09 18:41:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44050
[Bug fortran/32203] Support the vendor intrinsic function TIMEF
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-09 18:41 --- As demand was low and it was never supoorted by g77 - WONTFIX? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32203
[Bug rtl-optimization/44043] sorry, unimplemented: inlining failed in call to 'dst_output': optimizing for size and code size would grow
--- Comment #9 from justinmattock at gmail dot com 2010-05-09 18:42 --- Created an attachment (id=20615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20615action=view) dmesg of the latest HEAD and gcc 4.6.0 o.k. buddy!! compiled gcc(looked good), the compiled the kernel only issue I see is a warning about pao_tmp__ other than that nothing. looks good attached is dmesg with the latest kernel, and gcc 4.6.0 Thanks again..(I'll run her, and see if I run into any issues). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44043
[Bug fortran/32512] efficiency of RESHAPE and SPREAD
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-09 18:43 --- (In reply to comment #6) Was an experiment to see if an improvement to reshape could easily be implemented in the library. It fails completely, of course, because the source is freed! This does show that a flag in the descriptor to say that 'this' cannot be freed would be a boon. Thus marking as dependent on array-descriptor reform. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||37577 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512
[Bug tree-optimization/44050] Wrong code is produced with -fipa-pta -fno-tree-pta
--- Comment #3 from zsojka at seznam dot cz 2010-05-09 18:43 --- Created an attachment (id=20616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20616action=view) even shorter testcase $ gcc -O1 -fipa-cp -fipa-pta -fno-tree-pta pr44050-2.c ./a.out Aborted -- zsojka at seznam dot cz changed: What|Removed |Added Attachment #20613|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44050
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #7 from dirtyepic at gentoo dot org 2010-05-09 18:44 --- sorry, wrong bugzilla. ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
[Bug fortran/32515] F2003: Reject COMMON block names if local symbol already exists
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-09 18:58 --- With two minor modifications to the code (in main, call func(), not res(); in func1() call modFunc(), not mod), one gets: $ gfortran-svn -v gcc version 4.6.0 20100509 (experimental) (GCC) $ gfortran-svn -Wall -W -std=f95 pr32515.f90 pr32515.f90:24.16: common /bar/ r2 ! F95: Error also a global procedure 1 Error: Symbol 'bar' at (1) is already an external symbol that is not COMMON pr32515.f90:25.16: common /mod/ r3 ! F95: Error also a global procedure 1 Error: Symbol 'mod' at (1) is already an external symbol that is not COMMON pr32515.f90:23.16: common /res/ r1 ! F95: Error also a global procedure 1 Error: Fortran 2003: COMMON block 'res' at (1) that is also a function result $ gfortran-svn -Wall -W -std=f2003 pr32515.f90 pr32515.f90:24.16: common /bar/ r2 ! F95: Error also a global procedure 1 Error: Symbol 'bar' at (1) is already an external symbol that is not COMMON pr32515.f90:25.16: common /mod/ r3 ! F95: Error also a global procedure 1 Error: Symbol 'mod' at (1) is already an external symbol that is not COMMON I think, that's ok, Closing. Please reopen if I misread something. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32515
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #9 from alex dot pyattaev at gmail dot com 2010-05-09 19:07
---
(In reply to comment #7)
I have encountered the bug with switch construct. And the problem is not the
error message, but the fact that it is still compiling just fine this code:
switch (chan_prop.model_type)
{
case CM_STATIC:
return static_channel_model(src, ntransmitters, dst,
chan_prop);
case CM_FRISS:
return friss_channel_model(src, ntransmitters, dst,
chan_prop);
default:
return -1;
}
There should be some consistency at least! I'd like to see this fixed
properly.
The compiler should be perfectly predictable, and not like Sorry, i don't
like
this construct here... put a semicolon please.
I'd like this bug to be reopened and FIXED PROPERLY
gcc --version = (Gentoo 4.4.3-r2 p1.2) 4.4.3
A good example of seemingly normal code is following:
switch (whatever)
{
case 1:
int i=0;
i++;
printf(%d,i);
break;
}
It is technically perfectly legal to declare i as a local variable. However,
the compiler issues an error. And it is absolutely not clear why int i=0; is
not a statement. That is probably the only really annoying case. Moving
declaration of i into a code block solves the issue. I spent like 10 minutes
trying to find out why perfectly legal code would not compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug fortran/33584] FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal compiler error)
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-09 19:10 --- (In reply to comment #10) It looks like ~ 256 MB is needed to hold the result of the power operation being requested (2 ** 0x1fff). This is too much for this machine. Is there anything we can do here? If not, please close as WONTFIX. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
[Bug fortran/34145] single_char_string.f90 fails with -fdefault-integer-8
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-09 19:14 --- Still true for gcc version 4.6.0 20100509 (experimental) (GCC) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||36854 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34145
[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo
--- Comment #3 from dirtyepic at gentoo dot org 2010-05-09 19:26 --- Nothing changed. -march=native sets -mtune=core2 on my Penyrn as far back as 4.3, and you can see in PR44046 that Nehalem did the same before the patch. -- dirtyepic at gentoo dot org changed: What|Removed |Added CC||dirtyepic at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34501
[Bug fortran/34928] Extension: volatile common blocks
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-09 19:28 --- Since PR35037 we can have VOLATILE variables in COMMON blocks. But VOLATILE COMMON blocks are still unsupported (gcc version 4.6.0 20100509 (experimental) (GCC)). Demand is low, besides this PR, there's nothing in the ML. Even if supported by g77 - WONTFIX (maybe with a note in the docs)? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928
[Bug fortran/35003] spurious warning using -Wconversion, a do loop, and 8 byte integers
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-09 19:29 --- Patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00067.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35003
[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-05-09 19:38 --- With gcc-4.5.0 built as... Using built-in specs. COLLECT_GCC=gcc-4 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin10.3.0/4.5.0/lto-wrapper Target: x86_64-apple-darwin10.3.0 Configured with: ../gcc-4.5.0/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.5/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.5 Thread model: posix gcc version 4.5.0 (GCC) I get the following from... $ touch t.cc $ gcc -fverbose-asm t.cc -S more t.s # GNU C++ (GCC) version 4.5.0 (x86_64-apple-darwin10.3.0) # compiled by GNU C version 4.5.0, GMP version 4.3.1, MPFR version 2.4.2-p3, MPC version 0.8 # GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 # options passed: -D__DYNAMIC__ t.cc -fPIC -mmacosx-version-min=10.6.3 # -mtune=generic -fverbose-asm # options enabled: -fPIC -falign-loops -fargument-alias # -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcommon # -fdelete-null-pointer-checks -fearly-inlining # -feliminate-unused-debug-types -fexceptions -ffunction-cse -fgcse-lm # -fident -finline-functions-called-once -fira-share-save-slots # -fira-share-spill-slots -fivopts -fkeep-static-consts # -fleading-underscore -fmerge-debug-strings -fmove-loop-invariants # -fpeephole -freg-struct-return -fsched-critical-path-heuristic # -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock # -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec # -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column # -fsigned-zeros -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim # -ftree-forwprop -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize # -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc # -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version # -funit-at-a-time -funwind-tables -fvect-cost-model -fverbose-asm # -fzero-initialized-in-bss -gstrict-dwarf -m128bit-long-double -m64 # -m80387 -maccumulate-outgoing-args -malign-stringops -mfancy-math-387 # -mfp-ret-in-387 -mfused-madd -mieee-fp -mmmx -mno-sse4 -mpush-args # -mred-zone -msse -msse2 -msse3 which shows that -mtune was set to generic for that release. I'll double check with current gcc trunk but now suspect it has been changed to core2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34501
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-05-09 19:41 --- (In reply to comment #12) -Idir These affect interpretation of the INCLUDE directive (as well as of the #include directive of the cpp preprocessor). Also note that the general behavior of -I and INCLUDE is pretty much the same as of -I with #include in the cpp preprocessor, with regard to looking for header.gcc files and other such things. This path is also used to search for .mod files when previously compiled modules are required by a USE statement. Yes, I think that this text needs an update. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-09 20:02 ---
Experimental patch below gives:
$ gfortran-svn -Wall -W pr35779.f90
pr35779.f90:3.44:
integer, PARAMETER :: I2(10) = (/ (J1, J1=its_bad, 1, -1) /)
1
Error: Parameter 'its_bad' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
Some cleanup and regtesting is needed, though.
Index: array.c
===
--- array.c (revision 159195)
+++ array.c (working copy)
@@ -847,7 +847,7 @@ check_duplicate_iterator (gfc_constructo
static match match_array_cons_element (gfc_constructor_base *);
/* Match a list of array elements. */
-
+extern bool init_flag;
static match
match_array_list (gfc_constructor_base *result)
{
@@ -879,7 +879,7 @@ match_array_list (gfc_constructor_base *
for (n = 1;; n++)
{
- m = gfc_match_iterator (iter, 0);
+ m = gfc_match_iterator (iter, init_flag);
if (m == MATCH_YES)
break;
if (m == MATCH_ERROR)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2008-03-31 19:56:29 |2010-05-09 20:02:58
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug fortran/43072] unneeded temporary (s=s+f(a))
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-09 20:19 --- (In reply to comment #6) Same as 41113 - I'll decide what to do tonight - see you on #gfortran? PR41113 is closed as fixed - can this be closed as well? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43072
[Bug fortran/36915] Unneccessary array temporary for same_array_ptr = const * same_array_ptr
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-09 20:25 ---
This seemingly was fixed a while ago; -Warray-temporaries does not warn for
4.4.3, 4.5.1 nor current trunk.
Relevant section of the dump is:
while (1)
{
if (S.0 D.1515) goto L.1;
(*D.1516)[(S.0 + D.1520) * D.1523 + D.1517] = (*D.1512)[S.0 * D.1522
+ D.1513] * 1.973804473876953125e+1;
S.0 = S.0 + 1;
}
Closing as fixed.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36915
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-09 20:28 --- Still valid with: gcc version 4.6.0 20100509 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug fortran/36931] unneeded temporary for array intrinsic binop scalar
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-09 20:32 --- Both testcases, the original report as well as comment #2 still produce temporaries with gcc version 4.6.0 20100509 (experimental) (GCC). -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-07-25 13:04:23 |2010-05-09 20:32:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36931
[Bug c++/44045] initialization of array of shared_ptr's with initializer list causes compiler segfault
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-09 16:51:56 |2010-05-09 20:36:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44045
[Bug fortran/37039] Cray pointer with pointee DIMENSION statement after POINTER statement
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-09 20:39 --- This is, I think, a technical dupe of PR31560?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
[Bug c/10676] Using unnamed fields in initializers
--- Comment #15 from jsm28 at gcc dot gnu dot org 2010-05-09 20:39 --- Subject: Bug 10676 Author: jsm28 Date: Sun May 9 20:39:39 2010 New Revision: 159206 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159206 Log: PR c/10676 * c-typeck.c (lookup_field): Take a type directly. Update recursive calls. (build_component_ref): Update call to lookup_field. (set_init_label): Use lookup_field to find initialized field. Handle returned list of fields like a sequence of designators. testsuite: * gcc.dg/anon-struct-10.c: New test. Added: trunk/gcc/testsuite/gcc.dg/anon-struct-10.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug c/10676] Using unnamed fields in initializers
--- Comment #16 from jsm28 at gcc dot gnu dot org 2010-05-09 20:42 --- Fixed for 4.6. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.5.0 4.6.0 |4.5.0 Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #4 from kargl at gcc dot gnu dot org 2010-05-09 20:44 ---
(In reply to comment #3)
Experimental patch below gives:
$ gfortran-svn -Wall -W pr35779.f90
pr35779.f90:3.44:
integer, PARAMETER :: I2(10) = (/ (J1, J1=its_bad, 1, -1) /)
1
Error: Parameter 'its_bad' at (1) has not been declared or is a variable,
which
does not reduce to a constant expression
Some cleanup and regtesting is needed, though.
Index: array.c
===
--- array.c (revision 159195)
+++ array.c (working copy)
@@ -847,7 +847,7 @@ check_duplicate_iterator (gfc_constructo
static match match_array_cons_element (gfc_constructor_base *);
/* Match a list of array elements. */
-
+extern bool init_flag;
static match
match_array_list (gfc_constructor_base *result)
{
@@ -879,7 +879,7 @@ match_array_list (gfc_constructor_base *
for (n = 1;; n++)
{
- m = gfc_match_iterator (iter, 0);
+ m = gfc_match_iterator (iter, init_flag);
if (m == MATCH_YES)
break;
if (m == MATCH_ERROR)
I tried a similar patch, but it fell apart during testing.
Unfortunately, I can't remember what tripped up the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug tree-optimization/44050] Wrong code is produced with -fipa-pta -fno-tree-pta
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-09 20:49 --- Hm. The issue is we do not clone the ipa-pta flag in gimple_df but transfer ipa-pta info based on the setting of the flag in the src. This confuses us later. I have a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44050
[Bug fortran/38111] unneeded temporary
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-09 20:49 --- Enhancement only - and probably a dupe of PR33341?! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38111
[Bug fortran/38112] unneeded temporary
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2008-11-18 20:00:54 |2010-05-09 20:51:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38112
[Bug c/44051] New: FAIL: 22_locale/money_get/get/wchar_t/2.cc execution test
For Linux/ia32, I got
Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c
-S -o anon-struct-9.s(timeout = 300)
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:11:9:
error: duplicate member 'x'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:27:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:43:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:62:9:
error: duplicate member 'x'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:78:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:94:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:123:1:
error: expected identifier or '(' before numeric constant
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:123:1:
error: expected ';' before 'int'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:127:9:
error: duplicate member 'a123'
compiler exited with status 1
output is:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:11:9:
error: duplicate member 'x'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:27:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:43:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:62:9:
error: duplicate member 'x'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:78:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:94:9:
error: duplicate member 'b'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:123:1:
error: expected identifier or '(' before numeric constant
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:123:1:
error: expected ';' before 'int'
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:127:9:
error: duplicate member 'a123'
PASS: gcc.dg/anon-struct-9.c (test for errors, line 11)
PASS: gcc.dg/anon-struct-9.c (test for errors, line 27)
PASS: gcc.dg/anon-struct-9.c (test for errors, line 43)
PASS: gcc.dg/anon-struct-9.c (test for errors, line 62)
PASS: gcc.dg/anon-struct-9.c (test for errors, line 78)
PASS: gcc.dg/anon-struct-9.c (test for errors, line 94)
PASS: gcc.dg/anon-struct-9.c (test for errors, line 127)
FAIL: gcc.dg/anon-struct-9.c (test for excess errors)
Excess errors:
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:123:1:
error: expected identifier or '(' before numeric constant
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/anon-struct-9.c:123:1:
error: expected ';' before 'int'
--
Summary: FAIL: 22_locale/money_get/get/wchar_t/2.cc execution
test
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44051
[Bug fortran/35779] error pointer wrong in PARAMETER
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-09 20:57 --- (In reply to comment #4) I tried a similar patch, but it fell apart during testing. Unfortunately, I can't remember what tripped up the patch. Testing passed without issues here?! However, before submitting I'd like to add some cleanup; expr.c has gfc_init_expr and init_flag, both being used for the same purpose. Can be rolled into one patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
[Bug c/10676] Using unnamed fields in initializers
--- Comment #17 from davek at gcc dot gnu dot org 2010-05-09 21:00 --- Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug c/44051] FAIL: gcc.dg/anon-struct-9.c (test for excess errors)
--- Comment #1 from jsm28 at gcc dot gnu dot org 2010-05-09 21:01 --- Subject: Bug 44051 Author: jsm28 Date: Sun May 9 21:01:38 2010 New Revision: 159207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159207 Log: PR c/44051 * gcc.dg/anon-struct-9.c: Avoid generating identifier i386. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/anon-struct-9.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44051
[Bug testsuite/44051] FAIL: gcc.dg/anon-struct-9.c (test for excess errors)
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-05-09 21:04 --- Testcase fixed for 4.6. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |testsuite Known to work||4.6.0 Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44051
[Bug fortran/39280] Optimizing integer power
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-09 21:08 --- Situation still the same with gcc version 4.6.0 20100509 (experimental) (GCC). (In reply to comment #1) ... this asks for a POW_EXPR middle-end tree I guess. Or you can use builtins.c:expand_powi* do generate an expanded power series. Would that be enough of a gain to be worth the effort? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||36854 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39280
[Bug fortran/39280] Optimizing integer power
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-09 21:29 --- I am not sure to understand the requested optimization. Is it only for the special value j=-1 in j**i? Note that for this situation I hate to rely on the compiler and I use a flipper, i.e., I replace do i=1,10 n = (-1)**(i+1) call bar(n) end do with n = -1 do i=1,10 n = -n call bar(n) end do -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39280
[Bug fortran/42736] [4.3 Regression] Wrong-code with allocatable or pointer components in elemental functions
--- Comment #17 from dfranke at gcc dot gnu dot org 2010-05-09 21:51 --- Reopen and closing as fixed. References to this PR are confusing if it shows up as WONTFIX. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug fortran/42736] [4.3 Regression] Wrong-code with allocatable or pointer components in elemental functions
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-09 21:51 --- (In reply to comment #17) Reopen and closing as fixed. References to this PR are confusing if it shows up as WONTFIX. And closing again. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug c++/30195] Using declaration doesn't work in template.
--- Comment #4 from fabien dot chene at gmail dot com 2010-05-09 22:09 --- mine... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30195
[Bug c++/25994] Using declarations and base function overloading
--- Comment #5 from fabien dot chene at gmail dot com 2010-05-09 22:09 --- mine... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25994
[Bug fortran/42831] Unnecessary array temporary produced
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-09 22:13 --- Somewhat reduced testcase below. Note that the temporary depends on the POINTER attribute of 'table'. If POINTER and corresponding ALLOCATE are removed, there is no more temporary array. Also, if CENTIMETER is changed to simple REAL, but 'table' is still a POINTER, the temporary is omitted. module UnitValue_Module type :: UnitValue real :: Value = 1.0 end type interface operator(*) module procedure ProductReal_LV end interface operator(*) interface assignment(=) module procedure Assign_LV_Real end interface assignment(=) contains elemental function ProductReal_LV(Multiplier, Multiplicand) result(P_R_LV) real, intent(in):: Multiplier type(UnitValue), intent(in) :: Multiplicand type(UnitValue) :: P_R_LV P_R_LV%Value = Multiplier * Multiplicand%Value end function ProductReal_LV elemental subroutine Assign_LV_Real(LeftHandSide, RightHandSide) real, intent(inout) :: LeftHandSide type(UnitValue), intent(in) :: RightHandSide LeftHandSide = RightHandSide%Value end subroutine Assign_LV_Real end module UnitValue_Module program TestProgram use UnitValue_Module type :: TableForm real, dimension(:,:), allocatable :: RealData end type TableForm REAL :: CENTIMETER type(TableForm), pointer :: Table allocate(Table) allocate(Table%RealData(10,5)) CENTIMETER = 42 Table%RealData = 1 Table%RealData(:,1) = Table%RealData(:,1) * CENTIMETER end program TestProgram -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||36854 nThis|| Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-09 22:13:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42831
[Bug target/34501] The vector cost model does not seem suited for Intel Core2Duo
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-05-09 23:12 --- Okay, my mistake. It appears that the default builds for both i386-apple-darwin* and x86_64-apple-darwin* are both leaving -mtune set at generic. However it would be a nice aim for gcc 4.6.0 to have the processor specific costs outperform the generic tuning when invoked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34501
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #10 from dougsemler at gmail dot com 2010-05-09 23:25 ---
(In reply to comment #9)
A good example of seemingly normal code is following:
switch (whatever)
{
case 1:
int i=0;
i++;
printf(%d,i);
break;
}
It is technically perfectly legal to declare i as a local variable. However,
the compiler issues an error. And it is absolutely not clear why int i=0; is
not a statement. That is probably the only really annoying case. Moving
declaration of i into a code block solves the issue. I spent like 10 minutes
trying to find out why perfectly legal code would not compile.
Not to beat a dead horse here but...
Because that is *not* perfectly legal C code, and will not be valid C++ code if
you add another case label after it (jump over initialization)? A declaration
(int i) is not a statement.
That fails on both MSVC and gcc. In fact, MSVC will still barf even after
adding a semicolon after the label to make it a statement. (MSVC error is
error 2143: missing ';' before type)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug c/37231] GCC does not compile code with label statements that are followed by a declaration
--- Comment #11 from alex dot pyattaev at gmail dot com 2010-05-09 23:29
---
(In reply to comment #10)
(In reply to comment #9)
A good example of seemingly normal code is following:
switch (whatever)
{
case 1:
int i=0;
i++;
printf(%d,i);
break;
}
It is technically perfectly legal to declare i as a local variable. However,
the compiler issues an error. And it is absolutely not clear why int i=0;
is
not a statement. That is probably the only really annoying case. Moving
declaration of i into a code block solves the issue. I spent like 10 minutes
trying to find out why perfectly legal code would not compile.
Not to beat a dead horse here but...
Because that is *not* perfectly legal C code, and will not be valid C++ code
if
you add another case label after it (jump over initialization)? A declaration
(int i) is not a statement.
That fails on both MSVC and gcc. In fact, MSVC will still barf even after
adding a semicolon after the label to make it a statement. (MSVC error is
error 2143: missing ';' before type)
Ok, lets have pity for dead horse. Let it be as it is=)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37231
[Bug target/44046] Intel Core i5 M520 CPU detected as atom with -march=native
--- Comment #8 from hjl dot tools at gmail dot com 2010-05-10 03:52 --- Fixed. No need to change gcc 4.4. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.4.6 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44046
