[Bug driver/93284] New: gcc -v --help emits some messages to stderr

: driver Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Target Milestone: --- Running gcc -v --help to get all of GCC's options produces output to both stdout and stderr. This causes problems when running that output through a pager, for instance

[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #5 from Josh Triplett --- (In reply to Martin Sebor from comment #4) > (In reply to Josh Triplett from comment #0) > > > > I'm willing to work on a patch for this. > > If there still is interest in this feature are you still interest

[Bug c/54162] Please accept static global anonymous unions or structs as an extension

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54162 --- Comment #5 from Josh Triplett --- Visual C (2017 at least), clang, and as far as I can tell, current GCC. I don't know at what point this started working, but it seems to work now.

[Bug c/79266] excessive compile time for large static array (-O1)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79266 --- Comment #1 from Josh Triplett --- Following up: it looks like gcc -O1 does eventually complete, after several minutes. -O3 is still running.

[Bug c/79266] New: excessive compile time for large static array (-O1)

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Target Milestone: --- Consider the following test case: int main(int argc, char *argv[]) { char *array[] = { #include "num_array.h" argv[0], }; int sum = 0;

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #21 from Josh Triplett --- (In reply to PaX Team from comment #20) > (In reply to Josh Triplett from comment #13) > > Note that in addition to complaining if *any* exit to the function doesn't > > have the correct "out" value, you als

[Bug tree-optimization/70731] With -Ofast, reorder floating-point and integer operands to minimize conversions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731 --- Comment #4 from Josh Triplett --- (In reply to Marc Glisse from comment #3) > (In reply to Josh Triplett from comment #2) > > That's a fair point. Perhaps it should go into a separate optimization > > option, then, though it still seems in t

[Bug tree-optimization/70731] With -Ofast, reorder floating-point and integer operands to minimize conversions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70731 --- Comment #2 from Josh Triplett --- (In reply to Marc Glisse from comment #1) > That... seems dangerous to me. With floats, unsafe operations tend to change > the low bits. With integers, an overflow gets the high bits wrong. If you > call test

[Bug c/70731] New: With -Ofast, reorder floating-point and integer operands to minimize conversions

Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Target Milestone: --- [Not sure if this goes in the 'c' component or some appropriate optimizer component.] Given options l

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #24 from Josh Triplett --- Also, even the documentation seems unfortunate: "In C++ this is normally not an error since const variables take the place of #defines in C++." Why would C code not do this too? The GCC documentation shoul

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 Josh Triplett changed: What|Removed |Added CC||josh at joshtriplett dot org

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #18 from Josh Triplett --- (In reply to PaX Team from comment #17) > (In reply to Josh Triplett from comment #16) > > (In reply to PaX Team from comment #14) > > > can you give me an example of this? > > > > Sparse warns if you can r

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #16 from Josh Triplett --- (In reply to PaX Team from comment #14) > (In reply to Josh Triplett from comment #13) > > This approach won't necessarily provide the "different contexts for basic > > block" warning that Sparse has, but I

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #13 from Josh Triplett --- (In reply to PaX Team from comment #12) > 2. as for my idea, it's simple: track the context via an artificially > injected local integer variable (one per context if you want context > sensitivity) and initi

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #11 from Josh Triplett --- (In reply to Tom Tromey from comment #10) > (In reply to Josh Triplett from comment #9) > > > > It might help to see exactly where __context__ is used in real code. > > > > A few patterns: > > Sorry, I wa

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #9 from Josh Triplett --- (In reply to Tom Tromey from comment #6) > (In reply to Josh Triplett from comment #4) > > Unfortunate, and I'd love to see GCC handle trailing attributes (does a bug > > already exist for that somewhere?), b

[Bug c/68524] New: Please support attributes between function definition and opening brace

: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Target Milestone: --- GCC supports placing attributes after the closing parenthesis of a function declaration and before the semicolon. However

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #8 from Josh Triplett --- (In reply to PaX Team from comment #5) > (In reply to Josh Triplett from comment #4) > > Could you represent __context__ as a new GCC builtin? Would that make this > > any easier? > > it can be a builtin or

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #4 from Josh Triplett --- (In reply to Tom Tromey from comment #3) > (In reply to Josh Triplett from comment #2) > > > > The attribute syntax in the test case doesn't work with gcc. The > > > attributes > > > on the function defini

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856 --- Comment #2 from Josh Triplett --- (In reply to Tom Tromey from comment #1) > Created attachment 36815 [details] > simple version in python > > This implements the basics of the checker using the gcc python plugin. Awesome! > A few notes on

[Bug c/66240] RFE: extend -falign-xyz syntax

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 --- Comment #3 from Josh Triplett --- (In reply to Denis Vlasenko from comment #2) > (In reply to Josh Triplett from comment #1) > > Another alternative discussed in that thread, which seems near-ideal: align > > functions to a given size (for in

[Bug c/66240] RFE: extend -falign-xyz syntax

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 Josh Triplett changed: What|Removed |Added CC||josh at joshtriplett dot org

[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #3 from Josh Triplett --- (In reply to Josh Triplett from comment #2) > One alternative implementation: if GCC supported a "property" attribute, > specifying (optional) functions to get or set the property (with > compile-time errors

[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #2 from Josh Triplett --- One alternative implementation: if GCC supported a "property" attribute, specifying (optional) functions to get or set the property (with compile-time errors if attempting to get/set a property for which the

[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #1 from Josh Triplett --- An additional corner case: a deadfield, even one that has a default value to allow reads of it to work rather than erroring out, must be an rvalue, so that attempts to take the address of it fail.

[Bug c/63480] New: -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org -Wmissing-field-initializers warns if a positional initializer does not initialize

[Bug c/63479] New: Compiler flag to zero structure padding

Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Many memory disclosure vulnerabilities occur due to uninitialized structure padding. For instance, if the kernel declares a structure, initializes its fields, and copies the entire structure to

[Bug c/62194] New: Add deadfield attribute to ignore initializers for a structure field

: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org This request is the result of a discussion at Kernel Summit 2014, about handling conditional code without massive transitions or excessive

[Bug c/62093] New: multi-argument section attribute for bss, rodata, data

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org The Linux kernel and similar use the section __attribute__ to place some data and code into sections like "init", which can be discarded from memory at some point, or "

[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 --- Comment #5 from Josh Triplett --- (In reply to Tom Tromey from comment #4) > Implemented on trunk. Thanks! Please consider including anonymous structs and unions in the test case as well: struct S { int a; union { int b;

[Bug middle-end/61677] False positive with -Wmaybe-uninitialized (test case included)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61677 Josh Triplett changed: What|Removed |Added Attachment #33055|0 |1 is obsolete|

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #27 from Josh Triplett --- (In reply to Tom Tromey from comment #21) > (In reply to Tom Tromey from comment #20) > > > BTW if you want to try it out I have a branch: > > https://github.com/tromey/gcc/tree/add-sparse-attributes > > T

[Bug c/61677] New: False positive with -Wmaybe-uninitialized (test case included)

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Created attachment 33055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33055&action=edit Test case for false positive in -Wmaybe-uninitialized W

[Bug target/60545] Please support the 64-bit Windows/EFI calling convention on x86-64 Linux/ELF

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60545 --- Comment #2 from Josh Triplett --- (In reply to Andrew Pinski from comment #1) > The attribute is ms_abi. It is documented in 4.4.0 and above. > > From GCC 4.5.0 docuemtnation: > http://gcc.gnu.org/onlinedocs/gcc-4.45.0/gcc/Function-Attribute

[Bug c/60660] alloca function for inlines that allocates on caller stack

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60660 --- Comment #4 from Josh Triplett --- (In reply to Andrew Pinski from comment #1) > This is much harder than you think really. since you have to move all the > arguments of the callee function That I'm aware of, but it should be less of an issue

[Bug c/60660] New: alloca function for inlines that allocates on caller stack

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org To implement certain helper functions, it would help greatly to have the ability to perform stack allocations in the parent function from an inline function. If

[Bug c/60545] New: Please support the 64-bit Windows/EFI calling convention on x86-64 Linux/ELF

: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org For code interoperating with Windows-compatible assembly routines, or for system code calling into EFI firmware, it would help if GCC natively

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #19 from Josh Triplett --- (In reply to Tom Tromey from comment #18) > (In reply to Tom Tromey from comment #17) > > It seems that "force" works on function parameters and casts > > but not direct assignments: > > It's also an error i

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #15 from Josh Triplett --- (In reply to Tom Tromey from comment #14) > (In reply to Josh Triplett from comment #11) > > Personally, I'd actually suggest merging the two in GCC, and always issuing > > both sets of warnings. I'd also su

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #13 from Josh Triplett --- (In reply to H. Peter Anvin from comment #8) > Arguably the *right* way to solve that would be to support __null for C as > well as for C++. __null or nullptr?

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #12 from Josh Triplett --- (In reply to Tom Tromey from comment #9) > (In reply to Josh Triplett from comment #7) > > > I can't think of a legitimate reason to have a null pointer constant in a > > non-zero address space; there's alre

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #11 from Josh Triplett --- (In reply to Tom Tromey from comment #10) > Relatedly, could you say what the option "-Wcast-to-as" provides > beyond the normal warnings about changing address spaces? > I wonder if this is something I shoul

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #7 from Josh Triplett --- (In reply to Tom Tromey from comment #6) > Null pointer constants are treated specially, which makes sense, > but only if they have type "void *" and are in address space 0. Otherwise, they're not a null poin

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #4 from Josh Triplett --- (In reply to Tom Tromey from comment #3) > I noticed this behavior and was wondering if it is intended: > > bapiya. cat /tmp/q.c > __attribute__((force)) int *p; > int q = *p; > bapiya. sparse -Wno-decl /tmp/

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 --- Comment #8 from Josh Triplett --- (In reply to Josh Triplett from comment #7) > (In reply to Josh Triplett from comment #4) > > Also note that arithmetic operations between a bitwise and a known-zero > > value do not warn. > > > > The warning

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 --- Comment #7 from Josh Triplett --- (In reply to Josh Triplett from comment #4) > Also note that arithmetic operations between a bitwise and a known-zero > value do not warn. > > The warning on ~ of a value smaller than int only occurs if the v

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 --- Comment #6 from Josh Triplett --- (In reply to Tom Tromey from comment #5) > (In reply to Josh Triplett from comment #4) > > Also note that arithmetic operations between a bitwise and a known-zero > > value do not warn. > > I'm curious about

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 --- Comment #4 from Josh Triplett --- Also note that arithmetic operations between a bitwise and a known-zero value do not warn. The warning on ~ of a value smaller than int only occurs if the value is not subsequently stuffed back into the same

[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 --- Comment #2 from Josh Triplett --- Very nice! Looks reasonable to me. I agree with making designated_init on a non-struct an error. Sparse tends to almost never mark anything as an error unless it mangles Sparse's internal state somehow, bec

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 --- Comment #1 from Josh Triplett --- Note in particular the bit about typedefs. Two identical declarations both using __attribute__((bitwise)) create two variables with different types, but two declarations both usin the same typedef declared wi

[Bug c/59856] New: Support sparse-style context checking, used to validate locking correctness

: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Created attachment 31866 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31866&action=edit Sparse test case for context checking The

[Bug c/59855] New: Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers

: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org Created attachment 31865 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31865&action=edit Sparse test c

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #2 from Josh Triplett --- Here's a test case from Sparse, demonstrating some tricky behavior of noderef: # define __A__attribute__((noderef)) struct x { int a; int b; }; struct y { int a[2]; }; static void h(void) {

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 Josh Triplett changed: What|Removed |Added CC||josh at joshtriplett dot org --- Comment

[Bug c/59708] clang-compatible checked arithmetic builtins

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #6 from Josh Triplett --- (In reply to jos...@codesourcery.com from comment #5) > See what I said in about > the issues with something type-generic regarding detecting overflow on > t

[Bug c/59708] clang-compatible checked arithmetic builtins

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 --- Comment #4 from Josh Triplett --- (In reply to Jakub Jelinek from comment #2) > Not sure I like their naming though, I'd say they should be type generic > builtins handled in the FEs depending on the first argument's type, so that > it works e

[Bug c/59708] New: clang-compatible checked arithmetic builtins

Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org It would be nice to have a set of builtins for arithmetic operations that check for overflow, ideally compatible with those available in clang; see http://clang.llvm.org/docs

[Bug c/57166] New: Manual no longer documents -Wmissing-noreturn alias for -Wsuggest-attribute=noreturn

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57166 Bug #: 57166 Summary: Manual no longer documents -Wmissing-noreturn alias for -Wsuggest-attribute=noreturn Classification: Unclassified Product: gcc Version: 4.7.2 S

[Bug c/54162] Please accept static global anonymous unions or structs as an extension

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54162 Josh Triplett changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug c/54162] New: Does not accept static global anonymous unions or structs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54162 Bug #: 54162 Summary: Does not accept static global anonymous unions or structs Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED

[Bug c/51437] GCC should warn on the use of reserved identifier/macro names

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #13 from Josh Triplett 2012-02-19 18:56:28 UTC --- (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (Some of the other reserved identifier categories, such as E[A-Z0-9].*, > > > is[a-z].*, to[a-

[Bug c/51437] GCC should warn on the use of reserved identifier/macro names

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #12 from Josh Triplett 2012-02-19 18:50:34 UTC --- (In reply to comment #10) > (In reply to comment #9) > > However, note that the standards also reserve various other classes of > > names, > > such as types ending in _t, for which G

[Bug c/51437] GCC should warn on the use of reserved identifier/macro names

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #9 from Josh Triplett 2012-02-19 06:29:27 UTC --- (In reply to comment #8) > You really do want to flag both definition and usage. For instance, there's > plenty of buggy software (especially GNU software like binutils) using __pid_t

[Bug c/51437] GCC should warn on the use of reserved identifier/macro names

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #7 from Josh Triplett 2012-02-19 04:41:59 UTC --- (In reply to comment #6) > I would greatly like to see this as well; actually I was just about to file a > duplicate report when I found this, as a result of finding "struct _Color" in

[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

--- Comment #5 from josh at joshtriplett dot org 2010-04-02 02:03 --- Created an attachment (id=20286) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20286&action=view) Original header file, for reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624

[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

--- Comment #4 from josh at joshtriplett dot org 2010-04-02 02:03 --- Created an attachment (id=20285) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20285&action=view) Second original source file, for reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624

[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

--- Comment #3 from josh at joshtriplett dot org 2010-04-02 02:03 --- Created an attachment (id=20284) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20284&action=view) First original source file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624

[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

--- Comment #2 from josh at joshtriplett dot org 2010-04-02 02:02 --- Created an attachment (id=20283) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20283&action=view) Second preprocessed file to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624

[Bug c/43624] Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

--- Comment #1 from josh at joshtriplett dot org 2010-04-02 02:02 --- Created an attachment (id=20282) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20282&action=view) First preprocessed file to reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624

[Bug c/43624] New: Bad code generation: introduces strict aliasing warnings and references to uninitialized memory

Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: josh at joshtriplett dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43624