https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970
Eyal Rozenberg changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Preliminary notes:
* This bug report stems from a StackOverflow question I asked:
http://stackoverflow.com/q/41407257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837
--- Comment #4 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #3)
> There's https://gcc.gnu.org/wiki/VerboseDiagnostics for a few such errors.
Well, that's a (tiny) start... however:
* I wouldn't have found it if you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837
--- Comment #7 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #5)
> Be the change that you want to see in the world.
>
> If you want this, make it happen.
Well, I already started by filing this bug, but point taken.
> (In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85837
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
> We try to improve error messages rather than list all of the error messages
> out.
But the listed error messages must balance readability/accessibility with
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Compiler error and warning messages are sometimes difficult to understand -
especially (but not exclusively) for novice developers. They are also typically
concise, and assume
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952
--- Comment #8 from Eyal Rozenberg ---
Andrew, Marc: Sorry for the mess with the other bug. If only Bugzilla had an
"edit comment" feature I wouldn't have opened this second one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84083
--- Comment #4 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #3)
> Yes, we don't currently implement restrict disambiguation for calls.
So, would that account for the different compilation result for test1() and
test2() in
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Consider the following code:
#include
void bar(char c);
void foo(const char* __restrict__ ss)
{
for (int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84083
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
> I think bar can still change the value of what ss points to.
What, you mean, by walking up the stack? I don't see why the compiler should
accommodate that by
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Consider the following code:
template
int foo(T* __restrict__ a)
{
int i; T val = 0;
for (i = 0; i < 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83951
--- Comment #1 from Eyal Rozenberg ---
Created attachment 43194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43194=edit
Source producing the optimized (int) and unopmitized (float) object code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83951
Eyal Rozenberg changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Created attachment 43195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43195=edit
Code exemplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952
--- Comment #1 from Eyal Rozenberg ---
Also seeing this with -O3 -fno-unroll-loops -fno-tree-loop-vectorize :
https://godbolt.org/g/r2v7X8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10624
Eyal Rozenberg changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87543
--- Comment #2 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #1)
> The issue at -O2 is etc.
That is one issue, but there is the question of the changes in behavior between
versions and when `-march` is used. I don't know if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925
Eyal Rozenberg changed:
What|Removed |Added
Version|unknown |9.0
--- Comment #1 from Eyal Rozenberg
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Have a look at this GodBolt example: https://gcc.godbolt.org/z/zR03rA
On one hand, we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87925
--- Comment #5 from Eyal Rozenberg ---
(In reply to Martin Liška from comment #3)
> Currently we only do switch -> balanced decision tree (read series of
> if-then-else statements). Well definitely a potentially enhancement,
> question is
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Brief illustration on GodBolt: https://godbolt.org/z/sQyNGA
A related question on StackOverflow:
https://stackoverflow.com/q
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
See: https://godbolt.org/z/tYn9SX
for a live example and comparison with clang
Se: https://stackoverflow.com/q/53628998
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Related StackOverflow question: https://stackoverflow.com/q/55464578/1593077
GodBolt example: https://godbolt.org/z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #5 from Eyal Rozenberg ---
(In reply to Jan Hubicka from comment #3)
> The reason why we do not devirtualize is that only information about Aint is
> the type of function parameter
"Only"? :-)
> and we do not believe it implies
: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
(This is all illustrated at: https://godbolt.org/z/nz2YXE )
Let us make our language C++17. Consider the following function:
int foo(const int* x, void g())
{
int result = *x;
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
Eyal Rozenberg changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #6 from Eyal Rozenberg ---
Thanks to a friendly StackOverflow user, I should also report that (about) the
same code produces the same compiler behavior disparity for proper C:
https://godbolt.org/z/kVYqp8
with the slight
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89567
--- Comment #2 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #1)
> You are looking for IPA DSE
I'm not a compiler expert and don't know what this means. Even literally, I
don't know what these acronyms stand for.
> by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89567
--- Comment #4 from Eyal Rozenberg ---
> In the first excample, the interproceudral constant propagation pass
> (IPA-CP) found that foo1 is so small that copying all of it might be
> worth not passing the unused argument and so it does, that is
: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
The issue is captured in the example here:
https://gcc.godbolt.org/z/_U4X80
The issue was first described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89479
--- Comment #5 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #4)
> exposing __restrict to the IL).
Is "IL" an acronym for "Intermediate Language"? Remember many bug
posters/readers are not GCC developers and don't know all
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
(based on this SE question: https://stackoverflow.com/q/56409551/1593077
and this GodBolt test case: https://godbolt.org/z/YNstQX
)
Consider
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
libiberty performs the demangling for c++filt, the most commonly-used (and
perhaps only?) tool for demangling C++ names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #8 from Eyal Rozenberg ---
(In reply to rguent...@suse.de from comment #5)
> int foo3()
> {
> struct { int x; int y; } s;
> s.x = 3;
> char c = 1;
> return replace_bytes_3(,c);
> }
>
> Coalescing successful!
> Merged into 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #10 from Eyal Rozenberg ---
(In reply to rguent...@suse.de from comment #9)
> You'd have to experiment with different GCC versions, but yes.
I was hoping for a more concrete suggestion (which works with multiple GCC
versions)...
NCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Example on GodBolt: https://godbolt.org/z/Q17L1u
Consider the following functions:
template
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #1 from Eyal Rozenberg ---
Can also reproduce this in C, with slightly different code:
int replace_bytes_3(int v1 ,char v2)
{
memcpy( (void*) (((char*))+1) , , sizeof(v2) );
return v1;
}
int foo3()
{
int x = 3;
char c =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #6 from Eyal Rozenberg ---
> Is the example from real-world code?
Yes. Example: Some machines support atomic instructions on aligned 32 bits or
on 64 bits, but not directly on 1, 2, 3, 5, 6 or 7 bytes. So in order to
atomically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924
--- Comment #9 from Eyal Rozenberg ---
(In reply to Jason Merrill from comment #8)
> I think if the object were not an actual Aint, performing the standard
> conversion to A* should be undefined, allowing the devirtualization. But
> I'm not
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Over the past several years, C++ has seen increased use of type deduction via
auto variables (C++11), auto return type (C++14), template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739
--- Comment #3 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #2)
> Oops, that was meant to be print_type()
Ok, that's a better kludge than mine - it doesn't have the more serious
shortcomings. That makes the motivation for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93739
--- Comment #4 from Eyal Rozenberg ---
(In reply to Eyal Rozenberg from comment #3)
A couple more points:
* The error I get (https://godbolt.org/z/5GpR2T) doesn't have the "your type
here" string.
* This forces you to define a variable you're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94559
Eyal Rozenberg changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
This test:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/testsuite/23_containers/array/requirements/constexpr_fill.cc
is named constexpr_fill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42633
Eyal Rozenberg changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Consider the following program:
#include
int main() {
unsigned x { 5 };
return (std
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
(Relevant Godbolt: https://godbolt.org/z/GygbjZ)
This is the first of two apparent bugs manifesting when compiling
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
(Relevant Godbolt: https://godbolt.org/z/GygbjZ)
This is the second of two apparent bugs, following bug 94293
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
--- Comment #1 from Eyal Rozenberg ---
Note:
The bugs also manifest with this simpler program:
#include
int bar() {
std::string second { "Hey... no small-string optimization for me please!"
};
return 123;
}
See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #2 from Eyal Rozenberg ---
Note:
The bugs also manifest with this slightly simpler program:
#include
int bar() {
std::string second { "Hey... no small-string optimization for me please!"
};
return 123;
}
See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #3 from Eyal Rozenberg ---
(In reply to Marc Glisse from comment #1)
You should probably post that comment on the second, related, bug 94294 - which
is about the fact that GCC keeps the new and delete. This one is strictly about
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
--- Comment #6 from Eyal Rozenberg ---
(In reply to Richard Biener from comment #5)
> DSE part ... DCE
DSE = Dead Statement Elimination? DCE = Dead Code Elimination?
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
Consider the following code:
class Base {
public:
virtual void vmethod();
};
class foo : public Base {
int x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96283
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
> (In reply to Eyal Rozenberg from comment #0)
> > I'm assuming the compiler provides the linker with enough information to
> > realize which virtual methods'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97274
--- Comment #2 from Eyal Rozenberg ---
(In reply to Jonathan Wakely from comment #1)
> The linker issues the warning, because the symbol in glibc is annotated to
> cause a warning. It has nothing to do with GCC.
Hmm. There's still a question of
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
If you use tmpnam, or std::tmpnam in C++, you get a linker (not compiler,
linker) warning:
/usr/bin/ld:
CMakeFiles/simpleDrvRuntimePTX.dir/modified_cuda_samples
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eyalroz at technion dot ac.il
Target Milestone: ---
(GodBolt example: https://godbolt.org/z/Kvan5c)
Consider the following code:
#include
constexpr std::string_view f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
--- Comment #3 from Eyal Rozenberg ---
> And, the runtime sanitization intentionally isn't heavily optimized away,
> because the intent is to detect when the code is invalid, so it can't e.g.
> optimize away those checks based on assumption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553
--- Comment #5 from Eyal Rozenberg ---
(In reply to Jakub Jelinek from comment #4)
> Depends on what you mean by properly. -O3 can be used with sanitization,
> but expecting the code to be optimized the same way as without sanitization
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
Eyal Rozenberg changed:
What|Removed |Added
CC||eyalroz at technion dot ac.il
60 matches
Mail list logo
