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
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
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
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?
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
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?
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
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
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.
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?
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
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
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
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
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
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
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
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
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65377
npl at chello dot at changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution
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
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
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
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
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
++
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
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
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
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
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
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
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?
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
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, o
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
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
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
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
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
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
: 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
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
42 matches
Mail list logo
