||segher at gcc dot gnu.org
Resolution|--- |FIXED
Known to fail||7.4.0, 8.3.0, 9.2.0
--- Comment #3 from Segher Boessenkool ---
Fixed on trunk. This doesn't need a backport unless something that uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Thu Oct 17 19:52:55 2019
New Revision: 277132
URL: https://gcc.gnu.org/viewcvs?rev=277132=gcc=rev
Log:
Backport from trunk
2019-03-15 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Oct 17 19:51:01 2019
New Revision: 277131
URL: https://gcc.gnu.org/viewcvs?rev=277131=gcc=rev
Log:
Backport from trunk
2019-03-15 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #16 from Segher Boessenkool ---
Oh doh, I am blind, apparently :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #13 from Segher Boessenkool ---
I don't see a patch there? If you have one, please attach it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #11 from Segher Boessenkool ---
Well, it apparently has found new jump threading opportunities after
partition_blocks. Are such changes useful? Does it happen often?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92107
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Tue Oct 15 23:47:47 2019
New Revision: 277023
URL: https://gcc.gnu.org/viewcvs?rev=277023=gcc=rev
Log:
genattrtab: Parenthesize expressions correctly (PR92107)
As PR92107 shows,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #9 from Segher Boessenkool ---
(In reply to Ilya Leoshkevich from comment #7)
> Having eliminated bb 5, we cannot avoid making bb 6 cold, since this
> would violate CFG integrity: as far as I understand, it's important to
> maintain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
--- Comment #5 from Segher Boessenkool ---
A new attribute is not very enticing. First, it is yet another special-purpose
attribute, which can also be surprisingly hard to define what it should do.
Because it is a special attribute, the
||2019-10-14
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Segher Boessenkool ---
Does it need a new attribute at all?
If not, an optimisation like this is obviously beneficial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #8 from Segher Boessenkool ---
The current two jump passes we have after reload are there for a reason.
Some targets will be very unhappy if you delete them.
Like Jakub says, you need to avoid doing stuff with crossing edges in
many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92007
--- Comment #4 from Segher Boessenkool ---
Well it should at least be renamed then ;-)
But is that good anyway? We then do not have a jump pass after reload
(and before split2 and pro/epi, i.e. shrink-wrapping) any more.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #37 from Segher Boessenkool ---
-- If it is done in RTL it should really be done earlier, it doesn't get all
optimisations it should right now.
-- Unrolling small loops more aggressively (at -O2 even) perhaps needs to be
done at a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308
Segher Boessenkool changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #10 from Segher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #31 from Segher Boessenkool ---
Gimple passes know a lot about machine details, too.
Irrespective of if this is "low-level" or "high-level", it should be done
earlier than it is now. It should either be done right after expand, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #6 from Segher Boessenkool ---
Attempting shrink-wrapping optimization.
Block 2 needs the prologue.
(That's the entry block, already). And in fact it does need the prologue,
it has
movq%rdi, %rbx # 2 [c=4 l=3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #5 from Segher Boessenkool ---
Okay, I can reproduce it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #3 from Segher Boessenkool ---
So this works just fine with a compiler from a year ago.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91981
--- Comment #2 from Segher Boessenkool ---
I didn't have an x86 C++ compiler handy, so I tried on powerpc. This
isn't a big problem there, since we do separate shrink-wrapping by
default on powerpc; disabling that makes this pretty bad here,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
--- Comment #8 from Segher Boessenkool ---
(In reply to Lauri Kasanen from comment #7)
> Are you sure about the smaller ones? To me they should not care about 64-bit
> swaps,
"swappable" here means you can swap the low and high half on all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #26 from Segher Boessenkool ---
Yeah, and it probably should be a param (that different targets can default
differently, per CPU probably). On most Power CPUs all loops take a minimum
number of cycles per iteration (say, three), but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91905
--- Comment #5 from Segher Boessenkool ---
Does -mno-vsx make it work? How about -mcpu=power7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #24 from Segher Boessenkool ---
On some (many?) targets it would be good to unroll all loops with a small body
(not containing calls etc.) at -O2 already, some small number of times (2 or 4
maybe).
||2019-09-19
Host|powerpc64le-unknown-linux-g |
|nu |
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
Build|powerpc64le
||2019-09-19
Host|powerpc64le-unknown-linux-g |
|nu |
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
Build|powerpc64le
|segher at gcc dot
gnu.org
Ever confirmed|0 |1
Build|powerpc64le-unknown-linux-g |
|nu |
--- Comment #2 from Segher Boessenkool ---
Confirmed. Only happens on LE. I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #19 from Segher Boessenkool ---
> Anyway, fixing it properly likely requires quite some work.
Combine should not change any insns in place. It should create *new*
insns. It can always keep those in some temporary place, only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #17 from Segher Boessenkool ---
I'll do a patch to prohibit gen_reg_rtx inside combine, btw... Let's see
how far that goes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #12 from Segher Boessenkool ---
Thanks for testing!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #10 from Segher Boessenkool ---
The prologue is not necessarily inserted as the first bb, so it's not clear
to me that CA is never live there.
The code copying r11 to r0, and back, is removed by the usual optimisations
btw, in all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #9 from Segher Boessenkool ---
My patch do not clobber r11, that's the point of it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720
--- Comment #2 from Segher Boessenkool ---
Isn't this *exactly* what WORD_REGISTER_OPERATIONS says is okay to do?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #13 from Segher Boessenkool ---
1) Yes, you'll be better of without calling gen_reg_rtx, certainly.
2) I don't see how you can make the undo scheme support this, without
big cost and/or big restructuring.
If we can replace this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #11 from Segher Boessenkool ---
Oh lol, I finally wake up. It is called from the splitter. That isn't
really a valid thing to do.
We have some limited support for that since a while, but it seems this
cannot ever really work?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #10 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #9)
> So when was the array reallocated? combine does in general rely on all
> rtxen to stay in place, etc.
Ah pretty much directly from gen_reg_rtx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
--- Comment #9 from Segher Boessenkool ---
So when was the array reallocated? combine does in general rely on all
rtxen to stay in place, etc.
||segher at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #10 from Segher Boessenkool ---
The new testcases pr91656-[12].c fail on all BE systems as written (the
memmove copies the MSB, not the LSB as intended).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65640
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
Segher Boessenkool changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91275
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||segher at gcc dot gnu.org
Host|ppc64le |
--- Comment #2 from Segher Boessenkool ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #5 from Segher Boessenkool ---
(BTW, using addic here is wrong: addic clobbers CA, which may not be free).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Segher Boessenkool changed:
What|Removed |Added
Known to work||4.8.5
Known to fail|
|UNCONFIRMED |NEW
Last reconfirmed||2019-09-07
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Segher Boessenkool ---
Confirmed. Any target. Needs -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #24 from Segher Boessenkool ---
(clobber of a match_operand I mean, sigh).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91635
--- Comment #23 from Segher Boessenkool ---
If a splitter wants a new register during combine, it should do a match_scratch
for that. This is documented.
You do not normally get new registers during combine. combine cannot really
handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #17 from Segher Boessenkool ---
(In reply to Tamar Christina from comment #16)
> > Do you have a link to those problems? And no, please don't regress us for
> > no
> > reason at all, it's really easy to *not* regress this on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #15 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #13)
> These functions have to be expanded inline, unconditionally; there are no
> library functions they can reliably fall back on in general.
Ugh,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
--- Comment #14 from Segher Boessenkool ---
(In reply to Wilco from comment #12)
> > but we should really handle this with some non-signaling insns, not punt
> > it to libm to do.
>
> Well we should simply commit Tamar's patch again since it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
The -mlong-double-64 and -mlong-double-128 command line options aren't
documented.
The -Q --help=target output shows
-mlong-double-[64,128]127
which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 89794, which changed state.
Bug 89794 Summary: combine incorrectly forwards register value through auto-inc
operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #17 from Segher Boessenkool ---
Author: segher
Date: Sat Aug 31 19:01:52 2019
New Revision: 275245
URL: https://gcc.gnu.org/viewcvs?rev=275245=gcc=rev
Log:
rs6000: Fix darn-3.c for GCC 8 and GCC 7
Apparently I didn't properly test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #16 from Segher Boessenkool ---
Author: segher
Date: Sat Aug 31 18:58:04 2019
New Revision: 275244
URL: https://gcc.gnu.org/viewcvs?rev=275244=gcc=rev
Log:
rs6000: Fix darn-3.c for GCC 8 and GCC 7
Apparently I didn't properly test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:25:36 2019
New Revision: 275186
URL: https://gcc.gnu.org/viewcvs?rev=275186=gcc=rev
Log:
Backport from trunk
2019-08-23 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #12 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:23:55 2019
New Revision: 275185
URL: https://gcc.gnu.org/viewcvs?rev=275185=gcc=rev
Log:
Backport from trunk
2019-08-22 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #11 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:17:20 2019
New Revision: 275182
URL: https://gcc.gnu.org/viewcvs?rev=275182=gcc=rev
Log:
Backport from trunk
2019-08-23 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #10 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 14:15:39 2019
New Revision: 275181
URL: https://gcc.gnu.org/viewcvs?rev=275181=gcc=rev
Log:
Backport from trunk
2019-08-22 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 13:53:11 2019
New Revision: 275176
URL: https://gcc.gnu.org/viewcvs?rev=275176=gcc=rev
Log:
Backport from trunk
2019-08-23 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 30 13:51:26 2019
New Revision: 275175
URL: https://gcc.gnu.org/viewcvs?rev=275175=gcc=rev
Log:
Backport from trunk
2019-08-22 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Fri Aug 23 22:19:40 2019
New Revision: 274889
URL: https://gcc.gnu.org/viewcvs?rev=274889=gcc=rev
Log:
rs6000: New darn testcase (PR91481)
We used to implement darn with unspecs,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Thu Aug 22 19:36:21 2019
New Revision: 274835
URL: https://gcc.gnu.org/viewcvs?rev=274835=gcc=rev
Log:
rs6000: Use unspec_volatile for darn (PR91481)
Every call to darn should
||2019-08-21
CC||segher at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Segher Boessenkool ---
The various
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #6 from Segher Boessenkool ---
Maybe we should make "is this an ordered comparison" separate from the
actual comparison code.
That would make things quite a bit simpler as well. Maybe we can pull
that through to RTL, as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #4 from Segher Boessenkool ---
(In reply to Richard Biener from comment #1)
> where we end up with
>
>[local count: 1073741824]:
> if (a_3(D) < b_4(D))
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #3 from Segher Boessenkool ---
There are quite many different cases to test, and many *more* do not currently
generate the wanted code because it isn't optimised properly on gimple level,
and that makes it hard to test the RTL /
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Take this example:
===
#include
_Bool lt(double a, double b) { return isless(a, b); }
_Bool lo(double a, double b) { return a < b; }
_Bool ll(double a, doubl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684
--- Comment #10 from Segher Boessenkool ---
*** Bug 91331 has been marked as a duplicate of this bug. ***
||segher at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Segher Boessenkool ---
This is another instance of PR58684.
*** This bug has been marked as a duplicate of bug 58684 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88962
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
--- Comment #17 from Segher Boessenkool ---
Yup, those testcases work fine for powerpc, too; and the signed versions of
those
do as well. (I couldn't find vector-types.h; I did "#define VECTOR_SIZE 16").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
--- Comment #5 from Segher Boessenkool ---
It might work a lot better if it didn't have to load that all-ones vector
in a separate insn. Because it does, you need to do a 3->3 combination
(which we do not currently support) if you need to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Mon Jul 15 20:57:53 2019
New Revision: 273498
URL: https://gcc.gnu.org/viewcvs?rev=273498=gcc=rev
Log:
rs6000: Always output .machine
We now can always output .machine (if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #10 from Segher Boessenkool ---
And yes, that means a lot of work for whoever wants to make the warning
default (during GCC builds or otherwise).
The alternative is a lot of work for other people. That is not a good
alternative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #9 from Segher Boessenkool ---
Let me put it differently, then:
Such warnings should not be enabled by default before most it warns about
has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88497
--- Comment #12 from Segher Boessenkool ---
It still does some weird register moves (the xxlor and the fmr), but
those are totally different problems ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Sun Jul 14 08:24:38 2019
New Revision: 273475
URL: https://gcc.gnu.org/viewcvs?rev=273475=gcc=rev
Log:
rs6000: Shut up -Wformat-diag a little more
PR target/91148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #6 from Segher Boessenkool ---
Author: segher
Date: Sat Jul 13 15:57:21 2019
New Revision: 273468
URL: https://gcc.gnu.org/viewcvs?rev=273468=gcc=rev
Log:
rs6000: Shut up -Wformat-diag somewhat
We currently get lot of build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #5 from Segher Boessenkool ---
I have a patch removing "builtin function" where that is redundant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
--- Comment #8 from Segher Boessenkool ---
-mcall-* should change the calling convention, not anything else OS-related.
-mcall-aixdesc is the *default* for powerpc64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #4 from Segher Boessenkool ---
And I am quite serious about that last point: I have to redirect stderr
to file and search that with a text editor to find the errors, there are
a dozen screenfuls of useless warnings (about two screens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91148
--- Comment #3 from Segher Boessenkool ---
12593 |"internal error: builtin function %qs already processed",
That's a fatal_error; users will never see that, *no one* will ever see that.
14747 | error ("builtin function %qs is only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
--- Comment #4 from Segher Boessenkool ---
You still haven't said what the kernel uses it for, when, in what way.
It probably shouldn't. But, -mcall-* should not change whether __linux__
and friends are defined.
||2019-07-10
CC||segher at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
Confimed.
Testcase:
:|gcc -E -dM - -mcall-aixdesc|grep linux
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
In the new testcase pr88233.c, which is
typedef struct { double a[2]; } A;
A
foo (const A *a)
{
return *a;
}
we currently get as generated code for -m32
addi 10,4,4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233
--- Comment #4 from Segher Boessenkool ---
Author: segher
Date: Mon Jul 8 20:38:46 2019
New Revision: 273245
URL: https://gcc.gnu.org/viewcvs?rev=273245=gcc=rev
Log:
rs6000: Add testcase for PR88233
This testcase tests that with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88233
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Mon Jul 8 17:35:12 2019
New Revision: 273240
URL: https://gcc.gnu.org/viewcvs?rev=273240=gcc=rev
Log:
subreg: Add -fsplit-wide-types-early (PR88233)
Currently the second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
--- Comment #3 from Segher Boessenkool ---
Before combine there were also
(insn 8 7 9 3 (set (reg/v:DI 95 [ c ])
(reg:DI 92 [ b$h ])) "91102.c":18:15 47 {*movdi_aarch64}
(nil))
(insn 11 10 12 3 (set (reg:DI 100)
(subreg:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91102
--- Comment #2 from Segher Boessenkool ---
91102.c: In function 'foo':
91102.c:7:1: warning: control reaches end of non-void function [-Wreturn-type]
7 | }
| ^
so ice-on-invalid-code?
Although, hrm, inserting "return 3;" there still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89072
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #25 from Segher Boessenkool ---
At expand time, the assignment is
;; c_ = c;
(insn 35 34 36 (set (reg/f:DI 140)
(unspec:DI [
(symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
(reg:DI 2 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #24 from Segher Boessenkool ---
Is that disallowed? Is there any way to prevent that from happening, in
general?
1201 - 1300 of 3115 matches
Mail list logo
