https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #16 from Michael Matz ---
(In reply to Kewen Lin from comment #15)
> I agree, thanks for the comments! btw, I'm not fighting for the current
> implementation, just want to know more details why users are unable to make
> use of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #14 from Michael Matz ---
(In reply to Kewen Lin from comment #13)
> (In reply to Giuliano Belinassi from comment #12)
> > With your patch we have:
> >
> > > .LPFE0:
> > > ...
> > Which seems what is expected.
>
> Hi Giuliano,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #31 from Michael Matz ---
(In reply to H.J. Lu from comment #30)
> (In reply to Michael Matz from comment #29)
> > It not only can call malloc. As the backtrace of H.J. shows, it quite
> > clearly _does_ so :-)
>
> ld.so can only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113874
--- Comment #29 from Michael Matz ---
It not only can call malloc. As the backtrace of H.J. shows, it quite clearly
_does_ so :-)
That's why there is talk earlier in this report about potentially not using
malloc as one-time allocator for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #3 from Michael Matz ---
(In reply to Kewen Lin from comment #1)
>
> As Segher's review comments in [2], to support "before NOPs" before global
> entry and "after NOPs" after global entry,
Just to be perfectly clear here: the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113372
--- Comment #16 from Michael Matz ---
A general remark: in principle I don't see problems with undoing a little CSE,
as proposed. I.e. for each SSA name use, see if it (trivially, or
conservatively
or optimistically) refers to an address of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #21 from Michael Matz ---
(In reply to Jan Hubicka from comment #20)
> >
> > Live patching (user-space) doesn't depend on any particular alignment of
> > functions, on x86-64 at least. (The plan for other architectures wouldn't
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #19 from Michael Matz ---
(In reply to Jan Hubicka from comment #18)
> Reading all the discussion again, I am leaning towards -falign-all-functions
> + documentation update explaining that -falign-functions/-falign-loops are
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #11 from Michael Matz ---
(In reply to Florian Weimer from comment #10)
> (In reply to Michael Matz from comment #9)
> > > > I don't see how that helps. Imagine a preserve_all function foo that
> > > > calls
> > > > printf. How
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #9 from Michael Matz ---
(In reply to Florian Weimer from comment #8)
> (In reply to Michael Matz from comment #7)
> > > > Does the clang implementation take into account the various problematic
> > > > cases that arise when calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #7 from Michael Matz ---
(In reply to Florian Weimer from comment #5)
> > It also makes argument registers be callee-saved, which is very
> > unconventional.
>
> Isn't this done for the this pointer in some C++ ABIs?
There are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #4 from Michael Matz ---
(In reply to Florian Weimer from comment #2)
> I tried to write up something for the x86-64 psABI:
>
> Document the ABI for __preserve_most__ function calls
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
--- Comment #3 from Michael Matz ---
Huh, since when does clang implement this? See also
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624004.html
where I asked for comments about a similar, but not same, mechanism. I came
from
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728
--- Comment #11 from Michael Matz ---
(In reply to Michael Matz from comment #9)
> Just for completeness: I agree with Andrew that the initial code example in
> comment #0 doesn't show any problem. The edge from asmgoto to l0 doesn't
> cross
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110728
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #10 from Michael Matz ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Michael Matz from comment #7)
> > (In reply to Jakub Jelinek from comment #5)
> > > https://eel.is/c++draft/cfloat.syn points to the C standard for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #8 from Michael Matz ---
(In reply to Michael Matz from comment #7)
> So, my interpretation is that unsuffixed "4.2" has to be the double constant
> 4.2 (in IEEE double aka 0x1.0cccdp+2), which is then, because of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #7 from Michael Matz ---
(In reply to Jakub Jelinek from comment #5)
> https://eel.is/c++draft/cfloat.syn points to the C standard for
> FLT_EVAL_METHOD
> (plus https://eel.is/c++draft/expr#pre-6 talks about excess precision too)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #3 from Michael Matz ---
(In reply to Jakub Jelinek from comment #2)
> Note, internally in standard excess precision, 4.2 seen by the lexer is
> actually
> EXCESS_PRECISION ,
Then _that_ is the problem. The literal "4.2" simply is
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Target Milestone: ---
This came from a discussion about a user wondering why g++ behaved different
between GCC 12 and GCC 13, regarding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106571
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106353
--- Comment #2 from Michael Matz ---
True, but in this case it could also be emitted in a better way by the fortran
frontend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192
--- Comment #3 from Michael Matz ---
(In reply to Michael Matz from comment #2)
> see why it should be. If GIMP_SIMD_LANE has properties that make this
> transformation invalid I would argue that those properties are correctly
"are _not_" I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106192
--- Comment #2 from Michael Matz ---
Unroll-and-jam simply unrolls the outer loop and merged all resulting
inner-loop bodies. In this situation we have (before unroll-and-jam):
outerloop(i_1) {
_12 = i_1 <= 59
innerloop(i_1, j by 1) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105169
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104721
--- Comment #2 from Michael Matz ---
Is there a testcase where you noticed this, or was it just reading code?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543
--- Comment #11 from Michael Matz ---
(In reply to Richard Biener from comment #5)
> in particular the comment in bb_prevents_fusion_p saying
>
> /* BB is duplicated by outer unrolling and then all N-1 first copies
> move into the body
|RESOLVED
CC||matz at gcc dot gnu.org
--- Comment #7 from Michael Matz ---
Actually, it _is_ fixed. This problem report is about version 2.26, which is
many
years old. Current versions don't have this problem, at the very least when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102067
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #8 from Michael Matz ---
The only thing the x86-64 psABI says about this case is "'Unnamed bit-fields'
types do not affect the alignment of a structure or union." .
(zero-width bit-fields are _always_ unnamed)
But the x86-64 psABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100394
--- Comment #4 from Michael Matz ---
That then still shows problems with the pure function and -O2, but with
standard
C++ this then works:
struct S {
int foo(int i) const { if (i) throw 42; return 0; }
};
int __attribute__((noinline))
||matz at gcc dot gnu.org
--- Comment #3 from Michael Matz ---
That's simply invalid C++. A rethrow (which is what a 'throw' without value
is)
can only be done from within a catch. You need to throw a value:
...
int __attribute__((pure,noinline)) foo () { if (x) throw 42; return y; }
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100077
--- Comment #2 from Michael Matz ---
Yeah, to solve this fully requires representing the parameter passing in a
better
way, one that can be (a) used on the gimple side (where the code is already
generated assuming the vec3a params go into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99896
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #22 from Michael Matz ---
Over the last days I came to a similar conclusion. Control dependence as
defined
with postdoms doesn't capture the number of invocations of an instruction, just
wether it's invoked at all. I.e. paths with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #19 from Michael Matz ---
(In reply to Michael Matz from comment #18)
> But there are other blocks control dependend on bb4, namely bb5 and bb9.
> To see this observe that bb9 doesn't pdom bb4, but there's a path from bb4 to
> bb9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #18 from Michael Matz ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > Created attachment 50248 [details]
> > dot of the CFG as CD-DCE sees it
>
> (gdb) p debug_dominance_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #17 from Michael Matz ---
(In reply to Richard Biener from comment #16)
> Of course since -ffinite-loops and the C++ standard require forward progress
> here and all testcases expect the loop to not terminate we're in the realm
> of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #7 from Michael Matz ---
(In reply to Richard Biener from comment #5)
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
>
> struct S { T a[N] };
>
> ?
No. structs, if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #2 from Michael Matz ---
The psABI doesn't say anything about such types, no. Maybe it could in some
additional info pages, but it's always a problem to codify behaviour
retroactively
in it, when conflicting implementations already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #11 from Michael Matz ---
(In reply to Jan Hubicka from comment #10)
> > We could also punt: when enable-link-mutex we could artificially up the job
> > number for make to account for the waiting link steps. I.e. when normally
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96794
--- Comment #9 from Michael Matz ---
We could also punt: when enable-link-mutex we could artificially up the job
number for make to account for the waiting link steps. I.e. when normally -jN
was given, the link step could be done under -j(N +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #11 from Michael Matz ---
(In reply to rguent...@suse.de from comment #9)
> How do we represent sNaNs with -fnon-call-exceptions? That is,
I think we're currently simply buggy at various stages as soon as sNaNs are
involved _and_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #10 from Michael Matz ---
(In reply to Andreas Schwab from comment #5)
> > Just note that _all_ floating point operations, not just divisions, can trap
> > (without fast-math). You never know if the user enabled stops for any of
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #3 from Michael Matz ---
(In reply to Richard Biener from comment #2)
> which means for non-memory gimple_could_trap_p (stmt) - sth you can
> easily check I guess.
Just note that _all_ floating point operations, not just divisions,
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Target Milestone: ---
I believe gcc-10 miscompiles the following program when SVE and vectorization
are enabled. You need glibc to show
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522
--- Comment #3 from Michael Matz ---
See the llvm link of the respective patch. They specify that the outputs are
reliable only on the fallthrough (i.e. no goto taken) path (in particular the
outputs might or might not have been changed on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91626
--- Comment #7 from Michael Matz ---
I've added it verbatim from PR48622, which itself was an autoreduced testcase
for
an ICE, at the time preventing bootstrapping. I haven't verified if making the
testcase conforming C (i.e. provide a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #8 from Michael Matz ---
>From the GCC perspective, yes. From the standard-is-surprising perspective,
no, but that probably doesn't belong to the GCC bugzilla. So, yeah, can be
closed
for gcc 9 (theoretically it's still a bug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #18 from Michael Matz ---
(In reply to Alexander Monakov from comment #17)
> I think part of the problem is trying to make "deaths" explicit via CLOBBERs
> without making "births" also explicit in the IR.
Yes, that's basically the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93270
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92821
--- Comment #5 from Michael Matz ---
Yes, we (intentionally) haven't required any extensions to happen for arguments
or return values smaller than 64bit (e.g. we haven't even specified that
arguments <= 32bit would be zero-extended in the high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #6 from Michael Matz ---
(In reply to Jonathan Wakely from comment #5)
>
> Before choosing which conversion operator to use, the compiler considers the
> constructors of S, finding S(const S&) and S(S&&) as candidates. There is a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #4 from Michael Matz ---
Even though bugzilla isn't really for educating people, I'd still like to ask
why the two conversion sequences are deemed either incomparable or equal. In
S b { moveme(t) };
the return value of moveme()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #1 from Michael Matz ---
I _think_ a reduced program would be this:
-
template struct remove_ref { typedef _Tp type; };
template struct remove_ref<_Tp&> { typedef _Tp type; };
template struct
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matz at gcc dot gnu.org
Target Milestone: ---
A user of ours noted a difference in behaviour between gcc8 and gcc9 regarding
braced initializers. Take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #17 from Michael Matz ---
Author: matz
Date: Wed Nov 20 16:51:10 2019
New Revision: 278512
URL: https://gcc.gnu.org/viewcvs?rev=278512=gcc=rev
Log:
Fix PR90796
PR middle-end/90796
* gimple-loop-jam.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #16 from Michael Matz ---
(In reply to Jakub Jelinek from comment #14)
> Time to backport now?
Hmpf, I've actually done the regstrapping for gcc9 already but then forgot to
submit. Thanks for the reminder.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
Michael Matz changed:
What|Removed |Added
Summary|[8/9/10 Regression] GCC: O2 |[8/9 Regression] GCC: O2 vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #12 from Michael Matz ---
Author: matz
Date: Tue Oct 22 12:25:03 2019
New Revision: 277287
URL: https://gcc.gnu.org/viewcvs?rev=277287=gcc=rev
Log:
Fix PR middle-end/90796
PR middle-end/90796
* gimple-loop-jam.c
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[] = {&, &, &, &_end};
//int ary[] = {0, 1, 2, 3};
int i = 0;
int ret = 0;
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=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
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=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] =
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
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=91240
--- Comment #3 from Michael Matz ---
Also fixed by the patch at PR90796.
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=edit
potential patch
Actually I was barking up the wrong tree. It's not as easy as the CFG
manipulation for loop fusion
at gcc dot gnu.org |matz at gcc dot gnu.org
--- Comment #2 from Michael Matz ---
Mine.
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=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.
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
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=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
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
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 #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
+++
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
--- Comment #7 from Michael Matz ---
As I stated, it's only fixed in trunk, so it's still a regression in 7 and 8,
as marked in the summary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
Michael Matz changed:
What|Removed |Added
Summary|[7/8/9 Regression] |[7/8 Regression]
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=gcc=rev
Log:
Fix PR middle-end/86575
PR middle-end/86575
* gimplify.c
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
|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=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=gcc=rev
Log:
Fix PR87074
Backport from mainline
PR tree-optimization/87074
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=gcc=rev
Log:
Fix PR87074
PR tree-optimization/87074
* gimple-loop-jam.c
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=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();
}
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=85304
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 #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
> >
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
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84111
Michael Matz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 357 matches
Mail list logo
