--- 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
--- 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.
Th
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)
{
ca
--- 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=20611&action=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 -Wno-overl
--- 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=gcc&view=rev&rev=159200
Log:
2010-05-09 Richard Guenther
PR middle-end/44043
--- 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 some
--- 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=gcc&view=rev&rev=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=gcc&view=rev&rev=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
/root/bu
--- 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 la
--
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
h
--- 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 g
--- 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=gcc&view=rev&rev=159204
Log:
PR c/4784
* c-decl.c (detect_field_duplicates_hash
--- 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 ""
# 1 ""
# 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
--- 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.
an
--- 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 re
--- 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
--- 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://
--- 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|Rem
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
--- 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:
in the makefile.
I find it ugly, but it works...
(but does not mean that gcc leaving corrupted files around is not a bug ;-)
--
--- 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=20612&action=view)
first steps to bring C_SIZEOF to the ISO_C_BINDING
Attached patch is a start only. Comments:
* symbol.c (build
--- 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=gcc&view=rev&rev=159205
Log:
2010-05-09 Richard Guenther
PR middle-end/44024
--- 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=20613&action=view)
reduced testcase (from testsuite/gcc.dg/graphite/interchange-10.c)
Command line:
$ gcc -O1 -fipa-cp -fipa-pta -fno-tre
--- 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=20614&action=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
AssignedTo|unassigned
--- 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=20615&action=view)
dmesg of the latest HEAD and gcc 4.6.0
o.k. buddy!! compiled gcc(looked good), the compiled the kernel
only iss
--- 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=20616&action=view)
even shorter testcase
$ gcc -O1 -fipa-cp -fipa-pta -fno-tree-pta pr44050-2.c && ./a.out
Aborted
--
zsojka at sezna
--- 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
--- 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_typ
--- 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? I
--- 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 nothi
--- 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 wi
--- 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 not
--- 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:
W
--- 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=gcc&view=rev&rev=159206
Log:
PR c/10676
* c-typeck.c (lookup_field): Take a t
--- 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.
--
http://gcc.gnu.org/bugzilla/sho
--- 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 |2010-05-0
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
--- 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=gcc&view=rev&rev=159207
Log:
PR c/44051
* gcc.dg/anon-struct-9.c: Avoid genera
--- 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
Sta
--- 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 ge
--- 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|R
--- 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 chang
--- 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 pro
--- 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:
> > i
--- 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
A common technique is to benchmark a function by calling it many times i.e.
void foo(void);
int main(void)
{
}
--
Summary: "benchmark" function attribute.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Pri
--- Comment #1 from svfuerst at gmail dot com 2010-05-10 06:36 ---
A common technique is to benchmark a function by calling it many times i.e.
void foo(void)
{
/* foo's implementation */
}
int main(void)
{
int i;
for (i = 0; i < LARGE_NUM; i++) foo();
return 0;
}
The prob
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-10 06:55 ---
Re. comment #1:
(1) For this, there is the noinline attribute, as you already knew.
(2) See the noclone attribute
(3) See the regparm attribute
(4) You could use volatile and things like that, or put the unit in a se
100 matches
Mail list logo
