https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|11.4|11.5
--- Comment #25 from Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #8 from Richard Earnshaw ---
Perhaps something is changing the decision on the use of the frame pointer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #7 from Christophe Lyon ---
Indeed, but I am surprised it seems to compile for cortex-m4?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-09-27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #5 from Christophe Lyon ---
Could you share the preprocessed source file in the M3 and M4 cases along with
the full command line used to compile it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #4 from Thomas Petazzoni ---
Yes, same triplet. We do not (yet) have FDPIC support for ARM in Buildroot (we
have a patch series pending for that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #3 from Christophe Lyon ---
Interesting
Did you use the same target triplet?
arm*-*-uclinuxfdpiceabi is handled differently from
arm-buildroot-uclinux-uclibcgnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
--- Comment #2 from Thomas Petazzoni ---
Thanks for the feedback. There must be something special in those
configurations, because I did build a Cortex-M4 configuration with gcc 11.3.0
just a few days ago, and it built fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107032
Bug ID: 107032
Summary: ARM: libgcc2.c:2174:1: error: r7 cannot be used in
'asm' here
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
--- Comment #8 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:a6a0f3423f3053999c0eb6e7183319c1dca6455d
commit r12-8526-ga6a0f3423f3053999c0eb6e7183319c1dca6455d
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:e7d9fdf5e0ee4c34a880139254340b4165016289
commit r13-285-ge7d9fdf5e0ee4c34a880139254340b4165016289
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
--- Comment #5 from Tobias Burnus ---
(In reply to Richard Biener from comment #4)
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> +#ifndef DWARF2_DEBUGGING_INFO
> + || 1
> +#endif
> seems to get past the failure point - can you check a full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-05-11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
--- Comment #3 from Richard Biener ---
Ah, so I see nvptx_option_override sets flag_var_tracking to 0, but that should
be in effect at finish_option time already.
But as said, since we have
if (opts->x_debug_info_level < DINFO_LEVEL_NORMAL
|in final_scan_insn_1, at
>|final.cc:2629 when building |final.cc:2629 when building
> |libgcc2.c since |libgcc2.c since
>|r13-259-g76db543db88727789a |r13-259-g76db543db88727789a
>|6c117608a23e
in |[13 Regression] [nvptx] ICE
|final_scan_insn_1, at |in final_scan_insn_1, at
|final.cc:2629 when building |final.cc:2629 when building
|libgcc2.c since |libgcc2.c since
|r13-259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105551
Bug ID: 105551
Summary: [nvptx] ICE in final_scan_insn_1, at final.cc:2629
when building libgcc2.c since
r13-259-g76db543db88727789a6c117608a23edc2eace713
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Richard Biener changed:
What|Removed |Added
Target Milestone|11.3|11.4
--- Comment #24 from Richard
Hi @ll,
the "magic" constants 0x55...55, 0x33...33, 0x0f...0f and 0x01...01 used
in the popcountsi2() and popcountdi2() functions defined in libgcc2.c are
currently generated iterative via the 4 macros POPCOUNTCST, POPCOUNTCST8,
POPCOUNTCST4 and POPCOUNTCST2 from 2 nibbles over 4 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #23 from Richard Biener ---
I do not plan to backport this given it's quite intrusive and had some fallout.
-*-*
Summary|[11/12 Regression] |[11 Regression] Unoptimal
|Unoptimal code for __negdi2 |code for __negdi2 (and
|(and others) from libgcc2 |others) from libgcc2 due to
|due to unwanted |unwanted vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #21 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:90d693bdc9d71841f51d68826ffa5bd685d7f0bc
commit r12-7319-g90d693bdc9d71841f51d68826ffa5bd685d7f0bc
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #20 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f24dfc76177b3994434c8beb287cde1a9976b5ce
commit r12-7318-gf24dfc76177b3994434c8beb287cde1a9976b5ce
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #19 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:61fc5e098e76c9809f35f449a70c9c8d74773d9d
commit r12-7317-g61fc5e098e76c9809f35f449a70c9c8d74773d9d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #18 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Hmm:
> _14 = {_1, _5};
> _8 = VIEW_CONVERT_EXPR<__int128>(_14);
>
> Wouldn't it better to convert that to just (hopefully I got the order
> correct):
> t1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #17 from Richard Biener ---
For
FAIL: gcc.target/i386/pr91446.c scan-assembler-times vmovdqa[^\\n\\r]*xmm[0-9]
2
we used to produce
:
0: 48 83 ec 28 sub$0x28,%rsp
4: c4 e1 f9 6e d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #15 from Richard Biener ---
The patch will cause
FAIL: gcc.target/i386/pr91446.c scan-assembler-times vmovdqa[^\\n\\r]*xmm[0-9]
2
FAIL: gcc.target/i386/pr92658-avx512bw-2.c scan-assembler-times pmovsxdq 2
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #14 from Richard Biener ---
Another testcase is
struct S { double a, b; } s;
void
foo (double a, double b)
{
s.a = a;
s.b = b;
}
which also receives the same costs and compiles vectorized to
unpcklpd %xmm1,%xmm0
movaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #13 from Richard Biener ---
Created attachment 52476
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52476=edit
minimal patch
This is a minimal untested patch adjusting APIs to allow for the cost hook to
receive a slp_node in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #12 from rguenther at suse dot de ---
On Fri, 18 Feb 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
>
> --- Comment #11 from Jakub Jelinek ---
> True.
> So another option is to try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #11 from Jakub Jelinek ---
True.
So another option is to try to undo some of those short vectorization cases
during isel, expansion or later, though e.g. for the negdi2 case it will go
already during expansion into memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #10 from Richard Biener ---
Btw, I think it makes sense to build libgcc with -mno-sse, maybe even
-mgeneral-regs-only. Or globally with -fno-tree-vectorize (but we likely do
not want
%xmm uses for parameter setup either with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #9 from Richard Biener ---
(In reply to Jakub Jelinek from comment #8)
> Just trying a dumb microbenchmark:
> struct S { unsigned long a, b; } s;
>
> __attribute__((noipa)) void
> foo (unsigned long a, unsigned long b)
> {
> s.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #8 from Jakub Jelinek ---
Just trying a dumb microbenchmark:
struct S { unsigned long a, b; } s;
__attribute__((noipa)) void
foo (unsigned long a, unsigned long b)
{
s.a = a;
s.b = b;
}
int
main ()
{
int i;
for (i = 0; i <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> The costs look weird:
> _1 1 times scalar_store costs 12 in body
> _5 1 times scalar_store costs 12 in body
> _1 1 times vector_store costs 12 in body
> 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-02-18
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #5 from Jakub Jelinek ---
The costs look weird:
_1 1 times scalar_store costs 12 in body
_5 1 times scalar_store costs 12 in body
_1 1 times vector_store costs 12 in body
1 times vec_construct costs 8 in prologue
vec_construct is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #4 from Jakub Jelinek ---
What slp does is just
- w.s.low = _1;
- w.s.high = _5;
+ _14 = {_1, _5};
+ MEM[(union *)] = _14;
I must say I don't really see that as a beneficial optimization, construction
of a vector from scalars
Summary|Unoptimal code for __negdi2 |[11/12 Regression]
|(and others) from libgcc2 |Unoptimal code for __negdi2
|due to unwanted |(and others) from libgcc2
|vectorization |due to unwanted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
--- Comment #2 from Uroš Bizjak ---
Please note that gcc-10 does not vectorize the testcase even with -O3
-ftree-vectorize.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Uroš Bizjak changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Bug ID: 104582
Summary: Unoptimal code for __negdi2 (and others) from libgcc2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67379
Vittorio Zecca changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
ant 0x55...55 here,
and the other constants of course too.
> don't you really mean ~(UWtype) 0 instead?
This is indeed the better^Wcorrect solution.
Corrected patch attached.
Stefan
libgcc2.patch
Description: Binary data
On Fri, Nov 20, 2020 at 11:08:41AM +0100, Stefan Kanthak wrote:
> The construction of the "magic" constants 0x55...55, 0x33...33, 0x0f...0f
> and 0x01...01 in __popcountSI2 and __popcountDI2 with macros is awkward;
> these constants can simply be written as ((UWtype) ~0 / 3),
> ((UWtype) ~0 / 5),
The construction of the "magic" constants 0x55...55, 0x33...33, 0x0f...0f
and 0x01...01 in __popcountSI2 and __popcountDI2 with macros is awkward;
these constants can simply be written as ((UWtype) ~0 / 3),
((UWtype) ~0 / 5), ((UWtype) ~0 / 17) and ((UWtype) ~0 / 255)
Stefan Kantha
Hello,
On Thu, 12 Nov 2020, Stefan Kanthak wrote:
> Does GCC generate (unoptimised) code there, similar to the following i386
> assembly, using 4 loads, 4 shifts, 2 ands plus 3 ors?
Try for yourself. '-m32 -O2 -march=i386' is your friend.
Ciao,
Michael.
Spoiler: it's generating:
libgcc2.c defines __bswapsi2() as follows:
typedef int SItype __attribute__ ((mode (SI)));
SItype
__bswapsi2 (SItype u)
{
return u) & 0xff00) >> 24)
| (((u) & 0x00ff) >> 8)
| (((u) & 0xff00) << 8)
| (((u) & 0x00ff) <<
libgcc2 provides "double-word" division as __udivmoddi4()
The following part of its source
| UWtype d0, d1, n0, n1, n2;
| UWtype b, bm;
...
| count_leading_zeros (bm, d1);
| if (bm == 0)
...
| else
| {
| UWtype m1, m0;
| /* Normalize. */
|
| b = W_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
--- Comment #6 from Nick Briggs ---
Perhaps the info at https://gcc.gnu.org/install/specific.html could be updated
in the sparc*solaris section to include the notes about gnu as in the same way
that the x86*solaris section mentions it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
--- Comment #5 from Andrew Pinski ---
This is documented on https://gcc.gnu.org/install/configure.html too:
Confusion may also result if the compiler finds the GNU assembler but has not
been configured with --with-gnu-as.
...
The following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
--- Comment #3 from Nick Briggs ---
Could not configuring with "--with-gnu-as" have caused this?
Also, since it seems to be related to COMDAT, would "--disable-comdat" (if such
an option exists, since only --enable-comdat is documented) have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
--- Comment #2 from Nick Briggs ---
binutils/as version is:
/opt/binutils/bin/as --version
GNU assembler (GNU Binutils) 2.35
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
--- Comment #1 from Nick Briggs ---
Created attachment 48948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48948=edit
Intermediate output from gcc-9.3.0 compiling libgcc2 during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96362
Bug ID: 96362
Summary: bootstrapping gcc 9.3.0 on sparc-sun-solaris2.11 fails
compiling libgcc2.c (.group in output)
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
Bug 30370 depends on bug 30259, which changed state.
Bug 30259 Summary: ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66939
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
Hello!
As exposed by gcc.dg/torture/fp-int-convert-timode-?.c testcases from
PR88931, it is expected that libgcc2 rounds calculations according to
set FP rounding mode. To achieve dynamic rounding, we have to pass
-mfp-rounding-mode=d in addition to -mieee when compiling libgcc2.
2019-01-31
On Thu, 24 Jan 2019, Christophe Lyon wrote:
> On Thu, 24 Jan 2019 at 15:31, Joseph Myers wrote:
> >
> > On Thu, 24 Jan 2019, Christophe Lyon wrote:
> >
> > > The attached small patch adds
> > > /* { dg-require-effective-target fenv_exceptions } */
> > > to them.
> >
> > It should be a *new*
The test gcc.dg/torture/fp-int-convert-timode-3.c fails on darwin: the results
are
-0x1p+127
-0x1p+127
TIA
Dominique
On Thu, 24 Jan 2019 at 15:31, Joseph Myers wrote:
>
> On Thu, 24 Jan 2019, Christophe Lyon wrote:
>
> > The attached small patch adds
> > /* { dg-require-effective-target fenv_exceptions } */
> > to them.
>
> It should be a *new* effective-target, because these tests are nothing to
> do with
On Thu, 24 Jan 2019, Christophe Lyon wrote:
> The attached small patch adds
> /* { dg-require-effective-target fenv_exceptions } */
> to them.
It should be a *new* effective-target, because these tests are nothing to
do with exceptions; they're about rounding modes (but actually you only
need
On Wed, 23 Jan 2019 at 22:14, H.J. Lu wrote:
>
> On Wed, Jan 23, 2019 at 12:50 PM Joseph Myers wrote:
> >
> > On Wed, 23 Jan 2019, H.J. Lu wrote:
> >
> > > + fesetround (FE_DOWNWARD);
> > > + float fs = s128;
> > > + if (fs != -0x1p+127)
> > > +abort ();
> > > + double ds = s128;
> > > +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931
--- Comment #5 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Wed Jan 23 21:41:59 2019
New Revision: 268216
URL: https://gcc.gnu.org/viewcvs?rev=268216=gcc=rev
Log:
libgcc2.c: Correct DI/TI -> SF/DF conversions
FSTYPE FUNC (DWtyp
f988a6e34aed324f13b777af82deb Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 22 Jan 2019 18:55:35 -0800
Subject: [PATCH] libgcc2.c: Correct DI/TI -> SF/DF conversions
FSTYPE FUNC (DWtype u) in libgcc2.c, which converts DI/TI to SF/DF, has
/* No leading bits means u == minimu
On Wed, 23 Jan 2019, H.J. Lu wrote:
> + fesetround (FE_DOWNWARD);
> + float fs = s128;
> + if (fs != -0x1p+127)
> +abort ();
> + double ds = s128;
> + if (ds != -0x1p+127)
> +abort ();
This definitely needs #ifdef FE_DOWNWARD; even just limited to glibc
configurations, there are
FSTYPE FUNC (DWtype u) in libgcc2.c, which converts DI/TI to SF/DF, has
/* No leading bits means u == minimum. */
if (count == 0)
return -(Wtype_MAXp1_F * (Wtype_MAXp1_F / 2));
in the third case (where actually count == 0 only means the high part is
minimum). It should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43944
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
On 10/3/18 12:48 PM, Uros Bizjak wrote:
> On Wed, Oct 3, 2018 at 6:53 PM Jeff Law wrote:
>>
>> On 10/2/18 9:41 AM, Uros Bizjak wrote:
>>> Nowadays, we have these type-generic builtins always available.
>>>
>>> 2018-10-02 Uros Bizjak
>>&g
On Wed, Oct 3, 2018 at 6:53 PM Jeff Law wrote:
>
> On 10/2/18 9:41 AM, Uros Bizjak wrote:
> > Nowadays, we have these type-generic builtins always available.
> >
> > 2018-10-02 Uros Bizjak
> >
> > * libgcc2.c (isnan): Use __builtin_isnan.
> &
On 10/2/18 9:41 AM, Uros Bizjak wrote:
> Nowadays, we have these type-generic builtins always available.
>
> 2018-10-02 Uros Bizjak
>
> * libgcc2.c (isnan): Use __builtin_isnan.
> (isfinite): Use __builtin_isfinite.
> (isinf): Use __builtin_isinf.
>
>
Nowadays, we have these type-generic builtins always available.
2018-10-02 Uros Bizjak
* libgcc2.c (isnan): Use __builtin_isnan.
(isfinite): Use __builtin_isfinite.
(isinf): Use __builtin_isinf.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
OK for mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Hans-Peter Nilsson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #15 from Hans-Peter Nilsson ---
Author: hp
Date: Sun Sep 16 21:23:36 2018
New Revision: 264351
URL: https://gcc.gnu.org/viewcvs?rev=264351=gcc=rev
Log:
PR target/85666
* config/mmix/mmix.c (mmix_assemble_integer):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Hans-Peter Nilsson changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #13 from Hans-Peter Nilsson ---
Author: hp
Date: Sun Sep 9 18:12:14 2018
New Revision: 264183
URL: https://gcc.gnu.org/viewcvs?rev=264183=gcc=rev
Log:
PR target/85666
* config/mmix/mmix.c (mmix_assemble_integer):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #12 from Hans-Peter Nilsson ---
Author: hp
Date: Sun Sep 9 18:05:48 2018
New Revision: 264182
URL: https://gcc.gnu.org/viewcvs?rev=264182=gcc=rev
Log:
PR target/85666
* config/mmix/mmix.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #11 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #10)
> Created attachment 44180 [details]
> patch to mmix.c
>
> Builds libgcc. More late this weekend, I hope.
I now see the assertion in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #10 from Hans-Peter Nilsson ---
Created attachment 44180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44180=edit
patch to mmix.c
Builds libgcc. More late this weekend, I hope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #9 from Hans-Peter Nilsson ---
(In reply to Wilco from comment #8)
> I don't think that comment is accurate.
Of course it isn't accurate *now*, but it explains why the code looks as it is.
I see the "phase-computing" code in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #8 from Wilco ---
(In reply to Hans-Peter Nilsson from comment #7)
> Thank you for your interest in the MMIX port.
>
> (In reply to Wilco from comment #3)
> > (In reply to Sergei Trofimovich from comment #1)
> >
> > > #define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #7 from Hans-Peter Nilsson ---
Thank you for your interest in the MMIX port.
(In reply to Wilco from comment #3)
> (In reply to Sergei Trofimovich from comment #1)
>
> > #define MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #6 from Sergei Trofimovich ---
An observation (does not pretend to be a fix) to make gcc compile standard
library and be able to build runnable hello world on gcc master:
1. MMIX_CFUN_NEEDS_SAVED_EH_RETURN_ADDRESS can be unoptimised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #5 from Sergei Trofimovich ---
(In reply to Hans-Peter Nilsson from comment #4)
> (In reply to Sergei Trofimovich from comment #0)
> > gcc-7.3.0 worked. gcc-8.0.1 fails as:
>
> Don't you mean "9.0.1" which is what gcc outputs for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Sergei Trofimovich changed:
What|Removed |Added
CC||wdijkstr at arm dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
--- Comment #1 from Sergei Trofimovich ---
looks like leaf_function_p() predicate fails right at start of cfgexpand when
it tries to pick stack frame size. leaf_function_p() has a few hints that it's
knowingly trying to do it before expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85666
Bug ID: 85666
Summary: gcc-8.0.1 fails to build mmix target:
gcc/libgcc/libgcc2.h:203:20: internal compiler error:
in leaf_function_p, at final.c:4488
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78385
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78118
--- Comment #6 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Wed May 31 00:05:01 2017
New Revision: 248713
URL: https://gcc.gnu.org/viewcvs?rev=248713=gcc=rev
Log:
xtensa: Fix PR target/78118
It started failing after the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78385
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |target
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78385
Bug ID: 78385
Summary: Build of libgcc2 for target arm-eabi fails, if
configuration --with-abi=apcs-gnu is used (in
GCC-Build)
Product: gcc
Version: 6.2.0
1 - 100 of 584 matches
Mail list logo
