https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #8 from Matthijs van Duin ---
(In reply to Matthijs van Duin from comment #4)
> return std::pair{ ++i, ++i }.first;
My bad! This isn't an exhibit of the bug. I simply forgot that std::pair is not
really a struct, and this isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #25 from Matthijs van Duin ---
I wasn't referring to the warnings though but incorrect code generation. Since
is exhibited by pretty trivial test cases (testsuite/g++.dg/cpp0x/initlist86.C
confirms that { i++, i++ } works but the anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89695
--- Comment #4 from Matthijs van Duin ---
(In reply to Jonathan Wakely from comment #3)
> I believe this is required by the ABI for trivially copyable types.
I don't see how that's possible, the callee can't tell the difference.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijsvanduin at gmail dot com
Target Milestone: ---
On ARM, when extracting an element from a float32x2_t expression, i.e.:
float32x2_t v = (...);
float v0 = v[0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijsvanduin at gmail dot com
Target Milestone: ---
When a function that has a non-reference parameter of a trivially copyable
class-type is invoked with a prvalue expression as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89695
Matthijs van Duin changed:
What|Removed |Added
Summary|inappropriate copying of|unexpected copying of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #7 from Matthijs van Duin ---
Ah! I should have checked the actual tests of 51253 before calling it a
regression, apologies. I just kinda assumed that these simple cases would be
covered by the work done back then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
--- Comment #9 from Matthijs van Duin ---
I can still reproduce the same test case with: arm-linux-gnueabihf-gcc-8
(Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk revision 257435]
-mfloat-abi=hard is implicit for arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
--- Comment #13 from Matthijs van Duin ---
In case it's of interest, I did a quick benchmark of my testcase executed in a
loop on a cortex-a8:
Without neon:
12 instructions/iteration
14 cycles/iteration
With neon:
14 instructions/it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82989
--- Comment #15 from Matthijs van Duin ---
(In reply to Wilco from comment #14)
> Yes on older cores it can be a bad idea to allow accidental use of Neon
> instructions. The simplest workaround is to switch off Neon, just use
> -mfpu=vfp.
Sure,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83028
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061
--- Comment #2 from Matthijs van Duin ---
> void foo( bool ok ) {
^constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijsvanduin at gmail dot com
Target Milestone: ---
The following function:
void foo( uint64_t *a ) {
*a += *a >> 32;
}
compiled with arm-linux-gnueabihf-gcc -mcpu=cortex-a8 -mfpu=neon -O2
produc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49526
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: matthijsvanduin at gmail dot com
Target Milestone: ---
GCC 5.2.1 rejects the following code (with -std=gnu++11 or later):
constexpr uint16_t bswap16( uint16_t x ) {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #10 from Matthijs van Duin ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Matthijs van Duin from comment #4)
> > Also bug 65866 exists for the warning itself.
>
> I think this is an exact dup.
>
> *** This bug has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #12 from Matthijs van Duin ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to Matthijs van Duin from comment #10)
> > I'm assuming this means a new bug should be opened
> > about the wrong code generation?
>
> Yes plea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70796
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102942
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89695
--- Comment #5 from Matthijs van Duin ---
So for reference, the Itanium C++ ABI says:
"A type which is trivial for the purposes of the ABI will be passed and
returned according to the rules of the base C ABI, e.g. in registers; often
this has th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100801
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83234
Matthijs van Duin changed:
What|Removed |Added
CC||matthijsvanduin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65866
--- Comment #8 from Matthijs van Duin ---
(In reply to Yuxuan Shui from comment #7)
> IIUC now wrong codegen has all been fixed? so the only thing left should be
> the diagnostic bug?
It seems so yes, the combined testcase in Bug 70796 comment 5
31 matches
Mail list logo
