[Bug driver/87758] --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #4 from npl at chello dot at --- Is it really an excuse that it behaved like that forever? Given that -march and -sysroot (and spec files AFAIR) already affect the search paths, its not reasonable to expect -L wont work. I know that the linker is separate, but just adding the searchpath should be easy? If there is a new flag, please show in the returncode whether the library was found or not. If you want to inquire the linker, then maybe some "link-only" mode would be better, just invoking the linker with the usual flags and passing though additional commands.
[Bug libgcc/94220] New: libgcc FTB for ARM Thump when optimizing for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94220 Bug ID: 94220 Summary: libgcc FTB for ARM Thump when optimizing for size Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: npl at chello dot at CC: rearnsha at arm dot com Target Milestone: --- This issue was introduced with 6b9ce2b4eb49e3c930730c3721323349e2136b1a, the sections guarded with __OPTIMIZE_SIZE__ where apparently left out /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1139: Error: cannot honor width suffix -- `mul r2,r0' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1140: Error: cannot honor width suffix -- `sub r1,r1,r2' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1238: Error: MOV Rd, Rs with two low registers is not permitted on this architecture -- `mov work,dividend' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1239: Error: cannot honor width suffix -- `eor work,divisor' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1241: Error: cannot honor width suffix -- `mov curbit,#1' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1242: Error: cannot honor width suffix -- `mov result,#0' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1245: Error: cannot honor width suffix -- `neg divisor,divisor' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1249: Error: cannot honor width suffix -- `neg dividend,dividend' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1256: Error: MOV Rd, Rs with two low registers is not permitted on this architecture -- `mov r0,result' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1260: Error: cannot honor width suffix -- `neg r0,r0' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1351: Error: cannot honor width suffix -- `mul r2,r0' /tmp/b/.build/arm-none-eabi/src/gcc/libgcc/config/arm/lib1funcs.S:1352: Error: cannot honor width suffix -- `sub r1,r1,r2' (Fix is rather straightforward: add an 's' to every op)
[Bug driver/82715] New: support setting default for -pipe as configure option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82715 Bug ID: 82715 Summary: support setting default for -pipe as configure option Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: npl at chello dot at Target Milestone: --- Hello, I would like to be able to compile gcc with "-pipe" enabled by default. The advantages would be no trashing of the /tmp filesystem (and potentially a HDD behind it), no leftovers if gcc gets terminated, and potentially some performance benefit. AFAIK, the argument handling should be smart enough if -pipe should be dropped. Even if not, most of the times -pipe gives benefits and should be preferable. Some negative '-no-pipe' argument could override the default.
[Bug debug/58150] debug info about definition of enum class not emitted if the declaration was already used in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #2 from npl at chello dot at --- Created attachment 42381 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42381=edit another testcase I was generating a testcase before discovering this bug. Problem is the same: A class/struct using a prototyped, not yet defined "enum class" will prevent that debug information for this "enum class" to be emitted. Only if no class/struct uses a "enum class" before its defined, the debug info will be available. Affected: GCC 5.3.0, GCC 6.4.0, GCC 7.2.0 Please fix this, it really makes debugging a pain
[Bug tree-optimization/50417] regression: memcpy with known alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417 --- Comment #25 from npl at chello dot at --- Yes, that works fine. I just meant to say it needs more work than casting to a type with less alignment, and unless explicitly marked with this pragma you can expect a compiler to access like the (deduced) type was properly aligned.
[Bug tree-optimization/50417] regression: memcpy with known alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
--- Comment #22 from npl at chello dot at ---
(In reply to Richard Biener from comment #21)
> (In reply to Georg-Johann Lay from comment #18)
> > (In reply to rguent...@suse.de from comment #12)
> > > On Fri, 8 Jul 2016, olegendo at gcc dot gnu.org wrote:
> > >
> > > > void test (const int *a, int *b)
> > > > {
> > > > a[100] = 1;
> > > > b[200] = 2;
> > > >
> > > > std::memcpy ((char *)b, (char *)a, t);
> > > > }
> > > >
> > > > where a[100] and b[200] both would result in 32 bit accesses, not 4x1
> > > > byte or
> > > > something, because the base pointer is assumed to be int aligned.
> > >
> > > No, because the access is performed as 'int'.
> > >
> > > > Why should memcpy be any different?
> > >
> > > Because the memcpy stmt doesn't constitute a memory access but a function
> > > call.
> >
> > What about a new command option like -fassume-aligned-xxx that's off per
> > default?
> >
> > The user could assert that when she is using memcpy (and friends) with a
> > pointer of a specific type, then that also asserts that the data behind the
> > pointer is appropriately aligned and may be accessed accordingly.
>
> But if you do
>
> void copy (int *d, int *s)
> {
> memcpy ((char *)d, (char *)s, 4);
> }
>
> then you will get aligned accesses because all the middle-end sees is
>
> mempcy (d, s, 4);
Same thing happens already if you do this:
int d, s;
mempcy ((char *), (char *), 4);
Its also generally quite hard to force the compiler to do less-aligned
accesses, and I haven`t seen this "solution" anywhere. (Probably because it
doesn`t work on any current compiler)
> so as I said elsewhere the only way to reliably implement deriving alignment
> from pointer types is by the frontends inserting __builtin_assume_aligned
> calls before they possibly stripped any conversions.
>
> Yes, if we simply say we strictly follow C11 6.3.2.3/7 we can do that
> using a simple flag. But we won't get the optimization reliably because
> of the above issue for the variant with char * parameters and int * casts.
And you shouldn`t get the optimization in this case. Casting char* to int* is
non-standard, the assume_aligned builtin is a good fit for that non-standard
stuff IMHO.
> You could call that flag -fstrict-alignment (though maybe that would be
> confusing to people familiar with GCC internals STRICT_ALIGNMENT target
> macro). A simple implementation could be in get_pointer_alignment_1,
> wrapping it with a function that inspects TYPE_ALIGN (TREE_TYPE (TREE_TYPE
> (exp)) and uses that if it trumps the wrapped fn return values. But I
> expect much undesired fallout from such a change.
The internals are above my head, but in regards to fallout the same thing could
(has) be said for -fstrict-aliasing. Im a victim myself, and am suffering from
a paranoia where I have to replace pointer-accesses with memcpy =)
(In reply to Richard Biener from comment #19)
> (In reply to npl from comment #17)
> > I got interrupted by a colleague at work, part 2 of the ramblings...
> >
> > Everything you could argue against memcpy beeing replaced by simpler
> > instructions, doesnt change that the same issue persists with the
> > __builtin_memcpy function, which is explicitely saying you want the
> > optimizations.
> >
> > A pointer to a uint32 can be assumed to be proper aligned, CREATING such a
> > pointer thats not aligned is already undefined behaviour by the standard
> > (the compiler could zero out bits for example). I dont think that what
> > happens afterwards with something that shouldn`t exist in the first place is
> > an argument against optimizing proper code.
> >
> > Further, I lack a consistent way of dealing with potential aliasing
> > pointers. Using memcpy seems the sanest way, simply because its standards
> > compliant, supported everywhere and your code wont mysteriously break once
> > you use LTO or higher optimization settings.
> > Compilers can reliably detect this and replace memcpy since years (ignoring
> > this issue, which I would consider a bug), so there is no draw back. Its a
> > feature common pretty much everywhere, and a valid recommendation in many
> > discussions related to the topic.
> >
> > Consider the example below for illustration, FIXEDMEMCPY is how the plain
> > memcpy should work and already does work for archs with unaligned access.
> > (I had planned to post the code for 32bit x86, but the assembly is rather
> > ugly, a
[Bug tree-optimization/50417] regression: memcpy with known alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
--- Comment #17 from npl at chello dot at ---
I got interrupted by a colleague at work, part 2 of the ramblings...
Everything you could argue against memcpy beeing replaced by simpler
instructions, doesnt change that the same issue persists with the
__builtin_memcpy function, which is explicitely saying you want the
optimizations.
A pointer to a uint32 can be assumed to be proper aligned, CREATING such a
pointer thats not aligned is already undefined behaviour by the standard (the
compiler could zero out bits for example). I dont think that what happens
afterwards with something that shouldn`t exist in the first place is an
argument against optimizing proper code.
Further, I lack a consistent way of dealing with potential aliasing pointers.
Using memcpy seems the sanest way, simply because its standards compliant,
supported everywhere and your code wont mysteriously break once you use LTO or
higher optimization settings.
Compilers can reliably detect this and replace memcpy since years (ignoring
this issue, which I would consider a bug), so there is no draw back. Its a
feature common pretty much everywhere, and a valid recommendation in many
discussions related to the topic.
Consider the example below for illustration, FIXEDMEMCPY is how the plain
memcpy should work and already does work for archs with unaligned access.
(I had planned to post the code for 32bit x86, but the assembly is rather ugly,
amd64 would work with "unsigned long" and "unsigned long long").
I already ran in such issues, when different software components define their
own fixedwidth types. Its a practical issue where pointing to paragraphs of the
standard dont help, unless you provide a proper solution with it. The
FIXEDMEMCPY hack is fine for gcc but compilerspecific.
In short:
* Optimizing memcpy to simple instructions is a reality and expected, the
behaviour (slow code) on arm (and other archs with req. alignment) is a
unwelcome oddity
* memcpy is one of the few ways to deal with aliasing, and the most standards
compliant. (theres unions too, but thats not standards compliant)
* I dont see a problem in replacing standard functions (and __builtin_memcpy
has the same issue)
* I dont see a problem in expecting a correctly aligned pointer, and doing
undefined behaviour if the pointer could cause undefined behaviour.
typedef unsigned uint32_t;
typedef unsigned long uint32_alt;
_Static_assert(sizeof(uint32_t) == sizeof(uint32_alt), "you picked a bad
architecture or typedefs for this example");
#define FIXEDMEMCPY(a, b, s) __builtin_memcpy(__builtin_assume_aligned(a,
__alignof__(*a)), __builtin_assume_aligned(b, __alignof__(*b)), s)
unsigned breakme(uint32_t *ptr, uint32_alt *ptr2, uint32_t a)
{
/* normally in different compilation units, but LTO doesnt care */
*ptr = 0;
*ptr2 = a;
return *ptr;
}
unsigned fixme(uint32_t *ptr, uint32_alt *ptr2, uint32_t a)
{
/* fixes aliasing, but should be as fast as simple accesses */
uint32_t val = 0;
FIXEDMEMCPY(ptr, , 4);
FIXEDMEMCPY(ptr2 , , 4);
uint32_t val2;
FIXEDMEMCPY(, ptr, 4);
return val2;
}
:
0: e3a03000mov r3, #0
4: e5803000str r3, [r0]
8: e1a3mov r0, r3 // Oops: retval = 0
c: e5812000str r2, [r1]
10: e12fff1ebx lr
0014 :
14: e3a03000mov r3, #0
18: e5803000str r3, [r0]
1c: e5812000str r2, [r1]
20: e590ldr r0, [r0] // The load thats missing above
24: e24dd010sub sp, sp, #16 // Time for another
28: e28dd010add sp, sp, #16 // Bugreport ?
2c: e12fff1ebx lr
[Bug tree-optimization/50417] regression: memcpy with known alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
--- Comment #16 from npl at chello dot at ---
rguenther: Funny enough, I am using memcpy because thats the only standard
conform way to move data around that might be aliased. And I use this often to
parse binary streams from a network.
I think you are missing some key points, first that gcc readily replaces
functions it knows - which can be disabled at will. On x86, for all those
samples the call WILL BE replaced. (And in C++, RVO is explicitly allowed for
example)
So its pointless to discuss whether or not gcc should provide builtins (atleast
in the context of this bug). Instead talk about the replacing feature that
seems to work inconsistent / suboptimal.
One more sample to demonstrate this (all compiled with O2):
#include
int foo_ptr(const int *s)
{
/* nope */
int v;
memcpy(, s, sizeof(v));
return v;
}
int foo_ref(const int )
{
/* nope */
int v;
memcpy(, , sizeof(v));
return v;
}
int foo_refloc(const int )
{
/* This actually works */
int b = s;
int v;
memcpy(, , sizeof(v));
return v;
}
int foo_badalias(const char *s)
{
/* Nope, but then THIS shouldnt be be replaced by a aligned load */
int v;
memcpy(, (int *)s, sizeof(v));
return v;
}
int foo_badalias2(const char *s)
{
/* That works, but is undefined behaviour (casting from a pointer with
less alignment)! */
int v = *(int *)s;
return v;
}
[Bug tree-optimization/50417] regression: memcpy with known alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
npl at chello dot at changed:
What|Removed |Added
CC||npl at chello dot at
--- Comment #7 from npl at chello dot at ---
This seems to affect even the most trivial cases. I ran the following code witn
arm gcc 4.8.4, 4.9.2 and 5.3.0:
#include
#include
uint32_t foo_noalign(const uint32_t *s) {
uint32_t v;
memcpy(, s, sizeof(v));
return v;
}
uint32_t foo(const uint32_t *s) {
uint32_t v;
memcpy(, __builtin_assume_aligned(s, 4), sizeof(v));
return v;
}
Which generates the following code:
:
0: e92d4007push{r0, r1, r2, lr}
4: e3a02004mov r2, #4
8: e1a01000mov r1, r0
c: e08d0002add r0, sp, r2
10: ebfebl 0
14: e59d0004ldr r0, [sp, #4]
18: e28dd00cadd sp, sp, #12
1c: e49de004pop {lr}; (ldr lr, [sp], #4)
20: e12fff1ebx lr
0024 :
24: e590ldr r0, [r0]
28: e12fff1ebx lr
Thats really, really bad. clang has no problems generating the optimal code.
[Bug c/68657] [6 Regression] "gcc -Werror=sign-conversion test.i" shows invalid: -Wsign-conversion is not an option that controls warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #9 from npl at chello dot at --- I am using gcc 6.1 and I have the same problem with disabling -Wpsabi echo '#pragma GCC diagnostic ignored "-Wpsabi"' >test.c gcc -c test.c test.c:1:32: warning: '-Wpsabi' is not an option that controls warnings [-Wpragmas] #pragma GCC diagnostic ignored "-Wpsabi" ^
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #17 from npl at chello dot at --- Hi, so if I understand it right, the access fault itself isnt fixed, but if I use ABI Version = 9 it wont occur with this code? Should I open a separate Bug for the unaligned access issue?
[Bug c++/66216] New: Defaulted Operators and contructors not working with aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66216
Bug ID: 66216
Summary: Defaulted Operators and contructors not working with
aligned attribute
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: npl at chello dot at
Target Milestone: ---
The code below will not compile, faulting with defaulted declaration 'xx' does
not match expected signature.
This behaviour is in any gcc version from 4.7 - 5
// g++ -std=c++11 -c testalign.cpp
class CMymy
{
unsigned char _a;
unsigned char _b;
public:
constexpr CMymy() : _a(), _b() {}
constexpr CMymy(const CMymy ) = default;
CMymy operator=(const CMymy ) = default;
} __attribute__((aligned(2)));
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #3 from npl at chello dot at --- I just checked the alignment of nullptr, and here seems to be the issue: the size of 4, while the alignment is 1. This will result in unaligned access should a nullptr be stored (storing a nullptr probably is a really useless thing, but it seems to happen) static_assert(std::alignment_ofdecltype(nullptr)::value == 4, oops);
[Bug c++/65945] ARM: unaligned access when stroing nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #1 from npl at chello dot at --- Created attachment 35430 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35430action=edit disassembly showing the issue The issue is the line dc: e50b3019str r3, [fp, #-25] ; 0xffe7
[Bug c++/65945] New: ARM: unaligned access when stroing nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
Bug ID: 65945
Summary: ARM: unaligned access when stroing nullptr
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: npl at chello dot at
Target Milestone: ---
Created attachment 35429
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35429action=edit
code causing the issue
Hello,
the attachedcode produces an unaligned access for arm, on the production code I
ran into this issue with versions 5.1, 4.9.2, 4.8.4. This reduced testcase
doesnt produce the issue with 5.1, but for 4.9.2 and 4.8.4.
The issue seems to be the line
constexpr inline_type bool operator ==(bitmask X, decltype(nullptr)) \
{ return X == bitmask(); }
aparrently gcc converts stores the given parameter on the frame without caring
for alignment (str r3, [fp, #-25]). changing the type to unsigned seems
to fix this
Commandline to reproduce:
arm-none-eabi-g++ -std=c++11 -O0 -c unalignedgcc.cpp
[Bug c++/65945] ARM: unaligned access when stroing nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #2 from npl at chello dot at --- Well, gcc 5.1 seems to reproduceable aswell, I just looked at the wrong line. There are 3 stores of the implicitely converted nullptr, gcc 4.8.4, gcc 4.9.2 and gcc 5.1 all produce one unaligned store - just in different places
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #5 from npl at chello dot at --- making nullptr_t similar to void* would sound very reasonable to me. I tested clang and it seems to behave that way. Whatever the C++ ABI group comes up with, the unaligned accesses have to be fixed. This was really annoying to track down, as the stores will only be generated without optimizations - in other words I was searching for a completely different bug. I searched the bug database and supposedly throwing and catching nullptr`s is something legal. So you will have to correctly align it anyway, even if its arguable if nullptrs should ever be explicitly stored.
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #6 from npl at chello dot at --- btw... there seems to be a logical fallacy in the way gcc produces stores anyway. if a type has size 4 and alignment 1 (like a struct with 4 chars), shouldn`t the compiler generate byte-writes? Just curious if there could be a more generic bug hidden, which is triggered by my testcase (which can be fixed whit a bigger alignof(nullptr)) but might be triggered in other circumstances aswell.
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #8 from npl at chello dot at ---
@Andrew Pinski: The code in question was compiled for arm4t.
The toolchain is not configured for arm7, but has a multilib-configuration for
arm4/armv5te/thumb. No defaults where touched in any way, correct unaligned
load/stores are generated otherwise and __ARM_FEATURE_UNALIGNED is NOT defined.
Further I tested the code below and the gcc will generate a per-byte-copy:
-
#pragma pack(1)
struct CPacked
{
unsigned char m_EvilEpsilon;
unsigned m_Data;
};
void testaligned(CPacked *pPacked)
{
pPacked-m_Data = 0;
}
-
I tested almost the same thing with nullptr, also results in a per-byte-copy:
-
struct CNullpointer
{
unsigned char m_EvilEpsilon;
decltype(nullptr) m_Data;
};
void testnull(CNullpointer *pPacked)
{
pPacked-m_Data = 0;
}
-
To me that raises the following points:
*) nullptr_t in an struct will generate the correct code (per-byte-copy)
*) nullptr_t when flushed to the stackframe will write a word without adhering
to alignment restrictions.
Since I doubt there is special handling for nullptr_t for flushing to the
stackframe, this seems like a lingering issue that is hard to reproduce. Even
more so since development and testing nowadays seems focused on platforms which
will allow or emulate unaligned accesses.
maybe if you create a struct of 4 chars with a constexpr constructor that takes
an int you will run in the same issue. fixing nullptr_t alignment might just
hide the issue
[Bug c/65377] [5.0 Regression] cpp attribute check ala clang fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377 npl at chello dot at changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from npl at chello dot at --- 1) It simply shouldnt fail. 2) this is a generic header for C and C++. __has_cpp_attribute(clang::fallthrough) should resolve to 0 and not fail. This is a bug in gcc, unless you can explain why it shouldnt resolve to 0.
[Bug c/65377] New: [5.0 Regression] cpp attribute check ala clang fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
Bug ID: 65377
Summary: [5.0 Regression] cpp attribute check ala clang fails
to compile
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: npl at chello dot at
The following code fails to compile with gcc-5-20150301, gcc 4.8.4 and 4.9.2
are fine.
The command used is simply gcc test.c
#ifndef __has_cpp_attribute // Optional of course.
# define __has_cpp_attribute(x) 0 // Compatibility with non-clang compilers.
#endif
#if __has_cpp_attribute(clang::fallthrough) || (defined(__clang__)
__clang_major__ = 4 || (__clang_major__ == 3 __clang_minor__ = 3))
# define FALLTHROUGH [[clang::fallthrough]];
#else
# define FALLTHROUGH
#endif
int main()
{
}
Error Message is:
test.c:5:30: error: missing ')' after __has_attribute
#if __has_cpp_attribute(clang::fallthrough) || (defined(__clang__)
__clang_major__ = 4 || (__clang_major__ == 3 __clang_minor__ = 3))
^
test.c:5:31: error: ':' without preceding '?'
#if __has_cpp_attribute(clang::fallthrough) || (defined(__clang__)
__clang_major__ = 4 || (__clang_major__ == 3 __clang_minor__ = 3))
^
[Bug c/65377] [5.0 Regression] cpp attribute check ala clang fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377 --- Comment #6 from npl at chello dot at --- (In reply to npl from comment #3) 1) It simply shouldnt fail. 2) this is a generic header for C and C++. __has_cpp_attribute(clang::fallthrough) should resolve to 0 and not fail. This is a bug in gcc, unless you can explain why it shouldnt resolve to 0. I think gcc should simply ignore the __has_cpp_attribute macro, unless it does compile C++ code? if I use other names than __has_cpp_attribute it compiles. I will put some C++ guards around this code, but I still think this is a bug? (And I am compiling with Clang 3.4, but this doesnt support the feature check)
[Bug c/65377] [5.0 Regression] cpp attribute check ala clang fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377 --- Comment #8 from npl at chello dot at --- This (and the Iso recommendation) doesnt answer the question whether the __has_cpp_attribute macro should be defined for C sources either (it seems illogical to me). Guess its undefined and not a bug, I wont bother you anymore =)
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #10 from npl at chello dot at --- Hi, thanks for the fix, any chance of adding this to 4.9 and 4.8 aswell?
[Bug lto/58528] lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528 npl at chello dot at changed: What|Removed |Added CC||npl at chello dot at --- Comment #9 from npl at chello dot at --- I get this issue too, but cant provide sources. The program compiles if -g0 is used. Happens with gcc 4.8.2 and gcc 4.8.3. lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478 0x821c8c8 build_abbrev_table /tmp/toolchain-make/build/gcc-4.8.2/gcc/dwarf2out.c:7478 0x821c733 build_abbrev_table /tmp/toolchain-make/build/gcc-4.8.2/gcc/dwarf2out.c:7535 0x821e19b output_comp_unit /tmp/toolchain-make/build/gcc-4.8.2/gcc/dwarf2out.c:8608 0x8237fa0 dwarf2out_finish /tmp/toolchain-make/build/gcc-4.8.2/gcc/dwarf2out.c:23557 Target: arm-none-eabi Configured with: /tmp/toolchain-make/build/gcc-4.8.2/configure --prefix=/opt/imx28-48v1 --target=arm-none-eabi --enable-languages=c,c++ --disable-libstdcxx-verbose --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-multilib --disable-shared --disable-nls --with-system-zlib --enable-tls --with-gnu-as --with-gnu-ld --enable-lto --with-newlib --with-gmp=/tmp/toolchain-make/build/ggcnativebuild/gmp-5.1.3 --with-mpfr=/tmp/toolchain-make/build/ggcnativebuild/mpfr-3.1.2 --with-mpc=/tmp/toolchain-make/build/ggcnativebuild/mpc-1.0.2 --with-cloog=/tmp/toolchain-make/build/ggcnativebuild/cloog-0.18.0 --with-isl=/tmp/toolchain-make/build/ggcnativebuild/isl-0.11.1 --with-host-libstdcxx='-Wl,-Bstatic,/usr/lib/gcc/i486-linux-gnu/4.7/libstdc++.a,/usr/lib/gcc/i486-linux-gnu/4.7/libsupc++.a,-Bdynamic -lm' Thread model: single gcc version 4.8.2 (GCC)
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #4 from npl at chello dot at --- I just found the similar entry on launchpad. I have to recall this from memory, as its been a long time since I played around with it. The issue of repeating entries occurs if you have a function wihout stack-unwinding information. These are as far as I know: * .cantunwind in asm, probably plain asm too * C compiled compiled without flags to generate unwind tables * C++ compiled function with noexcept Further, the compiled code behaves right when exceptions are thrown (std::terminate), so the tables and generated code should be fine. The issue should thus be in libgcc`s implementation of the _Unwind_Backtrace function.
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
--- Comment #2 from npl at chello dot at ---
I cant easily make a simple reproducible testcase as this is a custom realtime
OS for a very specific CPU. And I can only test this example next week at work
where I have hardware to run it.
And I certainly wasnt talking about debugging with gdb (which uses some rather
advanced heuristics AFAIK), but the library funtions within libgcc (unwind.h
header). I reworked your example to show the issue:
#include unwind.h
#include iostream
_Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
{
void *ip = (void *)_Unwind_GetIP(context);
/* I have a check here to test if the ip is the same as last time, else this
would be called endlessly */
std::cout Address: ip std::endl;
return _URC_NO_REASON;
}
void bar()
{
std::cout This is in bar std::endl;
_Unwind_Backtrace((_Unwind_Trace_Fn)trace_func, nullptr);
}
void foo() noexcept
{
bar();
}
int main()
{
foo();
return 0;
}
[Bug libstdc++/59987] New: [C++11]: Missing ios_base::hexfloat format specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59987 Bug ID: 59987 Summary: [C++11]: Missing ios_base::hexfloat format specifier Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: npl at chello dot at The specifier for hexadecimal floats is missing: http://www.cplusplus.com/reference/ios/hexfloat/ I suppose the parsing of this format isnt working either (only tested this with gcc 4.7, but there doesnt seem to be any changes). stringstream instream(0x1.0624dd2f1a9fcp-10); double val; instream val; // should be 0.001
[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56728 --- Comment #3 from npl at chello dot at 2013-04-04 09:13:16 UTC --- (In reply to comment #2) Fixed for 4.8.1. Is it already in trunk? Fixed the ICE or disallowing the wrong constexpr - I guess I have a few of these?
[Bug libgcc/56846] New: _Unwind_Backtrace on ARM and noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 Bug #: 56846 Summary: _Unwind_Backtrace on ARM and noexcept Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at I want to inquire about the feasibility of using _Unwind_Backtrace on ARM, particularly in combination with the noexcept keyword. Since the backtrace depends on the unwind information, it seems the _Unwind_Backtrace breaks down when encountering noexcept functions. Whats even worse is, that instead of just stopping, _Unwind_Backtrace will just infinitely report the last context (unless the the callback tells to stop). So there are two points I guess, first that the _Unwind_Backtrace should stop when it cant proceed further instead of looping forever. I suppose thats a bug. Then I`d ask if its somehow possible to still backtrace through noexcept functions, perhaps with a compiler switch that still generates the necessary unwind tables and/or manual adjustment to the personality routine. (gdb can generate the traces... so I guess it must be possible) I am using an arm-none-eabi toolchain, of version 4.7.2. Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/opt/hipase-imx28-v0/libexec/gcc/arm-none-eabi/4.7.2/lto-wrapper Target: arm-none-eabi Configured with: /opt/hipase-imx28-v0/src/gcc-4.7.2/configure --prefix=/opt/hipase-imx28-v0 --target=arm-none-eabi --enable-languages=c,c++ --disable-libstdcxx-verbose --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-multilib --disable-shared --disable-nls --with-system-zlib --enable-tls --enable-gold --with-gnu-as --with-gnu-ld --enable-lto --with-newlib --with-gmp=/home/tcbuild/toolchain-make/build/ggcnativebuild/gmp-5.0.5 --with-mpfr=/home/tcbuild/toolchain-make/build/ggcnativebuild/mpfr-3.1.1 --with-mpc=/home/tcbuild/toolchain-make/build/ggcnativebuild/mpc-1.0.1 --with-cloog=/home/tcbuild/toolchain-make/build/ggcnativebuild/cloog-ppl-0.15.11 --with-ppl=/home/tcbuild/toolchain-make/build/ggcnativebuild/ppl-0.11 --with-host-libstdcxx='-Wl,-Bstatic,/usr/lib/gcc/i486-linux-gnu/4.4.5/libstdc++.a,/usr/lib/gcc/i486-linux-gnu/4.4.5/libsupc++.a,-Bdynamic -lm' Thread model: single gcc version 4.7.2 (GCC)
[Bug c++/56762] New: too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 Bug #: 56762 Summary: too aggressive optimization or missing warnings Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at Created attachment 29743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29743 code describing the issue Alternatively this could be just me misunderstanding C++. But the issue is that I have an object created on the stack and I would expect it to survive until it goes out of scope. Now I understand that I probably used it the wrong way by giving it a temporary when it needed a reference to something more solid, but I would expect an error message in this case. Please look at the provided code, which compiles without error/warning. the exchange function wont have any calls to lock/unlock. tested with gcc 4.7.2 + 4.8.0
[Bug c++/56762] too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 --- Comment #2 from npl at chello dot at 2013-03-28 13:38:01 UTC --- Oh how I hate this rule. Thanks for the info and sorry for the invalid report.
[Bug c++/56728] New: ICE using constexpr initialization and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56728 Bug #: 56728 Summary: ICE using constexpr initialization and arrays Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at Created attachment 29722 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29722 code to raise the ICE gcc 4.8.0 raises an ICE when fed with the provided code, while gcc 4.7.2 has no problems. removing either of the constexpr fixes the issue, and one of them probably shouldnt pass as constexpr in the first place (Im not really adept at interpreting the official C++11 standard but AFAIR reinterpret casts arent allowed?) internal compiler error: in gimple_expand_cfg, at cfgexpand.c:4575 -- used gcc: Using built-in specs. COLLECT_GCC=./tc/bin/arm-none-eabi-g++ COLLECT_LTO_WRAPPER=/opt/tc48/libexec/gcc/arm-none-eabi/4.8.0/lto-wrapper Target: arm-none-eabi Configured with: /opt/tc48/src/gcc-4.8.0/configure --prefix=/opt/tc48 --target=arm-none-eabi --enable-languages=c,c++ --disable-libstdcxx-verbose --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-multilib --disable-shared --disable-nls --with-system-zlib --enable-tls --enable-gold --with-gnu-as --with-gnu-ld --enable-lto --with-newlib --with-gmp=/home/tcbuild/toolchain-make/build/ggcnativebuild/gmp-5.1.1 --with-mpfr=/home/tcbuild/toolchain-make/build/ggcnativebuild/mpfr-3.1.2 --with-mpc=/home/tcbuild/toolchain-make/build/ggcnativebuild/mpc-1.0.1 --with-cloog=/home/tcbuild/toolchain-make/build/ggcnativebuild/cloog-0.18.0 --with-isl=/home/tcbuild/toolchain-make/build/ggcnativebuild/isl-0.11.1 --with-host-libstdcxx='-Wl,-Bstatic,/usr/lib/gcc/i486-linux-gnu/4.4.5/libstdc++.a,/usr/lib/gcc/i486-linux-gnu/4.4.5/libsupc++.a,-Bdynamic -lm' Thread model: single gcc version 4.8.0 (GCC)
[Bug libstdc++/56677] New: [ratio] : ratio_multiply, ratio_divide, etc results doesnt verify as __is_ratio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56677 Bug #: 56677 Summary: [ratio] : ratio_multiply, ratio_divide, etc results doesnt verify as __is_ratio Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at within chrono there is a test for template parameters if they classify as ratios: __is_ratio this test only works if the type is constructed as ratio, but the arithmetic functions on ratio ratio_multiply, ratio_divide, .. dont generate the result this way. Here is a little programm to illustrate the issue: -- #include ratio #include chrono typedef std::ratio_dividestd::ratio1, std::ratio1 ratii1; typedef std::ratioratii1::num,ratii1::den ratii2; std::chrono::durationunsigned long, ratii1 d1; // compile time check raises error std::chrono::durationunsigned long, ratii2 d2; // works fine. -- the solution would be either to make the __is_ratio smarter or, just generate results like I did with ratii2.
[Bug libstdc++/56677] [ratio] : ratio_multiply, ratio_divide, etc results doesnt verify as __is_ratio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56677 --- Comment #3 from npl at chello dot at 2013-03-21 14:38:48 UTC --- Thanks, this did not occur to me. Still, wouldnt it be relatively easy to adopt the __is_ratio function to check for the ::type instead?
[Bug libstdc++/56002] [C++11] allow generic locks to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 --- Comment #3 from npl at chello dot at 2013-01-17 20:43:35 UTC --- great, response looks already more promising than my other gcc patches/requests. Any chance this will find its way into 4.7.3?
[Bug libstdc++/56002] New: [mutex] allow generic classes to be used without requiring plattform support for threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56002 Bug #: 56002 Summary: [mutex] allow generic classes to be used without requiring plattform support for threads Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at Created attachment 29179 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29179 patch for mutex. diffed against 4.7.2 I am using gcc libstdc++ on a plattform that isnt natively supported and thus thread-functionality is not available from libstdc++. However I would like to be able to still use std::lock_guard, std::unique_lock, std::lock with my own mutex-classes. There ist no technical reason to prevent use of those generic classes and functions which are deliberately designed to work with custom implementations. ---mutex like it is now (all-or-nothing): #if HAS_GCC_THREADS mutexes definiton generic stuff like defer_lock_t,lock_guard, unique_lock, lock once_flag #endif ---mutex like it should be: #if HAS_GCC_THREADS mutexes definiton #endif generic stuff like defer_lock_t,lock_guard, unique_lock, lock #if HAS_GCC_THREADS once_flag #endif
[Bug c++/55879] [C++11] nested constexpr Initialisation raises internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55879 --- Comment #2 from npl at chello dot at 2013-01-08 19:30:29 UTC --- (In reply to comment #1) The problem also occurs for gcc 4.8.0 20121209 (experimental). Let me remark that according to C++11 the variable s_Memmap could not be used in constant expressions, because it contains an (effective) reinterpret_cast, which is not allowed in this context. If I understand you right, then you mean that the s_Memmap is not an constexpr array. As far as I understand this is not an issue that schould prevent compiling - I believe constexpr arrays are valid and different to const arrays? The former should not compile with this initializer. Also this variable is an linkervariable in my project, and I dont think gcc could constexpr it... even if I might be able to do away with the cast with something like extern C const unsigned _lnkDDRRAM[]; btw here is my error output for 4.7.2: nestedconstexpr.cpp:35:1: in constexpr expansion of ‘CNested(CAddress(1107296256u))’ nestedconstexpr.cpp:22:26: in constexpr expansion of ‘((CNested*)this)-CNested::m_PrimaryBlock.CAddress::CAddress((* primary))’ nestedconstexpr.cpp:35:1: internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:7435
[Bug c++/55879] New: [C++11][constexpr] nested constexpr Initialisation raises internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55879 Bug #: 55879 Summary: [C++11][constexpr] nested constexpr Initialisation raises internal compiler error Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at Created attachment 29084 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29084 code to raise the error Compiling the added code results in an internal compiler error, I tested this with GCC 4.6.3 and 4.7.2, both fail at different lines though. Some notes: for 4.7.2: *) I tested using a defaulted copy-constructor, this fixes the issue *) removing the constexpr fixes the issue for 4.6.3: *) I havent tested the provided code itself (have no access to 4.6.3 right now), I used slightly bigger version of the code. Im hopefull it still causes trouble. *) the important part is to use an external variable but have an additional entry in the array with an constant I dint provide a preprocessed source because I hope this is a sufficiently small piece to reproduce the error easily. Since this seems a rather fragile issue right now I guess it would be a good idea to create some bigger tests and check other gcc versions aswell - thats the reason I have code to break both versions in one file instead of simplifying it further. ---Command used (4.7.2/4.6.3 respectively): g++ -std=c++11 nestedconstexpr.cpp g++ -std=c++09 nestedconstexpr.cpp ---Compiler version: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-4)
[Bug target/46453] MIPS backend is not using special instructions for __builtin_bswap32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46453 --- Comment #1 from npl at chello dot at 2010-11-13 22:41:08 UTC --- Created attachment 22388 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22388 Partial patch inplementing 32 and 64 bit bswaps. diffed against gcc 4.5.1 Well, I went ahead and wrote a patch that adds support for the 32 and 64 bit bswap-builtins. Im not sure if this is the best way to do it and I dont know enough to tackle the 16bit bswaps.
[Bug target/46453] New: MIPS backend is not using special instructions for __builtin_bswap32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46453
Summary: MIPS backend is not using special instructions for
__builtin_bswap32
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@chello.at
Host: i686
Target: mips-elf
Build: ../configure --disable-libssp --prefix=/usr/local
--target=mips-elf
MIPS32 Relase 2 introduced a special instruction called wsbh that can be used
for 32- and 16-bit byteswaps. However GCC never does produce this instruction.
all code-snippets are produced with -march=mips32r2 -O3 (which should enable
the wsbh, rotr and ins instructions and optimized code using them). the
assembly assumes big-endian endian.
* __builtin_bswap32:
eg. v0 = __builtin_bswap32(a0); should result in
wsbh v0, a0
rotr v0, v0, 16
* 16bit byteswaps:
similarly v0 = ((a0 8) | (a0 8)); (with a0,v0 being 16 bit uints)
should result in:
wsbh v0, a0
as it is now, the __builtin_bswap32 will always result in a function call
(already atleast 2 instructions) and the implementation which uses 9
instruction.
a 16bit bswap results in 4 instructions. So that would be nice savings
especially in the 32bit case
* Unaligned loads:
More unimportantly unaligned 16bit loads could be optimized a bit aswell if
the ins instruction is available:
--Code sample (unaligned 16bit load):
#pragma pack(push,1)
union Unaligned {
unsigned char c[2];
unsigned short u16;
};
#pragma pack(pop)
unsigned short readUnaligned16(const void *ptr) {
return ((const union Unaligned *)(ptr))-u16;
}
-- Code sample
results in this sequence:
# a0 = ptr, v0 = return value
lbuv0,0(a0)
lbuv1,1(a0)
sllv0,v0,0x8
orv0,v1,v0
better would be:
lbuv0,0(a0)
lbuv1,1(a0)
insv1,v0,8,8
Generating this sequences for unaligend 16bit loads would be a nice start. But
there could be generic optimizations with sequences of left-shift and or being
replaced with ins instructions, aslong it can be verified that registers have
enough explicitly zeroed bits so they dont overlap.
similarly right-shift and masking could be replaced by ext instructions. eg. v0
= ((a0 8) 0xFF) equals to ext v0,a0,8,8.
[Bug c/38836] New: Documentation for x86 builtins is outdated
The documentation for builtin functions need a serious overhaul, trying to use several builtins as documented will result in the linker complaining about missing functions. As reference (I`m not sure how accurate this is) take this post: http://www.mail-archive.com/g...@gcc.gnu.org/msg03309.html Also the correct alternative of using xmmintrin.h is mentioned nowhere in the documentation, neither the correct typedefs (or even which variation should be prefered). eg. defining v8qi as typedef uint_8 v8qi __attribute__ ((vector_size (8))); will result in errors with function requiring a 8*8 vector of integers. Its not obvious that you have to use typedef char v8qi __attribute__ ((vector_size (8))); instead -- Summary: Documentation for x86 builtins is outdated Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: npl at chello dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38836
