https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919
--- Comment #1 from Freddie Chopin ---
More possibly imporant notes:
1. The warning appears only with -O1 or -O2, with 0, s, g or 3 the warning is
gone.
2. Adding -fsanitize=undefined to compiler invocation makes the warning go away
as well - no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Following code gives no warning with GCC 11.3 and earlier versions:
-- 8&l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86890
--- Comment #2 from Freddie Chopin ---
Prerequisites docs say "isl Library version 0.15 or later". Configure script
also accepts 0.20 just fine.
BTW - 0.19 builds and works OK.
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
When trying to build GCC 8.2.0 with isl 0.20, I see a lot (at least a few
dozens) of errors about undeclared functions, like:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8
ity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
According to https://en.cppreference.com/w/cpp/atomic/atomic std::atomic<>
should contain value_type and difference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739
Freddie Chopin changed:
What|Removed |Added
Attachment #44111|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85739
--- Comment #1 from Freddie Chopin ---
I'm currently in the process of reducing the test case with the wonderful tool
that I've found yesterday - C-Reduce (; I hope that I'll be able to upload
something short and generic (not requiring arm-none-e
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Created attachment 44111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44111&action=edit
preprocessed sour
: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Target: arm-none-eabi
This issue is inspired by following bug report for GAS
c
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Here's a minimal test case execut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82461
--- Comment #2 from Freddie Chopin ---
Any chance there is a patch for this problem that could be merged before 7.3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #6 from Freddie Chopin ---
The runtime checks are no good in deeply embedded (like a MCU)...
Anyway - would this behave the same if the values in `in[]` would NOT be known
at compile time? For example provided by user for each run of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #4 from Freddie Chopin ---
Would it be possible to have a warning with -Wall -Wextra when something like
that happens? I think this behaviour here is really strange and really
unexpected. In "real" programs I guess there are tons of s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #2 from Freddie Chopin ---
Indeed, reducing the values in `in[]` makes the code behave properly. But
anyway - how does this particular (minor) issue in the code affect a seemingly
unrelated loop? After all, this loop's variable - `b1`
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Example code:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
#include
#incl
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
I've posted this info to the gcc mailing list. Richard Biener suggested opening
a bug report, so he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80534
--- Comment #9 from Freddie Chopin ---
Patch above (applied to 7.0.1-RC-20170425) fixes the original issue which I
reported - the project builds fine and works correctly. The warnings
("dereferencing type-punned pointer will break strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80534
--- Comment #1 from Freddie Chopin ---
Created attachment 41276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41276&action=edit
preprocessed source which causes the problem - minimal version
OK, I've managed to narrow it down to a much sm
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Target: arm-none-eabi
Created attachment 41275
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80332
--- Comment #2 from Freddie Chopin ---
Same behaviour with gcc 7.0.1 20170409.
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
There is a base type with "__attribute__ ((deprecated))". If I create an alias
with "typedef",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66297
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #6 from Freddie Chopin ---
> On a newer Intel (or AMD) machine, add -march=naitve and you will
> see the same behavior.
You are right, adding that switch causes the assert to appear...
> VFMA is not just multiply and accumulate but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #4 from Freddie Chopin ---
Hello Andrew and thanks for your answer.
Generally I don't care about the sequence of operations or the exact
instructions that get generated, but in this case this default behaviour
produces invalid result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #2 from Freddie Chopin ---
Created attachment 40701
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40701&action=edit
assembly dump of valid version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79436
--- Comment #1 from Freddie Chopin ---
Created attachment 40700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40700&action=edit
assembly dump of invalid version
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Target: arm-none-eabi
Created attachment 40699
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40699&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824
--- Comment #5 from Freddie Chopin ---
Sure, more data points show that this is most likely a problem in a target
component, not in middle-end or c front-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78824
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904
--- Comment #9 from Freddie Chopin ---
Any chance for merging the fix to gcc-6 branch before gcc 6.3 would be
released?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904
--- Comment #7 from Freddie Chopin ---
Could this be also backported to the gcc-6 branch? I guess there will be 6.3
version (possibly before first 7.x version), so it would be nice to have this
patch there (;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907
--- Comment #1 from Freddie Chopin ---
Maybe it is important to add, that it doesn't matter whether
SomeClass::someFunction() is const or not - it behaves identically in both
cases.
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Target: x86_64-pc-linux-gnu, arm-none-eabi
Failing test case:
--- 8&
NCONFIRMED
Severity: critical
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Target: arm-none-eabi
In some very specific cases frame pointer can thrash c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71113
--- Comment #1 from Freddie Chopin ---
BTW, I've come to the code as above from a slightly different scenario -
initially I tried using references, but it was failing (placed in RAM, not in
flash) no matter what I did. Now I think that the two pr
NCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Take a look at following test case:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64514
--- Comment #1 from Freddie Chopin ---
The question at stackoverflow has an answer with much simpler test-case which
also shows the problem. http://stackoverflow.com/a/27810002/157344
--- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 ---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
The test code below works perfectly fine with GCC 4.8 (and 4.7):
--- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 ---
#i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
--- Comment #7 from Freddie Chopin ---
Great (; Do you have some timeline? I'm not trying to rush you - I'm just
working on a project in which this feature would be beneficial, so I'm
wondering whether I should wait a bit (this particular require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55409
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126
--- Comment #4 from Freddie Chopin 2013-02-13
07:29:23 UTC ---
Created attachment 29430
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29430
simple fail case
I think I have an even simplier test case, I guess it's the same problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #9 from Freddie Chopin 2013-02-12
15:31:46 UTC ---
(In reply to comment #8)
> Perhaps because you are the reporter and reporter is always CCed on the PRs,
> no
> matter if on CC or not?
If you remove me from the CC list I w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #5 from Freddie Chopin 2013-02-12
09:07:37 UTC ---
Yes, sorry about the fuzz with the testcase and thx for confirming.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Freddie Chopin changed:
What|Removed |Added
CC||freddie_chopin at op dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
--- Comment #2 from Freddie Chopin 2013-02-12
07:14:17 UTC ---
Created attachment 29421
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29421
failing test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56291
Bug #: 56291
Summary: ICE for C++11 in output_constructor_regular_field, at
varasm.c:4821
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
--- Comment #6 from Freddie Chopin 2012-12-21
07:08:59 UTC ---
(In reply to comment #4)
> Former is better on code size, latter wins on performance. Hopefully this
> explains everything.
Indeed, it's clear now. Thank you for your time!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
--- Comment #3 from Freddie Chopin 2012-12-20
17:07:47 UTC ---
Indeed that's a trivial case, but other - useful - cases also show strange
behavior which I cannot clearly explain, so while we're at it I'd be grateful
for some explanation...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
--- Comment #1 from Freddie Chopin 2012-12-20
15:23:25 UTC ---
BTW - it seems that optimization settings don't make any difference here - the
code below was compiled with -Os, on all other levels (1,2,3) the assembly
looks like this:
00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55757
Bug #: 55757
Summary: Suboptimal interrupt prologue/epilogue for ARMv7-M
(Cortex-M3)
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONF
52 matches
Mail list logo
