http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49318
--- Comment #4 from irar at gcc dot gnu.org 2011-06-10 07:19:31 UTC ---
Author: irar
Date: Fri Jun 10 07:19:28 2011
New Revision: 174891
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174891
Log:
PR tree-optimization/49318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459
--- Comment #10 from Anitha Boyapati
2011-06-10 07:37:19 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > I agree. But this does not fully solve the problem either.
> > INCOMING_RETURN_ADDR_RTX is being defined in dwarf2out.c to
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344
--- Comment #8 from Dominique d'Humieres 2011-06-10
08:32:37 UTC ---
With the patch in comment #3 applied on top of revision 174846 I have been able
to update powerpc-apple-darwin9 (long update, but not a full bootstrap).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324
--- Comment #6 from Tobias Burnus 2011-06-10
08:35:02 UTC ---
(In reply to comment #5)
> The following should partially help
It does - but it also leads to two test suite failures:
gfortran.dg/alloc_comp_assign_5.f90 - failure around line 53.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
Jaak Ristioja changed:
What|Removed |Added
CC||jaak at ristioja dot ee
--- Comment #12 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
--- Comment #13 from Jaak Ristioja 2011-06-10
08:52:47 UTC ---
(In reply to comment #12)
> PPS: As noted by other, this bug is likely a duplicate to bug 39284 and bug
> 43868.
As noted by others, this bug is likely a duplicate to bug 39284 and b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43686
--- Comment #3 from Jaak Ristioja 2011-06-10 09:19:49
UTC ---
(In reply to comment #1)
> Duplicate of PR42621?
And probably a duplicate of bug 39284 also.
(In reply to comment #2)
> yes. It's definitely the same issue.
>
> The only additional
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49358
Richard Guenther changed:
What|Removed |Added
Keywords||missed-optimization, ra
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49357
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49355
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49354
Richard Guenther changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49350
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #7 from Eric Botcazou 2011-06-10
09:50:28 UTC ---
The alias.c machinery is clearly based on the fundamental assumption of pointer
arithmetics, i.e. that you aren't allowed to compute a difference unless both
pointers point to the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #8 from Richard Guenther 2011-06-10
09:59:06 UTC ---
(In reply to comment #7)
> The alias.c machinery is clearly based on the fundamental assumption of
> pointer
> arithmetics, i.e. that you aren't allowed to compute a difference unl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49355
--- Comment #2 from Jonathan Wakely 2011-06-10
10:00:00 UTC ---
it's only valid in C++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #2 from Richard Guenther 2011-06-10
10:00:58 UTC ---
Needs quite some more memory for me ... (doesn't fit in my 3GB box).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48660
--- Comment #3 from Mikael Pettersson 2011-06-10
10:04:52 UTC ---
Created attachment 24484
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24484
reduced test case
With the massively reduced test case and r154736 built as a cross to
armv5tel-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47599
--- Comment #8 from Bastien ROUCARIES
2011-06-10 10:14:06 UTC ---
Any news of this bug ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
Bastien ROUCARIES changed:
What|Removed |Added
CC||roucaries.bastien+bugs at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35827
Bastien ROUCARIES changed:
What|Removed |Added
CC||roucaries.bastien+bugs at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #3 from Jonathan Wakely 2011-06-10
10:39:58 UTC ---
"you're gonna need a bigger boat"
compiles ok on a 64-bit box, physical memory usage nears 4GB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #9 from Eric Botcazou 2011-06-10
10:55:53 UTC ---
> Creating that pointer is perfectly valid - you are allowed to cast a
> pointer to an uintptr_t and back, which is what the code does (in some
> obfuscated way of course).
No disagre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
Summary: [4.7 Regression] Huge 470.lbm regression
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #10 from Richard Guenther 2011-06-10
11:13:53 UTC ---
(In reply to comment #9)
> > Creating that pointer is perfectly valid - you are allowed to cast a
> > pointer to an uintptr_t and back, which is what the code does (in some
> > obf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
--- Comment #1 from William J. Schmidt 2011-06-10
11:23:16 UTC ---
OK, I'll clean this up.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49343
--- Comment #3 from Martin Jambor 2011-06-10
11:23:32 UTC ---
Apparently build_ref_for_model has to calculate offsets of
COMPONENT_REFs with component_ref_field_offset just like
get_ref_base_and_extent does in order to be able to make sense of
"p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
--- Comment #2 from rguenther at suse dot de
2011-06-10 11:31:07 UTC ---
On Fri, 10 Jun 2011, wschmidt at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
>
> --- Comment #1 from William J. Schmidt
> 2011-06-10 11:23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362
Summary: Arm Neon intrinsic types not correctly interpreted by
compiler.
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49362
--- Comment #1 from mark.pupilli at dyson dot com 2011-06-10 11:38:40 UTC ---
There is a typo -
'treats uint32_t as a single register and not an array of 4 x uint32_t'
should read:
'treats uint32x4_t as a single register and not an array of 4 x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
--- Comment #3 from William J. Schmidt 2011-06-10
11:41:15 UTC ---
OK, I won't clean this up. ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
--- Comment #3 from Jakub Jelinek 2011-06-10
11:44:03 UTC ---
Created attachment 24486
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24486
gcc47-pr49352.patch
Rough patch I've been playing with. There is no point testing gimple_code
of us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
Summary: [feature request] multiple target attribute (and
runtime dispatching based on cpuid)
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49349
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49361
--- Comment #4 from Richard Guenther 2011-06-10
12:19:32 UTC ---
Author: rguenth
Date: Fri Jun 10 12:19:30 2011
New Revision: 174903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174903
Log:
2011-06-10 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344
--- Comment #10 from Richard Guenther 2011-06-10
12:18:59 UTC ---
Author: rguenth
Date: Fri Jun 10 12:18:55 2011
New Revision: 174902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174902
Log:
2011-06-10 Richard Guenther
PR bootst
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
Ira Rosen changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #4 from Ir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49344
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324
--- Comment #7 from Tobias Burnus 2011-06-10
12:45:13 UTC ---
Submitted patch, which fixes - except of RESHAPE - the issue of comment 0 and
comment 3:
http://gcc.gnu.org/ml/fortran/2011-06/msg00095.html
TODO: See comment 6: Namely, for realloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49322
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
Jakub Jelinek changed:
What|Removed |Added
Attachment #24486|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
--- Comment #6 from Jakub Jelinek 2011-06-10
13:08:13 UTC ---
Actually, should vect_is_slp_reduction be called at all if check_reduction
is false? I think without check_reduction e.g. nothing ensures that code is
commutative and associative...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49352
--- Comment #7 from Ira Rosen 2011-06-10 13:30:52 UTC
---
(In reply to comment #6)
> Actually, should vect_is_slp_reduction be called at all if check_reduction
> is false? I think without check_reduction e.g. nothing ensures that code is
> commu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #4 from Mike Jarvis 2011-06-10 14:02:45
UTC ---
That's a bit odd. The final function in the .ii file consists of two function
calls. If I delete either one of these, the compile succeeds and only uses
about 1100M (RSIZE in top).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #5 from Jonathan Wakely 2011-06-10
14:06:19 UTC ---
a single 32-bit process won't be able to use that much
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364
Summary: [4.7 regressions] Empty .debug_abbrev sections confuse
SGI nm
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364
--- Comment #1 from Rainer Orth 2011-06-10 14:14:40 UTC
---
Created attachment 24488
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24488
gcc 4.6.0 assembler output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364
--- Comment #2 from Rainer Orth 2011-06-10 14:15:12 UTC
---
Created attachment 24489
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24489
gcc 4.7.0 assembler output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49364
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365
Summary: 436.cactusADM performance regression
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365
Richard Guenther changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org
Known to f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365
H.J. Lu changed:
What|Removed |Added
CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302
--- Comment #11 from William J. Schmidt
2011-06-10 15:28:52 UTC ---
Author: wschmidt
Date: Fri Jun 10 15:28:46 2011
New Revision: 174912
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174912
Log:
2011-06-10 Bill Schmidt
PR lto/493
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302
--- Comment #12 from William J. Schmidt
2011-06-10 15:33:53 UTC ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365
--- Comment #3 from Richard Guenther 2011-06-10
15:36:49 UTC ---
I'm trying to get my hands on it. Most code differences betweeen good and
bad rev. appear in loop array prefetching. Before aprefetch dumps differ only
for datestamp.c, PUGH/Setup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
Summary: pointer-to-member-function not given value in
DW_TAG_template_value_param
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41736
--- Comment #9 from Tom Tromey 2011-06-10 16:09:38
UTC ---
See PR 49366 as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #33 from Jerry DeLisle 2011-06-10
16:16:19 UTC ---
The last test case I am working is fmt_g0_6.f08.
The apparent failing case is:
print "(rc,g15.2)", 0.995000_8
Which is resulting in 0.99 and we expect it to be 1.0.
However
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #34 from Jerry DeLisle 2011-06-10
16:22:20 UTC ---
Additional note: The standard states:
"Let N be the magnitude of the internal value"
The internal value is to be used to determine the conversion to F formatting. I
think this adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48459
--- Comment #11 from Jason Merrill 2011-06-10
16:24:12 UTC ---
(In reply to comment #10)
> I don't think initial_return_save() is called now. It passes the compilation
> there but gets struck in other places. I think it is because
> INCOMING_RET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #35 from Thomas Henlich
2011-06-10 16:56:02 UTC ---
(In reply to comment #33)
> The last test case I am working is fmt_g0_6.f08.
>
> The apparent failing case is:
>
> print "(rc,g15.2)", 0.995000_8
>
> Which is resulting in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #36 from Thomas Henlich
2011-06-10 17:01:34 UTC ---
(In reply to comment #34)
> Additional note: The standard states:
>
> "Let N be the magnitude of the internal value"
>
> The internal value is to be used to determine the conversi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49367
Summary: missed optimization with __restrict field
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: trivial
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39415
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906
--- Comment #37 from Jerry DeLisle 2011-06-10
17:29:54 UTC ---
Updated patch posted for approval:
http://gcc.gnu.org/ml/fortran/2011-06/msg00097.html
Thomas, thanks for working the Standard issues and your testing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39684
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
--- Comment #3 from Martin Sebor 2011-06-10 17:44:47
UTC ---
Here's another test case, one that does involve slicing and where a consistent
but differently phrased warning would, IMO, be useful. Perhaps something like:
warning: slicing high orde
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49368
Summary: __builtin_constant_p is unable to determine if a union
is constant
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49347
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Summa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348
--- Comment #3 from Dodji Seketeli 2011-06-10
18:47:46 UTC ---
Candidate patch posted to
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00873.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
Dodji Seketeli changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369
Summary: typeof() strips const from member when used in const
method
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369
--- Comment #1 from Jonathan Wakely 2011-06-10
19:22:43 UTC ---
can you use typeof(this->B::member) instead?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769
--- Comment #2 from paolo at gcc dot gnu.org
2011-06-10 19:31:03 UTC ---
Author: paolo
Date: Fri Jun 10 19:31:00 2011
New Revision: 174927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174927
Log:
/cp
2011-06-10 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088
Georg-Johann Lay changed:
What|Removed |Added
Keywords||missed-optimization
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369
--- Comment #2 from shawn.bohrer at gmail dot com 2011-06-10 20:20:11 UTC ---
(In reply to comment #1)
> can you use typeof(this->B::member) instead?
Yes this works for my application, thanks for the suggestion. Surely this is
still a bug though
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26882
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
Known to f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49370
Summary: flags implemented in the specs file but undocumented
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49107
--- Comment #20 from Marc Glisse 2011-06-10
20:39:59 UTC ---
The patch fixes the example (thanks), but I still have trouble with the
following (and I also get a different type of failure elsewhere that I'll
investigate later):
#include
templat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #7 from Thorsten Glaser 2011-06-10 20:54:58
UTC ---
OK, so the fix is that the System.Address type must be changed in GNAT
to be handled as pointer in the GCC middle-/back-end. Is any GCC/GNAT
developer please working on this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #6 from Mike Jarvis 2011-06-10 21:04:59
UTC ---
I figured out how to install a 64 bit version of g++ on my machine, and I also
booted up the machine with 6 and 4 held down to get the 64 bit kernel.
And this didn't help. I'm still
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #7 from Jonathan Wakely 2011-06-10
21:10:16 UTC ---
does 'ulimit -a' show any limit on memory size?
obviously it would be good if gcc didn't use so much memory, but I did verify
that given a sufficiently beefy machine (64-bit, 24GB R
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #8 from Mike Jarvis 2011-06-10 21:26:59
UTC ---
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
--- Comment #9 from Mike Jarvis 2011-06-10 21:47:37
UTC ---
That worked. So I guess g++ is exceeding the stack limit and crashing, not the
heap memory.
$ ulimit -aH
core file size (blocks, -c) 0
data seg size (kbytes, -d) unl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49369
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
--- Comment #2 from vincenzo Innocente
2011-06-11 05:58:46 UTC ---
These new developments sound interesting. Hope somebody is working on it and
will publish a testable version soon.
On the other hand I was thinking more of exploiting auto-vectori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49351
Mike Jarvis changed:
What|Removed |Added
Severity|normal |minor
--- Comment #10 from Mike Jarvis 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363
davidxl changed:
What|Removed |Added
CC||tmsriram at google dot com
--- Comment #3 from
97 matches
Mail list logo