https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95133
--- Comment #2 from James Greenhalgh ---
Should reproduce further back if you force it on with -ftree-vectorize .
i.e.
gcc foo.c -ftree-vectorize -O3
Breaks somewhere between:
gcc version 7.0.0 20160615
gcc version 7.0.0 20160907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96313
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
It was pointed out that some forks of GCC (
https://github.com/FEX-Emu/gcc/commit/8a2b7389f50a50a4e26ec98101d47fb1fc1c1bcd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96958
--- Comment #1 from James Greenhalgh ---
Asleep at the wheel today, I had intended to link to the
https://gcc.gnu.org/pipermail/libstdc++/2011-September/036420.html original
discussion rather than leave it as a tedious exercise for the reader.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Created attachment 30290
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30290&action=edit
Reduced testcase
Using built-in specs.
COLLECT_GCC=../build-a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
A bisect shows that this bug first occurs after r197095:
2013-03-26 Richard Biener
* emit-rtl.c (set_mem_attributes_minus_bitpos): Remove
alignment computations and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
--- Comment #4 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 30293
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30293&action=edit
Less reduced failing testcase
Yes, the same thing happens for packed versions of those
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58106
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2013-08-09
Ever
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
The patch set around [1/4] Using gen_int_mode instead of GEN_INT causes a
number of similair regressions when building for AArch64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58383
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot
tus: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Created attachment 30917
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30917&a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
--- Comment #1 from jgreenhalgh at gcc dot gnu.org ---
Created attachment 30918
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30918&action=edit
Output of dom1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59037
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
Bug 19794 depends on bug 54742, which changed state.
Bug 54742 Summary: Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742
What|Removed |Added
--
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
The following code:
typedef unsigned char uint8x8_t
__attribute__ ((__vector_size__ (8)));
typedef unsigned short
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
A colleague tripped up on this typo:
void bar();
void
foo (int x)
{
if (x) return
bar ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85466
--- Comment #11 from James Greenhalgh ---
With Jonathon's suggested change, copied in to the original poster's framework
(without -fno-trapping-math), Clang hot loop ( score: 165065
http://quick-bench.com/6NaD8ay0f8qMh9n0aMriYEiuKNA ) is:
0.16%
: middle-end
Assignee: luis.machado at linaro dot org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: hjl.tools at gmail dot com, law at redhat dot com,
luis.machado at linaro dot org
Target Milestone: ---
Target: x86-64-none-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85682
--- Comment #3 from James Greenhalgh ---
The bisect robot doesn't bootstrap, only build a stage 1 compiler.
I've checked your most recent patch against these testcases, and they execute
and complete fine.
(In reply to Luis Machado from comment
||2018-01-03
CC||jgreenhalgh at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from James Greenhalgh ---
I
||2018-01-25
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from James Greenhalgh ---
Confirmed on aarch64-none-linux-gnu. My bisect pointed to the same revision
r255569 . The 50x slow
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-none-linux-gnu, x86-64-none-linux-gnu
Hi
Our testing robot spotted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84242
--- Comment #1 from James Greenhalgh ---
Also gcc.target/i386/mvc9.c on x86-64-none-linux-gnu.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: itsimbal at gcc dot gnu.org
Target Milestone: ---
Target: x86-64-none-linux-gnu, aarch64-none-linux-gnu
Hi, our bisect robot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84243
--- Comment #2 from James Greenhalgh ---
gcc -v:
Configured with: .../gcc/configure --disable-bootstrap
--enable-languages=c,c++,fortran --disable-multilib --disable-libsanitizer
--prefix=.../build/install/
FAIL: gcc.target/i386/cet-intrin-3
||2018-07-30
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from James Greenhalgh ---
On the platforms I'm looking at, this is equal to a 13% regression in dynamic
instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84521
James Greenhalgh changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
For this code compiled at -Ofast:
double bar (double, double, double, double, double);
double
foo (double a)
{
return bar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556
James Greenhalgh changed:
What|Removed |Added
CC||jgreenhalgh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
--- Comment #2 from James Greenhalgh ---
(In reply to Jakub Jelinek from comment #1)
> I guess ifcvt only triggers some latent bug, either RA or more likely in
> reg-stack. That said, all the comments about the r229822 changes say its
> purpose
}(?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: kyrylo.tkachov at arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371
James Greenhalgh changed:
What|Removed |Added
Target|arm-none-eabi |arm-none-eabi,
|
||2016-02-22
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from James Greenhalgh ---
Confirmed, I'm trying to figure out what is going wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69841
James Greenhalgh changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69841
James Greenhalgh changed:
What|Removed |Added
CC||alan.lawrence at arm dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69841
James Greenhalgh changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
-*-*,
||arm*-*-*
Last reconfirmed|2016-02-29 00:00:00 |2016-3-7
CC||jgreenhalgh at gcc dot gnu.org
--- Comment #5 from James Greenhalgh ---
Also failing on arm/aarch64 (so good further evidence of signed vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69841
--- Comment #5 from James Greenhalgh ---
I don't know enough about the C++ standard to know whether this patch is
reasonable to backport to GCC 5. Jason, do you have an opinion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232
--- Comment #8 from James Greenhalgh ---
(In reply to Pat Haugen from comment #6)
> (In reply to James Greenhalgh from comment #5)
> > "Fixed" with the testsuite skips. Feel free to add any other target triplets
> > for which this test is unrelia
||jgreenhalgh at gcc dot gnu.org
--- Comment #5 from James Greenhalgh ---
The crux of this issue is going to be that your Cortex-A53 has no support for
the cryptography extension, but does have support for the CRC extensions.
By inspection of host_detect_local_cpu, I see that we run
|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
--- Comment #8 from James Greenhalgh ---
(In reply to Christophe Lyon from comment #6)
> > 3) We should think about whether we need to put out these +no extension
> > strings at all. I don't like that for my older sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133
James Greenhalgh changed:
What|Removed |Added
Target||aarch64*-none-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749
--- Comment #4 from James Greenhalgh ---
Hi, sorry I missed this. I need to write a better filter for bugs I'm CCed on,
I'll work on that.
I'm hitting the limits of what I can guess from the Sparc machine files. I
don't understand why we get an
|NEW
Last reconfirmed||2016-04-01
CC||jgreenhalgh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from James Greenhalgh ---
Fails for me on trunk and 5.3. Trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896
--- Comment #6 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Apr 1 09:45:44 2016
New Revision: 234665
URL: https://gcc.gnu.org/viewcvs?rev=234665&root=gcc&view=rev
Log:
Backport: [PATCH] Do not set structural equality on polynomial ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896
James Greenhalgh changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||jgreenhalgh at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from James Greenhalgh ---
Try compiling and running with -fsanitize=undefined. You have a bug in your
logic that results in an out-of-bounds memory access:
.../ab2.cpp:97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133
--- Comment #10 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Apr 11 10:14:59 2016
New Revision: 234876
URL: https://gcc.gnu.org/viewcvs?rev=234876&root=gcc&view=rev
Log:
[Patch AArch64 2/3] Rework the code to print extension strings (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133
--- Comment #11 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Apr 11 10:16:26 2016
New Revision: 234877
URL: https://gcc.gnu.org/viewcvs?rev=234877&root=gcc&view=rev
Log:
[Patch AArch64 3/3] Fix up for pr70133
gcc/
PR target/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133
James Greenhalgh changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69841
James Greenhalgh changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #
||jgreenhalgh at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from James Greenhalgh ---
Please, stop this.
||jgreenhalgh at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from James Greenhalgh ---
Hi Lewis,
This bugzilla is for reporting bugs against GCC, rather than asking for usage
help. Feel free to post the same message on gcc-h
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
Take this simple testcase:
void
foo (float * __restrict__ __attribute__ ((aligned (16
||jgreenhalgh at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #11 from James Greenhalgh ---
Looks like this is fixed on all live branches. Ramana, please reopen if there
is something more to be done that I've missed.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
CC: kugan.vivekanandarajah at linaro dot org
Target Milestone: ---
Created attachment 38671
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38671&action=edit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81456
--- Comment #2 from James Greenhalgh ---
(In reply to Martin Liška from comment #1)
> Confirmed, started with r238594.
The cost model relies on the target giving a reasonable approximation for an
instruction size through ix86_rtx_costs.
The bas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81832
James Greenhalgh changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
A destructive operation is one in which an input operand is both read and
written. For example, in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82237
James Greenhalgh changed:
What|Removed |Added
Target||aarch64*-*-*
Status|UNCON
||jgreenhalgh at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from James Greenhalgh ---
Comment 1 claims this is fixed, Andrew, please reopen if it is still an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250
James Greenhalgh changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #8 from James Greenhalgh ---
In the case before Honza's patch, corrupt profile information leads to a branch
being marked as 100% taken. After Honza's patch, the branch is instead seen
with 95.6% taken:
(jump_insn 1916 1915 1922 309
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #10 from James Greenhalgh ---
The most striking improvement was in libquantum, for which we saw a 15%
performance improvement on Cortex-A72 (3% on cortex-A57) directly attributable
to basic block ordering after this patch.
Otherwise,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79534
--- Comment #12 from James Greenhalgh ---
So while there's nothing buggy about the if-conversion which causes the
performance issue, it does show an interesting missed optimization that ifcvt
can't handle.
We make the transform through find_if_c
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
This testcase:
double
bar (double a)
{
return 1.0/__builtin_sqrt(a);
}
Fails with an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80457
--- Comment #3 from James Greenhalgh ---
(In reply to Bill Schmidt from comment #2)
> Per https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00967.html, James
> Greenhalgh has a more comprehensive patch for this, so removing myself from
> the Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80457
--- Comment #7 from James Greenhalgh ---
Thanks for your help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
--- Comment #7 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Jun 16 17:29:56 2017
New Revision: 249272
URL: https://gcc.gnu.org/viewcvs?rev=249272&root=gcc&view=rev
Log:
[Patch ARM] Fix PR71778
gcc/
PR target/71778
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
--- Comment #8 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Jun 19 16:58:03 2017
New Revision: 249379
URL: https://gcc.gnu.org/viewcvs?rev=249379&root=gcc&view=rev
Log:
Backport: [Patch ARM] Fix PR71778
gcc/
PR target/71778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
--- Comment #9 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Jun 19 17:12:12 2017
New Revision: 249380
URL: https://gcc.gnu.org/viewcvs?rev=249380&root=gcc&view=rev
Log:
Backport: [Patch ARM] Fix PR71778
gcc/
PR target/71778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71778
James Greenhalgh changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250
--- Comment #5 from James Greenhalgh ---
Author: jgreenhalgh
Date: Wed Nov 23 17:36:21 2016
New Revision: 242784
URL: https://gcc.gnu.org/viewcvs?rev=242784&root=gcc&view=rev
Log:
[Patch ARM 17/17] Enable _Float16 for ARM and fix PR target/63250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #2 from James Greenhalgh ---
(In reply to Rainer Orth from comment #1)
> James, this is caused by your patch series
>
> [Patch 1/17] Add a new target hook for describing excess precision intentions
>
> I believe.
>
> Rainer
Than
||2016-11-24
Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #4 from James Greenhalgh ---
Well, certainly this comment and assert in tree.c:
/* The target should not ask for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #6 from James Greenhalgh ---
None of the logic was there in the original code, so there is not much to
compare.
The question for the backend when TYPE is EXCESS_PRECISION_TYPE_FAST or
EXCESS_PRECISION_TYPE_STANDARD is, does it wants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #8 from James Greenhalgh ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to James Greenhalgh from comment #6)
> > None of the logic was there in the original code, so there is not much to
> > compare.
>
> ?? Since -fexce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #9 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Nov 25 09:25:31 2016
New Revision: 242866
URL: https://gcc.gnu.org/viewcvs?rev=242866&root=gcc&view=rev
Log:
[Patch i386] PR78509 - TARGET_C_EXCESS_PRECISION should not retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #10 from James Greenhalgh ---
Should now be fixed, but I'll leave open for Rainer to confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509
--- Comment #12 from James Greenhalgh ---
I tried looking at the generated assembly for that test with the compilers I
built before my patch series, and after the patch series + the fix above. I
couldn't see any difference in code generated for t
||jgreenhalgh at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #12 from James Greenhalgh ---
I can still trigger this with a testcase using 16-bit floating-point types, and
the tiny memory model:
int
main (__fp16 x)
{
__fp16 a
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
This bug report is mostly from inspection, but the effects of this issue can be
seen with this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
James Greenhalgh changed:
What|Removed |Added
Target||aarch64*-*-*
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70120
James Greenhalgh changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78547
James Greenhalgh changed:
What|Removed |Added
CC||hjl at gcc dot gnu.org,
|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot
gnu.org
--- Comment #1 from James Greenhalgh ---
Well, confirmed - and an easy fix is to recompute the offset data while
sweeping for valid constants at the end of compilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
James Greenhalgh changed:
What|Removed |Added
Last reconfirmed|2016-09-03 00:00:00 |2016-11-30
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
--- Comment #7 from James Greenhalgh ---
Right, I've trimmed too much context from my message.
This performance regression starts with r239219 which adds a cost model to the
threader which relies on frequency information (arguably this is a bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #2 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Dec 2 14:29:35 2016
New Revision: 243182
URL: https://gcc.gnu.org/viewcvs?rev=243182&root=gcc&view=rev
Log:
[Patch 1/2 PR78561] Rename get_pool_size to get_pool_size_upper_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #3 from James Greenhalgh ---
Author: jgreenhalgh
Date: Fri Dec 2 14:31:10 2016
New Revision: 243183
URL: https://gcc.gnu.org/viewcvs?rev=243183&root=gcc&view=rev
Log:
[Patch 2/2 PR78561] Recalculate constant pool size before emittin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #6 from James Greenhalgh ---
Author: jgreenhalgh
Date: Mon Dec 5 09:35:28 2016
New Revision: 243239
URL: https://gcc.gnu.org/viewcvs?rev=243239&root=gcc&view=rev
Log:
[Patch 2/2 PR78561] Recalculate constant pool size before emittin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #7 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #5)
> Oh btw, you forgot to commit the testcase in 2/2.
Thanks, that's the easy one to fix. Would you be able to help me with a
configure line I can use for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #9 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #8)
> I usually use --disable-libgomp, but otherwise everything default (well,
> --enable-languages=all,ada,go,obj-c++).
I need a bit more hand holding on this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #11 from James Greenhalgh ---
My bootstrap at r243245 on gcc110 seemed to work fine.
[jgreenhalgh@gcc1-power7 gcc]$ ../build-gcc/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=../build-gcc/gcc/xgcc
Target: powerpc64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #13 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #12)
> It still happens here, also on gcc110. Note you need --disable-werror,
> to avoid another bootstrap error.
>
> Did you perchance use --disable-bootstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78561
--- Comment #15 from James Greenhalgh ---
(In reply to Segher Boessenkool from comment #14)
> I used trunk. --disable-bootstrap fails the same, just much faster ;-)
>
> Maybe the binutils etc. version matters?
Do you have a "modern" GCC on pat
1 - 100 of 299 matches
Mail list logo
