--- 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
--- 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
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)
--- 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
--- 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
--- 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)
{
--- 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
--- 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
--- 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
--
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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
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
--- 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
--- 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
--- 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
--- 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() };
}
--
--- 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.
--- 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
--- 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
--- 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
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- 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
--- 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.
--
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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)
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
--- 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;
--- 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
--- 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
--
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
--- 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
--- 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
--- 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
--- 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) /)
--- 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.
--
--- 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
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2008-11-18 20:00:54
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)
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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++;
--- 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;
--- 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
97 matches
Mail list logo
