https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90576
--- Comment #5 from Martin Liška ---
@Maxim: Can you please retest it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92653
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92653
Bug ID: 92653
Summary: [10 Regression] PGO bootstrap is broken with
--with-build-config=bootstrap-lto-lean
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
franz changed:
What|Removed |Added
CC||franz.flasch at gmx dot at
--- Comment #4 from f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616
--- Comment #7 from Anthony Williams ---
Reported as ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-oem/+bug/1853807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92632
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92055
--- Comment #10 from Georg-Johann Lay ---
Author: gjl
Date: Mon Nov 25 08:59:06 2019
New Revision: 278668
URL: https://gcc.gnu.org/viewcvs?rev=278668&root=gcc&view=rev
Log:
gcc/
Build double32 / long-double32 multilibs if needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
Bug ID: 92654
Summary: internal compiler error: in lookup_template_class_1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92655
Bug ID: 92655
Summary: Suboptimal vectorization of variable shift
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92655
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92655
--- Comment #2 from Richard Biener ---
"Fixed" source (MULWU), side-stepping GENERIC folding/narrowing of the
subtract:
inline uint64_t MULWU(uint64_t k, uint64_t m)
{
unsigned long xyz = BITS-m;
return (( (k)<<(m) & M61) + ( (k) >> (xyz))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646
--- Comment #2 from Mysaa ---
I tried again to compile in a dedicated directory, the same error occurs :
/home/bernard/building/gcc-9.2.0/bld/./gcc/xgcc
-B/home/bernard/building/gcc-9.2.0/bld/./gcc/
-B/usr/local/armv7l-unknown-linux-gnueabihf/bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
--- Comment #2 from Richard Biener ---
Btw, which variant is actually the fastest for you? abs expansion doesn't
do any cost comparison but just uses direct abs, max and then the xor with
shift as third option (and after that fall back to compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92626
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92628
Richard Biener changed:
What|Removed |Added
Blocks||49774
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85861
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #13)
> (In reply to Jonathan Wakely from comment #11)
> > My guess is that we don't want to warn about conversions that are
> > well-defined and the original value can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92628
--- Comment #4 from Tobias Burnus ---
(In reply to Richard Biener from comment #3)
> I think we have a duplicate asking about restrict to have an effect on
> function calls.
Could be PR tree-optimization/81008.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646
--- Comment #3 from Andreas Schwab ---
Where is located then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91956
--- Comment #3 from Martin Jambor ---
Author: jamborm
Date: Mon Nov 25 10:09:42 2019
New Revision: 278669
URL: https://gcc.gnu.org/viewcvs?rev=278669&root=gcc&view=rev
Log:
Make IPA-SRA follow comdat-local rules (PR 91956)
2019-11-25 Martin Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92109
--- Comment #8 from Martin Jambor ---
Author: jamborm
Date: Mon Nov 25 10:13:08 2019
New Revision: 278670
URL: https://gcc.gnu.org/viewcvs?rev=278670&root=gcc&view=rev
Log:
ipa: Prevent materialization of clones with removed bodies (PR 92109)
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91956
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92109
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92638
--- Comment #3 from Richard Biener ---
It's not really "iteration" that is missing but the free () stmt is marked
as necessary and only later "elided" but dataflow makes the loop necessary
because of that. We may eventually get away with not con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644
--- Comment #3 from Richard Biener ---
INTEGRAL_TYPE_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575
--- Comment #2 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 25 10:29:51 2019
New Revision: 278671
URL: https://gcc.gnu.org/viewcvs?rev=278671&root=gcc&view=rev
Log:
PR ada/92575
* expect.c (__gnat_expect_poll [VMS, HPUX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 25 10:30:41 2019
New Revision: 278672
URL: https://gcc.gnu.org/viewcvs?rev=278672&root=gcc&view=rev
Log:
PR ada/92575
* expect.c (__gnat_expect_poll [VMS, HPUX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 25 10:31:20 2019
New Revision: 278673
URL: https://gcc.gnu.org/viewcvs?rev=278673&root=gcc&view=rev
Log:
PR ada/92575
* expect.c (__gnat_expect_poll [VMS, HPUX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 92575, which changed state.
Bug 92575 Summary: couple of suspicious assignments in expect.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644
--- Comment #4 from Jakub Jelinek ---
Created attachment 47350
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47350&action=edit
gcc10-pr92644.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 25 10:48:55 2019
New Revision: 278675
URL: https://gcc.gnu.org/viewcvs?rev=278675&root=gcc&view=rev
Log:
PR ada/92362
* gcc-interface/trans.c (gnat_to_gnu) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362
--- Comment #4 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 25 10:52:33 2019
New Revision: 278676
URL: https://gcc.gnu.org/viewcvs?rev=278676&root=gcc&view=rev
Log:
PR ada/92362
* gcc-interface/trans.c (gnat_to_gnu) :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92362
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92637
--- Comment #3 from John Dong ---
(In reply to Andrew Pinski from comment #1)
> > 214: aa0a03e0mov x0, x10 // HERE x10 is
> > overwriten by glibc
>
>
> Hmm, GCC knows that find_next_zero_bit will not clobber x10 so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #7 from Richard Biener ---
Kind-of a testcase for SSE2, but this has a matching BIT_FIELD_REF at least,
but still "fails" at the vector source. Skia seems to pun to __int128
before doing the extracts somehow (maybe that's our intrins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646
--- Comment #4 from Mysaa ---
There is two of them :
bernard@pipi:~$ locate cdefs.h
/home/bernard/building/gcc-9.2.0/fixincludes/tests/base/sys/cdefs.h
/usr/include/arm-linux-gnueabihf/sys/cdefs.h
bernard@pipi:~$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92655
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Maybe we could check in vect_determine_min_output_precision_1
whether the result is used as a shift amount, and if so do:
precision = MAX (precision, use_stmt_info->min_output_precision);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92637
John Dong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
Bug ID: 92656
Summary: The zero_extend insn can't be eliminated in the
combine pass
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
--- Comment #5 from franz ---
OK, I've now digged a little further in to this issue.
According to the GCC docs for a native build a 3-stage-build is performed
automatically. So with "--disable-bootstrap" the build should behave the same
as the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #3 from Jiangning Liu ---
It is a stupid test, but it is simplified from a real application.
To solve even more complicated scenario, this simple case needs to be addressed
first.
If we change the case to be as below,
int f(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #2 from fiesh at zefix dot tv ---
It's been made invalid by creduce, but the original code was valid.
If necessary, we can try to produce valid code that leads to the same issue.
But I'd only do so if necessary since it's somewhat cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #3 from fiesh at zefix dot tv ---
(Or is there some other trick to make it valid apart from extending the
interestingness test of creduce to include a clang compilation step?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #14 from Richard Biener ---
Well, lying means that for non-escaped desctiptors A and B doing
A.data = malloc();
gfc_desc_to_cfi_desc (&B, &A)
B.data and A.data are not considered aliasing.
So I'd recommend to not lie here. Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #4 from Martin Liška ---
(In reply to fiesh from comment #2)
> It's been made invalid by creduce, but the original code was valid.
>
> If necessary, we can try to produce valid code that leads to the same issue.
> But I'd only do so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
--- Comment #8 from Bernd Schmidt ---
Author: bernds
Date: Mon Nov 25 12:31:16 2019
New Revision: 278681
URL: https://gcc.gnu.org/viewcvs?rev=278681&root=gcc&view=rev
Log:
Convert m68k to not use cc0
* config/m68k/m68k.c (output_move_hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48188
--- Comment #4 from Zdenek Sojka ---
Doesn't seem to crash since at least gcc-7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #4 from Richard Biener ---
(In reply to Jiangning Liu from comment #3)
> It is a stupid test, but it is simplified from a real application.
>
> To solve even more complicated scenario, this simple case needs to be
> addressed first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228
steffen.seckler at tum dot de changed:
What|Removed |Added
CC||steffen.seckler at tum dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Bug ID: 92657
Summary: High stack usage due ftree-ch
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #15 from Jakub Jelinek ---
I think other fn spec attributes in trans-decl.c should be checked.
E.g. for internal_pack, I see ".r", when the function sometimes returns a
pointer to a field pointed by the first argument. The address of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Eric Gallager changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #20 from Iain Sandoe ---
As of XCode 11.3beta, the contained SDK works OK:
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
We still have the underlying problems - which need to be addressed (so please
don't close this P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #5 from fiesh at zefix dot tv ---
Thank you for your offer. The original translation unit is a whopping 20MB and
took about 3 days to reduce ;-)
I changed the file and the interestingness test to make sure clang compiles it.
It's ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Bug ID: 92658
Summary: x86 lacks vector extend / truncate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
--- Comment #2 from Joseph S. Myers ---
Author: jsm28
Date: Mon Nov 25 13:45:42 2019
New Revision: 278684
URL: https://gcc.gnu.org/viewcvs?rev=278684&root=gcc&view=rev
Log:
Prevent all uses of DFP when unsupported (PR c/91985).
Code that direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> (A) seems pointless in this case, it's right there in the caret diagnostic.
>
> The type size_t is irrelevant.
>
> IMO a better testcase would be:
>
> const in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92653
--- Comment #1 from Martin Liška ---
Author: marxin
Date: Mon Nov 25 13:57:00 2019
New Revision: 278686
URL: https://gcc.gnu.org/viewcvs?rev=278686&root=gcc&view=rev
Log:
Comment too strict checking assert.
2019-11-25 Martin Liska
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Bug ID: 92659
Summary: Suggestions for bitshift
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92660
Bug ID: 92660
Summary: overflow warning message enhancement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #3 from Jonathan Wakely ---
No, not necessarily.
extern const int n; // defined in another file
auto i = 1 << n;
void f(const int n)
{
auto i = 1 << n;
}
Not all const variables are compile-time constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #1 from Richard Biener ---
It looks like there are already some avx512 patterns matching this but they
are not visible to the RTL expanders.
(define_insn "zero_extendv8qiv8hi2"
[(set (match_operand:V8HI 0 "register_operand" "=x,v")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #1 from Andrew Pinski ---
Again, this is not due to tree-ch at all. This is due to the code motion
passes move invariant load/stores out of the loop. Tree-ch pass just allows
those passes to work.
All three (gcse, tree pre and tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #2 from Adhemerval Zanella
---
(In reply to Andrew Pinski from comment #1)
> Again, this is not due to tree-ch at all. This is due to the code motion
> passes move invariant load/stores out of the loop. Tree-ch pass just allows
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #3 from Adhemerval Zanella
---
(In reply to Adhemerval Zanella from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Again, this is not due to tree-ch at all. This is due to the code motion
> > passes move invariant loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92050
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Mon Nov 25 14:33:32 2019
New Revision: 278689
URL: https://gcc.gnu.org/viewcvs?rev=278689&root=gcc&view=rev
Log:
Fortran] PR 92050 - fix ICE with -fcheck=all
Backport from mainl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #9 from Richard Biener ---
Thanks a lot. So besides the following mismatch for SLP
_24 = MEM[base: src_22(D), index: ivtmp.20_267, offset: 0B];
_97 = (unsigned char) _24;
_98 = (short unsigned int) _97;
_99 = BIT_FIELD_REF <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
Bug ID: 92661
Summary: [10 Regression] AIX bootstrap failure with
builtin-types.def change
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #7 from Tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
Bug ID: 92662
Summary: change in gcc 8 vs 9: call of overloaded
‘basic_string()’ is
ambiguous
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
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 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #2 from Jonathan Wakely ---
I'm pretty sure GCC 9 is correct. It started to be rejected with r269602:
PR c++/86521 - wrong overload resolution with ref-qualifiers.
Here we were wrongly treating binding a const lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Bug ID: 92663
Summary: Add __gcc_has_bug or __gcc_bug_fixed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #21 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #20)
> As of XCode 11.3beta, the contained SDK works OK:
>
> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
>
> We still have the underlying problems - w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #2 from David Edelsohn ---
A crude work-around to allow GCC to bootstrap and show the extent of the
problem, I need the following patches to comment out all decimal builtins.
Index: rs6000-call.c
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #22 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #21)
> (In reply to Iain Sandoe from comment #20)
> > As of XCode 11.3beta, the contained SDK works OK:
> >
> > https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #3 from David Edelsohn ---
An alternate work-around is
Index: tree.c
===
--- tree.c (revision 278691)
+++ tree.c (working copy)
@@ -10334,7 +10334,7 @@
uint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92664
Bug ID: 92664
Summary: Wrong .debug_line section information when compiling
stdin input with -g3
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #8 from Wilco ---
(In reply to David Binderman from comment #7)
> (In reply to David Brown from comment #0)
> > Surely it is time to make "-fno-common" the default, at least when a modern
> > C standard is specified indicating that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92641
--- Comment #3 from joseph at codesourcery dot com ---
The C front end explicitly tracks VLA size expressions in type names in
casts and ensures they are evaluated at an appropriate point using a
C_MAYBE_CONST_EXPR (which later turns into a COM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #9 from Jonathan Wakely ---
C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
imply -fcommon. It's just as bad in C89 as in later standards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #4 from joseph at codesourcery dot com ---
The design in the target-independent compiler is that the functions that
get called when processing builtins.def notice that the type involved is
error_mark_node (which in turn gets set whe
1 - 100 of 157 matches
Mail list logo
