http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2011-10-07 16:50:10
UTC ---
Or another solution: should the fortran frontend perhaps put all these
variables not in MAINs scope (where they aren't referenced anyway), but
rather into file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
--- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-10-07 17:00:59
UTC ---
Hmm, I can't build go due to:
../../../gcc/libgo/runtime/sigqueue.goc:79:1: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50638
--- Comment #8 from Michael Matz matz at gcc dot gnu.org 2011-10-07 17:02:00
UTC ---
Okay, so it's really the emutlv_v variables. That should be fixed by the
patch at gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Attachment #23268|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
Bug #: 50419
Summary: Bad interaction between data-ref and disambiguation
with restrict pointers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
--- Comment #1 from Michael Matz matz at gcc dot gnu.org 2011-09-15 14:16:54
UTC ---
Created attachment 25293
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25293
(untested) patch
Potential fix for this. As yet untested.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2011-09-02 18:31:56
UTC ---
Author: matz
Date: Fri Sep 2 18:31:47 2011
New Revision: 178489
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178489
Log:
PR middle-end/50260
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50165
--- Comment #11 from Michael Matz matz at gcc dot gnu.org 2011-08-26 16:02:21
UTC ---
Author: matz
Date: Fri Aug 26 16:02:17 2011
New Revision: 178118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178118
Log:
PR lto/50165
* lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47653
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50037
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49194
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49016
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851
--- Comment #9 from Michael Matz matz at gcc dot gnu.org 2011-05-04 12:02:44
UTC ---
Also defining NULL as 0 creates problems when passing it to varargs
functions on LP64 platforms, not just for sentinels. As Andreas says, it's a
valid null
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48703
Summary: segfault in canonicalize_for_substitution
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48622
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48622
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2011-04-17 01:18:54
UTC ---
Author: matz
Date: Sun Apr 17 01:18:51 2011
New Revision: 172603
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172603
Log:
PR tree-optimization/48622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48645
--- Comment #4 from Michael Matz matz at gcc dot gnu.org 2011-04-17 01:18:54
UTC ---
Author: matz
Date: Sun Apr 17 01:18:51 2011
New Revision: 172603
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172603
Log:
PR tree-optimization/48622
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48622
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48645
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633
Summary: IRA causes ICE in compensate_edge
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48633
--- Comment #1 from Michael Matz matz at gcc dot gnu.org 2011-04-15 21:17:22
UTC ---
During reducing the testcase I had this hunk applied for ira-build.c:
Index: ira-build.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48623
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2011-04-08 11:37:59
UTC ---
I was asking what specifically doesn't work. I.e. why the changes to cfgbuild
were necessary. I'm not so dense to not understand that it doesn't work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
--- Comment #11 from Michael Matz matz at gcc dot gnu.org 2011-04-08 13:05:18
UTC ---
I know what's the problem. Your patch can't work. commit_one_edge_insertion
relies on edge splitting to work, which relies on being able to patch jump
insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
--- Comment #12 from Michael Matz matz at gcc dot gnu.org 2011-04-08 20:18:14
UTC ---
Author: matz
Date: Fri Apr 8 20:18:08 2011
New Revision: 172208
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=172208
Log:
PR middle-end/48389
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.5/4.6/4.7 Regression]|[4.5/4.6 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48389
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516
--- Comment #5 from Michael Matz matz at gcc dot gnu.org 2011-03-30 17:31:58
UTC ---
Author: matz
Date: Wed Mar 30 17:31:54 2011
New Revision: 171736
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171736
Log:
PR fortran/47516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274
Summary: C frontend emit invalid promotions
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274
--- Comment #2 from Michael Matz matz at gcc dot gnu.org 2011-03-24 14:51:08
UTC ---
It's x86_64-linux and indeed it does define that hook. Like 19 other targets.
This is quite inconvenient. The target should have a say in what
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #48 from Michael Matz matz at gcc dot gnu.org 2011-02-18 19:52:19
UTC ---
Author: matz
Date: Fri Feb 18 19:52:16 2011
New Revision: 170284
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170284
Log:
PR fortran/45586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47698
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #43 from Michael Matz matz at gcc dot gnu.org 2011-01-26 12:39:04
UTC ---
Yep. With my patch the saner looking
new_person-service.education.person.ss = *ss;
statement is generated. It's possible that class containers actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
--- Comment #7 from Michael Matz matz at gcc dot gnu.org 2011-01-25 12:58:33
UTC ---
FWIW removing the second recursive call doesn't regress the testsuite.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #40 from Michael Matz matz at gcc dot gnu.org 2011-01-25 15:02:40
UTC ---
The patch from comment #35 requires another change in unrelated code, which
I think actually fixes a pre-existing bug in type extension support:
Index: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #35 from Michael Matz matz at gcc dot gnu.org 2011-01-20 16:36:23
UTC ---
Created attachment 23047
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23047
possible patch
So, this is my current version. I'm creating a different type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #34 from Michael Matz matz at gcc dot gnu.org 2011-01-19 16:39:30
UTC ---
As I said in comment #27, gfc_component structs belonging to the type, they
are shared between target and non-target variants. Thus one cannot set
inherited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #32 from Michael Matz matz at gcc dot gnu.org 2011-01-18 13:56:01
UTC ---
Yes, but it's possible I was going up the wrong tree. My idea was to
build the no-restrict variants of types on demand, as necessary, basically
from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #29 from Michael Matz matz at gcc dot gnu.org 2011-01-17 13:52:20
UTC ---
It is, btw, a sign of bad Fortran language design
I don't see that. The frontend merely needs to emit correctly typed
expressions. And that the type of 'a%b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47265
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #12 from Michael Matz matz at gcc dot gnu.org 2010-11-25 17:02:19
UTC ---
The following needs to be taken into account when determining the
validity:
If this use is supposed to be valid (we can associate a pointer with
and entity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #13 from Michael Matz matz at gcc dot gnu.org 2010-11-25 17:07:10
UTC ---
no, your example here is different, and is not allowed. The original
testcase is fine.
so y=a%b%c%d%z
is allowed as soon as any of a, b, c, or d or z
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46077
--- Comment #6 from Michael Matz matz at gcc dot gnu.org 2010-11-19 20:56:33
UTC ---
Author: matz
Date: Fri Nov 19 20:56:27 2010
New Revision: 166958
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166958
Log:
PR tree-optimization/46077
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46077
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46098
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2010-10-18 15:58:26
UTC ---
One idea we had was that this is all frontends business anyway, and hence
it should (if it so desires) simply create volatile MEM_REFs for references
to half
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764
--- Comment #3 from Michael Matz matz at gcc dot gnu.org 2010-09-24 13:37:04
UTC ---
The problem is how the alignment for the read accesses is computed.
When we vectorize this data_ref:
ibuf[64 - i] (0 = i 64)
i.e.
ibuf[64 .. 1]
The first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45764
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||rakdver at gcc dot
301 - 357 of 357 matches
Mail list logo
