http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #55 from Michael Matz 2012-05-29 13:08:52
UTC ---
FWIW the node->callees list in yukawa_gn_full has 25076 entries.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Bug #: 53646
Summary: Surprising effects of cxx11 vs cxx98 ABI compatibility
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #5 from Michael Matz 2012-06-12 15:36:01
UTC ---
(In reply to comment #2)
> N.B. std::pair is not a POD in c++98 or c++11, so I don't know what libstdc++
> could have done to cause the FE to change how it returns a std::pair.
I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #6 from Michael Matz 2012-06-12 15:41:49
UTC ---
FWIW, it's finish_struct_bits setting TREE_ADDRESSABLE, because
type_has_nontrivial_copy_init returns true for pair with that ctor.
I think this indeed makes pair non-POD.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #10 from Michael Matz 2012-06-12 16:02:28
UTC ---
Yep, defaulting that ctor changes the ABI back to register passing.
If we could change that in libstdc++, all the better, but I still think the
issue is larger than just this specific
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #15 from Michael Matz 2012-06-13 12:07:38
UTC ---
I think so, yes. I initially really reported this as general c++ problem,
with the testcase of course being about a concrete instance of the problem
but not meaning to specifically co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #58 from Michael Matz 2012-06-15 14:56:33
UTC ---
Author: matz
Date: Fri Jun 15 14:56:26 2012
New Revision: 188667
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188667
Log:
PR middle-end/38474
* cfgexpand.c (add_alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #59 from Michael Matz 2012-06-15 15:12:59
UTC ---
There should be no compile performance problems in expand anymore.
The alias stmt walker as used from IPA remains a problem, though.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705
--- Comment #2 from Michael Matz 2012-06-17 15:36:19
UTC ---
Or alternatively cselib doesn't respect one invariant in constructing the
locations of its VALUEs. As seen above it constructs two values for the same
memory area, one referring to sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Michael Matz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Michael Matz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688
--- Comment #4 from Michael Matz 2012-06-21 12:18:31
UTC ---
Author: matz
Date: Thu Jun 21 12:18:23 2012
New Revision: 188852
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188852
Log:
PR middle-end/53688
* builtins.c (get_memory_
||matz at gcc dot gnu.org
Resolution||FIXED
--- Comment #5 from Michael Matz 2012-06-21 12:52:18
UTC ---
Fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #18 from Michael Matz 2012-06-21 14:36:29
UTC ---
Just today I had to debug another crash in our package management code.
This time a c++98 library picked up a std::list operator= from a c++11
library resulting in a crash. See
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #20 from Michael Matz 2012-06-21 15:25:59
UTC ---
As I stumbled over this problem complex recently already I had a hunch that it
might again be a 11/98 mixture. Having the symbols would have made that a
certainty. But it wouldn't ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
--- Comment #21 from Michael Matz 2012-06-21 15:32:07
UTC ---
(In reply to comment #20)
> certainty. But it wouldn't have helped me that much further. I still would
> have had to find out which functions were causing the wild write in order
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #62 from Michael Matz 2012-06-26 14:44:58
UTC ---
(In reply to comment #61)
> (In reply to comment #57)
>
> Anyway, on the machine where are debugged this, compilation at -O3
> took over 16 seconds which dropped to about 13.5 seconds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
--- Comment #2 from Michael Matz 2012-07-04 12:11:10
UTC ---
ISL generally has speed problems. For instance graphite/interchange-8.c
needs quite long to compile (well, several seconds), and _all_ of the runtime
is basically in malloc/free/copy a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
--- Comment #15 from Michael Matz 2012-08-03 14:43:14
UTC ---
Author: matz
Date: Fri Aug 3 14:43:09 2012
New Revision: 190126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190126
Log:
PR tree-optimization/54146
* cfgexpand.c (ad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
Michael Matz changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Michael Matz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #3 from Michael Matz 2012-03-01 12:56:40
UTC ---
Created attachment 26802
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26802
candidate fix
This fixes the problem by remembering the last seen call and checking if
it's before or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #4 from Michael Matz 2012-03-01 14:10:08
UTC ---
Bah, no. That won't generally work. In particular it might be calls that
don't necessarily dominate the "non-trapping" stmt that make it trapping
again:
*X = a;
if (cond)
free_ever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #5 from Michael Matz 2012-03-01 16:08:18
UTC ---
(In reply to comment #4)
> We can ignore back edges,
> hence the path between both accesses are acyclic, so we might still get away
> with a non-iterating algorithm.
Of course we canno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32120
--- Comment #10 from Michael Matz 2012-03-06 12:06:08
UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > I still have an unfinished patch to convert SCCVN to
> > http://dl.acm.org/citation.cfm?id=512536
> >
> > I'm happy to attach t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908
Bug #: 52908
Summary: xop-mul-1:f9 miscompiled on bulldozer (-mxop)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52910
Bug #: 52910
Summary: xop-mul-1:f13 miscompiled on bulldozer (-mxop)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52934
Bug #: 52934
Summary: enhancement: cshift0 should be inlined
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
--- Comment #6 from Michael Matz 2012-04-17 13:54:36
UTC ---
Author: matz
Date: Tue Apr 17 13:54:26 2012
New Revision: 186530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186530
Log:
PR tree-optimization/18437
* tree-vectorizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52977
--- Comment #6 from Michael Matz 2012-04-19 13:29:34
UTC ---
Author: matz
Date: Thu Apr 19 13:29:29 2012
New Revision: 186593
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186593
Log:
PR middle-end/52977
* tree.h (VECTOR_CST_NELT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
--- Comment #8 from Michael Matz 2011-11-17 16:04:04
UTC ---
Author: matz
Date: Thu Nov 17 16:03:56 2011
New Revision: 181443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181443
Log:
PR middle-end/50644
PR middle-end/50741
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #20 from Michael Matz 2011-11-17 16:04:04
UTC ---
Author: matz
Date: Thu Nov 17 16:03:56 2011
New Revision: 181443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181443
Log:
PR middle-end/50644
PR middle-end/50741
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #39
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
--- Comment #6 from Michael Matz 2011-11-21 13:28:08
UTC ---
Yes, the patch submission to the mailing list was incorrect and contained a
non-intended change. The patch as committed and ChangeLogged is correct.
Aldy: yes, I'm taking a peek.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
Michael Matz changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #7 fro
||matz at gcc dot gnu.org
Resolution||DUPLICATE
--- Comment #2 from Michael Matz 2011-11-21 16:25:34
UTC ---
Yes, definitely a dup (tried testcase with my potential patch).
*** This bug has been marked as a duplicate of bug 51125 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
--- Comment #9 from Michael Matz 2011-11-22 13:32:20
UTC ---
Author: matz
Date: Tue Nov 22 13:32:15 2011
New Revision: 181615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181615
Log:
PR c++/51264
* tree.c (iterative_hash_expr):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
--- Comment #10 from Michael Matz 2011-11-22 14:18:35
UTC ---
Fixed. Improving the situation with the clobbers should be tracked somewhere
else.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51264
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
--- Comment #8 from Michael Matz 2011-11-22 14:56:03
UTC ---
Author: matz
Date: Tue Nov 22 14:55:58 2011
New Revision: 181619
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181619
Log:
PR other/51125
* trans-mem.c (expand_block_tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275
--- Comment #4 from Michael Matz 2011-11-23 14:12:11
UTC ---
Andrew: yes, I considered something similar. To work really well it requires
some changes to the conflict generation code, though. Without the clobbers
all objects stay live on the ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50317
--- Comment #7 from Michael Matz 2011-11-28 13:46:45
UTC ---
(In reply to comment #6)
> Patch to drop ={v} {CLOBBER} stmts when the lhs lost TREE_ADDRESSABLE bit
> during execute_update_addresses_taken.
Actually it's not only the loss of TREE_AD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50317
--- Comment #10 from Michael Matz 2011-11-28 14:52:50
UTC ---
(In reply to comment #8)
> Perhaps we could drop the var ={v} {CLOBBER} stmts when renaming the var
> into SSA instead.
I think your current patch is better, no use in slowing down th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #51 from Michael Matz 2011-12-02 13:23:57
UTC ---
Nope, I don't have more than a couple hacks to try different approaches
as of right now. I should dust them off for next stage1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51275
--- Comment #7 from Michael Matz 2011-12-05 16:02:10
UTC ---
As said, this would still require ugly fiddling with exception edges.
Getting rid of some of the clobbers a posteriori seems cleaner.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51117
--- Comment #9 from Michael Matz 2011-12-13 13:59:42
UTC ---
Author: matz
Date: Tue Dec 13 13:59:35 2011
New Revision: 182283
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182283
Log:
PR tree-optimization/51117
* tree-eh.c (sink_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #18 from Michael Matz 2012-01-19 15:06:14
UTC ---
Author: matz
Date: Thu Jan 19 15:06:04 2012
New Revision: 183305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183305
Log:
PR tree-optimization/46590
* cfgexpand.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #19 from Michael Matz 2012-01-19 15:10:43
UTC ---
The var-expansion slowness is fixed again. The rest of course still applies.
||matz at gcc dot gnu.org
Resolution|FIXED |
--- Comment #6 from Michael Matz 2012-01-25 15:13:35
UTC ---
This testcase still segfaults in the same way. The problem this time is
in removing regions without landing pads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
--- Comment #8 from Michael Matz 2012-01-25 15:54:29
UTC ---
(In reply to comment #7)
> Well, that is a different testcase for a different bug, better would be not
> to reuse this one for that.
Hmm, perhaps. Too late now.
> Are you working on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
--- Comment #9 from Michael Matz 2012-01-26 13:25:06
UTC ---
Author: matz
Date: Thu Jan 26 13:24:58 2012
New Revision: 183559
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183559
Log:
PR tree-optimization/48794
* tree-eh.c (remov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48794
Michael Matz changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #20 from Michael Matz 2012-01-26 15:50:43
UTC ---
Author: matz
Date: Thu Jan 26 15:50:33 2012
New Revision: 183566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183566
Log:
PR tree-optimization/46590
* cfgexpand.c: Re
||2012-01-27
CC||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Michael Matz 2012-01-27 15:28:18
UTC ---
Will be fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
--- Comment #3 from Michael Matz ---
I don't see anything to improve either (as far as unroll-and-jam is concerned).
It's quite possible that cunrolli is harming more than helping in this case,
but with it disabled it seems the code is as it shou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
at gcc dot gnu.org |matz at gcc dot gnu.org
--- Comment #2 from Michael Matz ---
Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #7 from Michael Matz ---
Created attachment 46675
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46675&action=edit
potential patch
Actually I was barking up the wrong tree. It's not as easy as the CFG
manipulation for loop fus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91240
--- Comment #3 from Michael Matz ---
Also fixed by the patch at PR90796.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #3 from Michael Matz ---
(In reply to Antony Polukhin from comment #2)
> (In reply to Michael Matz from comment #1)
> Valgrind complains are distracting. GDB entering the destructor is
> missleading. Is there a simple way to change th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #9 from Michael Matz ---
(In reply to rguent...@suse.de from comment #8)
> >The fun thing is, there's a difference between these two loop nests:
> >
> > for (i) for (j) a[i][0] = f(a[i+1][0]);
> > for (i) for (j) b[i][j] = f(a[i+1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #11 from Michael Matz ---
(In reply to rguent...@suse.de from comment #10)
> >It's the only affine functions that don't progress with each iteration.
> > I
> >think, at least :)
>
> Hm. At least we analyze wrapping ones, but I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #7 from Michael Matz ---
(In reply to Antony Polukhin from comment #6)
> (In reply to Michael Matz from comment #3)
> > I don't really see any, no good idea here :-/
>
> How about moving all the optimizations based on reading uniniti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91898
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91898
--- Comment #3 from Michael Matz ---
For purposes of discussion, let's make a full example:
% cat ex.c
int get(int);
int foo (int a, int *ary)
{
//void *labelsy[] = {&&lab1, &&lab2, &&lab3, &&lab_end};
//int ary[] = {0, 1, 2, 3};
int i = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Michael Matz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |matz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
--- Comment #7 from Michael Matz ---
(In reply to Jakub Jelinek from comment #6)
> Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
> code is called before that happens.
Yes, sure. That still doesn't necessarily mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #2 from Michael Matz ---
I think we should say something about the addresses of stack slots individual
overaligned arguments as well (i.e. that the slot itself will also be aligned
accordingly), not just for the overall effect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #7 from Michael Matz ---
What about this variant of the second part?
diff --git a/x86-64-ABI/low-level-sys-info.tex
b/x86-64-ABI/low-level-sys-info.tex
index 66270b9..93b5e95 100644
--- a/x86-64-ABI/low-level-sys-info.tex
+++ b/x86-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #10 from Michael Matz ---
Ah, I missed that. Yeah, I'd like to be co-owner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89545
--- Comment #12 from Michael Matz ---
(In reply to H.J. Lu from comment #11)
> (In reply to Michael Matz from comment #10)
> > Ah, I missed that. Yeah, I'd like to be co-owner.
>
> Please send me your gitlab account name.
Err, right, that prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #9 from Michael Matz ---
(In reply to Richard Biener from comment #8)
>
> I'm out of ideas suitable for GCC 9 (besides reverting the patch, reverting
> to bogus state).
Either that or some hack (e.g. artificially avoiding vectorizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #7 from Michael Matz ---
No, this is not a problem in the stack slot sharing algorithm, but rather in
the input. As presented to expand, and only showing the important parts,
and reordering some BBs to make the flow more obvious:
;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #12 from Michael Matz ---
(In reply to Jakub Jelinek from comment #11)
> before that region. If we can say for:
> for (...)
> {
> unsigned char v[10];
> unsigned char *p = foo (v);
> *p = 1;
> unsigned c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #5 from Michael Matz ---
FWIW, the reduced testcase from comment #3 is wrong. Even with -O0 or with gcc
4.3 or 6 I get:
b:48
Aborted (core dumped)
But I can reproduce the problem with the original testcase.
at gcc dot gnu.org |matz at gcc dot gnu.org
--- Comment #6 from Michael Matz ---
I think I know what's going on. Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86973
--- Comment #1 from Michael Matz ---
I can reproduce the same error without any va-args:
% cat bug.i
extern void foo(void *);
__attribute__((sysv_abi))
void a(__attribute__((__vector_size__(8 * sizeof(double double b){
foo(0);
}
% ./cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86973
--- Comment #3 from Michael Matz ---
A testcase that doesn't need -mabi cmdline args:
extern __attribute__((ms_abi)) void foo(void);
__attribute__((sysv_abi))
void a(__attribute__((__vector_size__(8 * sizeof(double double b){
foo();
}
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86973
--- Comment #4 from Michael Matz ---
FWIW, the testcase is broken since it can be compiled, namely since
the two attributes ms_abi and sysv_abi are accepted, which is r137525 from
2008. Only broken with -mno-accumulate-outgoing-args of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87074
--- Comment #5 from Michael Matz ---
Author: matz
Date: Sat Sep 1 17:22:05 2018
New Revision: 264029
URL: https://gcc.gnu.org/viewcvs?rev=264029&root=gcc&view=rev
Log:
Fix PR87074
PR tree-optimization/87074
* gimple-loop-jam.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87074
--- Comment #6 from Michael Matz ---
Author: matz
Date: Sat Sep 1 17:33:45 2018
New Revision: 264030
URL: https://gcc.gnu.org/viewcvs?rev=264030&root=gcc&view=rev
Log:
Fix PR87074
Backport from mainline
PR tree-optimization/870
|RESOLVED
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |matz at gcc dot gnu.org
--- Comment #7 from Michael Matz ---
Fixed in trunk and gcc-8-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239
--- Comment #8 from Michael Matz ---
(In reply to Richard Biener from comment #7)
> While hmmer is now split the testcase in this bug isn't. We do find some
> split points but appearantly never split the loop.
This is not a case for normal loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #3 from Michael Matz ---
(In reply to Jakub Jelinek from comment #2)
> I'd say the right thing is to keep libieee.a around, even if it will be an
> empty ar archive.
Agreed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #9 from Michael Matz ---
(In reply to Carlos O'Donell from comment #8)
> > It matters from the users' point of view. I think it's better to give them
> > a build error when they use unsupported functionality, rather than giving
> > t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
--- Comment #4 from Michael Matz ---
Author: matz
Date: Wed Nov 14 15:43:54 2018
New Revision: 266148
URL: https://gcc.gnu.org/viewcvs?rev=266148&root=gcc&view=rev
Log:
Fix PR middle-end/86575
PR middle-end/86575
* gimplify.c (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
Michael Matz changed:
What|Removed |Added
Summary|[7/8/9 Regression] |[7/8 Regression]
|-Wimp
101 - 200 of 382 matches
Mail list logo
