https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Bug ID: 88690
Summary: internal compiler error: in
output_constructor_regular_field, at varasm.c:5031
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #1 from Eugene ---
Created attachment 45338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45338&action=edit
Zipped prepocessed file causing internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #2 from Eugene ---
Created attachment 45339
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45339&action=edit
Output of arm-none-eabi-gcc.exe -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88677
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #6 from Martin Liška ---
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |7.5
Summary|[sparc64] Problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88594
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 4 09:00:05 2019
New Revision: 267571
URL: https://gcc.gnu.org/viewcvs?rev=267571&root=gcc&view=rev
Log:
PR target/88594
* config/i386/i386.c (ix86_expand_divmod_l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #4 from Martin Liška ---
Reduced test-case:
$ cat services.ii
typedef char a;
using b = int;
class c {
b f{5};
};
class d {
int e{};
};
class C {
C() = delete;
};
class i : public d, public C {};
template using g = i;
enum { h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #5 from Eugene ---
Meanwhile I have found exact line that causing this issue:
services.ii@35563:
characteristic_inst(const characteristic_inst&) = delete;
When commented out, compilation pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #6 from Martin Liška ---
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |7.5
Summary|internal compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88594
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
--- Comment #2 from Antony Lewis ---
I think the individual elements are correct, it's the array indexing operations
that are wrong (this is clearer in the longer example; looks a like wrong
stride). E.g. printing this in the main program after c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #8 from Jakub Jelinek ---
Further reduced (-std=c++17):
struct A { int a = 1; };
struct B { int b = 0; };
struct C { C () = delete; };
struct D : public B, public C {};
struct E : A { D f; } g{};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88686
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88691
Bug ID: 88691
Summary: Add support for -fuse-ld=lld (https://lld.llvm.org/)
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
Jakub Jelinek changed:
What|Removed |Added
Target|arm-linux-gnueabihf |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88692
Bug ID: 88692
Summary: Spurious "redundant move in return statement"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88676
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
Dominique d'Humieres changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48543
--- Comment #8 from Thomas Koenig ---
Author: tkoenig
Date: Fri Jan 4 10:42:12 2019
New Revision: 267572
URL: https://gcc.gnu.org/viewcvs?rev=267572&root=gcc&view=rev
Log:
2019-01-04 Thomas Koenig
PR fortran/48543
* gfortran.dg/cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342
--- Comment #23 from Dominique d'Humieres ---
Still present, see
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg00318.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
Thomas Koenig changed:
What|Removed |Added
Target||x86-64-pc-cygwin
--- Comment #7 from Tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52491
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88567
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 45340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45340&action=edit
minimal reproducer
I've reduced the file as much as I could.
ICEs for aarch64 with -Ofast -march=a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #9 from Uroš Bizjak ---
Created attachment 45341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45341&action=edit
Somehow reduced testcase
The testcase can be compiled with a cross to --target=x86_64-w64-mingw32:
cc1 -O3 -marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
--- Comment #10 from Uroš Bizjak ---
As mentioned in comment #5, this is due to r266345 (AKA fix for PR84877). It
looks that the change now emits RTL sequence outside of BB.
This is what can be seen at the end of .reload dump:
...
(code_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88331
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88691
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #12 from Uroš Bizjak ---
See also PR88331.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88522
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88689
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88693
Bug ID: 88693
Summary: Wrong code since r263511
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88693
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88694
Bug ID: 88694
Summary: constexpr isn't captured correctly in lambda
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88694
--- Comment #1 from Amos Bird ---
Created attachment 45343
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45343&action=edit
the ii file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88694
--- Comment #2 from Amos Bird ---
Currently by introducing a `auto local_i = decltype(i)();` can workaround this.
#include
#include
#include
template
constexpr void static_for_impl(Func&& f, std::integer_sequence) {
(f(std::integral_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87276
--- Comment #6 from Vincent Lefèvre ---
Note concerning the tests: in Debian, as of gcc-snapshot 1:20181209-1, MPFR is
no longer affected (and I've checked that the failure is still reproducible
with gcc-snapshot 1:20181127-1). But the testcase i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88676
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #23 from Gary Mills ---
> It's not Solaris, first of all. Solaris is a closed system once again. It's
> illumos, which is derived from Opensolaris. These are the two as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88690
--- Comment #10 from Eugene ---
(In reply to Jakub Jelinek from comment #8)
> Further reduced (-std=c++17):
> struct A { int a = 1; };
> struct B { int b = 0; };
> struct C { C () = delete; };
> struct D : public B, public C {};
> struct E : A {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #7 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #6)
> Is anyone going to test the #c5 patch and submit if it passes?
We won't test it. We no longer use LCM to insert vxorps since LCM generates
vxorps inside the loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #8 from Jeffrey A. Law ---
That's an indication you've likely done something wrong with your local
properties HJ. LCM inherently also does LICM since LICM is just a special case
of PRE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #9 from H.J. Lu ---
(In reply to Jeffrey A. Law from comment #8)
> That's an indication you've likely done something wrong with your local
> properties HJ. LCM inherently also does LICM since LICM is just a special
> case of PRE.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #10 from Jakub Jelinek ---
So, is this actually a regression? I.e. is there a testcase that fails with
trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88567
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88593
--- Comment #11 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #10)
> So, is this actually a regression? I.e. is there a testcase that fails with
> trunk?
I believe this issue is latent on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88693
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88567
--- Comment #4 from rsandifo at gcc dot gnu.org
---
BTW, turns out that this is the same ICE as gcc.dg/vect/pr63379.c,
which was on my list of things to look at in stage 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
Bug ID: 88695
Summary: Accepts invalid program with incompatible function
types.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
--- Comment #4 from Steve Kargl ---
On Fri, Jan 04, 2019 at 09:40:52AM +, antony at cosmologist dot info wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
>
> --- Comment #2 from Antony Lewis ---
> I think the individual elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #1 from Anders Granlund ---
Correction:
The second standard reference should be 6.7.6.3/15 and not 6.7.3/15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #2 from Jonathan Wakely ---
See PR 64526 and DR 317.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83243
Eric Gallager changed:
What|Removed |Added
CC||dilyan.palauzov at aegee dot
org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88691
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64526
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #9 from ktkachov at gcc dot gnu.org ---
For context, this is the hot loop in 557.xz_r from SPEC2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88567
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Created attachment 45345
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45345&action=edit
Candidate patch
I'll test the attached over the weekend. Seems to pass initial spot-testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88693
--- Comment #2 from Jakub Jelinek ---
Created attachment 45346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45346&action=edit
gcc9-pr88693.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #10 from Jakub Jelinek ---
If the compiler knew say from PGO that pos is usually a multiple of certain
power of two and that the loop usually iterates many times (I guess the latter
can be determined from comparing the bb count of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #10 from Sam Tebbs ---
Author: samtebbs
Date: Fri Jan 4 16:26:38 2019
New Revision: 267579
URL: https://gcc.gnu.org/viewcvs?rev=267579&root=gcc&view=rev
Log:
[PATCH][GCC][Aarch64] Change expected bfxil count in
gcc.target/aarch64/co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88027
acsawdey at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #9 from Eric Botcazou ---
> There are similar problems for other TLS models which can be relaxed, but
> even worse than this, local dynamic uses a sethi/xor for the offset from the
> defining module's block to load a signed 32-bit val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #11 from Wilco ---
(In reply to Jakub Jelinek from comment #10)
> If the compiler knew say from PGO that pos is usually a multiple of certain
> power of two and that the loop usually iterates many times (I guess the
> latter can be de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #10 from Eric Botcazou ---
> So, if the above formulas are incorrect, relaxation is required in all cases.
...are correct...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88363
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87964
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #3 from Anders Granlund ---
Yes, the type of f does have a prototype.
That fact is however not relevant here.
Note that I'm not making any calls to f here. I am only using f in a way
that requires its type to be compatible wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #4 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #2)
> See PR 64526 and DR 317.
(Forgot to reply instead of adding an additional comment)
Yes, the type of f does have a prototype.
That fact is however not rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88647
--- Comment #4 from Anders Granlund ---
(In reply to jos...@codesourcery.com from comment #1)
> 6.3.2.1#2 (conversion of lvalues to rvalues): "If the lvalue has an
> incomplete type and does not have array type, the behavior is undefined.".
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88694
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568
--- Comment #4 from joseph at codesourcery dot com ---
On Fri, 4 Jan 2019, jakub at gcc dot gnu.org wrote:
> Joseph, is there any meaning for DECL_EXTERNAL & TREE_STATIC, or is that
> invalid flag combination? If the latter, we should go with t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #5 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #4)
>
> If the test doesn't fail if it fails to load libcurl (and doesn't get
> stuck), it is fine too.
> If it fails if it is missing, yeah, something like a tcl proced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
--- Comment #5 from joseph at codesourcery dot com ---
It's DR#316 that's relevant here (where the committee agreed with my
interpretation that implies this example is valid, and reiterated their
intent not to fix issues with unprototyped funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
[...]
> I may try a build on Solaris 10 with the snv_121 assembler myself.
> The sparc machine is busy un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #11 from James Clarke ---
(In reply to Eric Botcazou from comment #9)
> > There are similar problems for other TLS models which can be relaxed, but
> > even worse than this, local dynamic uses a sethi/xor for the offset from the
> > d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431
--- Comment #10 from Jonathan Wakely ---
Maybe like this:
--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -439,7 +439,7 @@ namespace __variant
constexpr bool
_M_valid() const noexcept
{
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #12 from Eric Botcazou ---
(> So, as far as I see it, we have two choices:
>
> 1. Disable all X -> LE relaxations in the linker. Works, but then gives
> suboptimal performance if some code linked into an executable is built with
> -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517
--- Comment #3 from Jonathan Wakely ---
(In reply to Xiaoyi Zhang from comment #0)
> 2. Conversion assignment operator=(T&&)
> According to [variant.assign] 23.7.3.3 (11.3): if
> is_nothrow_constructible == false &&
> is_nothrow_move_constructibl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88696
Bug ID: 88696
Summary: Power VSX builtins missing vmuluwm / vector int
vec_mul (vector int, vector int);
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88640
--- Comment #4 from Jakub Jelinek ---
-Ofast -fsignaling-nans is a really weirdo combination of options, it says that
NaNs aren't honored, but sNaNs are, so in this case it folds a _7 = 1.0 * _2
that is marked that could throw into just _7 = _2;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88653
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88697
Bug ID: 88697
Summary: New test case gcc.target/powerpc/pr88457.c in r267307
fails because of glibc requirement
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88695
Anders Granlund changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
Bug ID: 88698
Summary: Relax generic vector conversions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87364
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88698
--- Comment #1 from Marc Glisse ---
It would help if you could write some (very short) functions illustrating the
behavior you are requesting. "convert", "compatible" all depend about the
context in which they appear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88699
Bug ID: 88699
Summary: tree check fail: expected function_decl, have
using_decl in add_method, at cp/class.c:1137
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88699
--- Comment #1 from David Binderman ---
Bug seems to start someplace between revision 266950 and 267100.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #28 from Florian Weimer ---
It seems that using symbol aliases (via .symver) in conjunction with LTO and a
version script which has a local: * clause causes the LTO plugin to assume that
the aliased function definitions are not (exter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88188
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88699
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88699
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |9.0
Summary|tree check fail:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654
--- Comment #6 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #4)
>
> My i686-linux bootstraps are done through a couple of executable scripts in
> ~/hbin directory on x86_64-linux:
> for i in ~/hbin/*; do echo ===$i===; cat $i; do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88638
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88700
Bug ID: 88700
Summary: C11 Annex K builtins
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassi
1 - 100 of 143 matches
Mail list logo
