http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157
Bug #: 57157
Summary: Poor optimization of portable rotate idiom
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nisse at lysator dot liu.se
Created attachment 31918
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31918action=edit
Example program
Some background:
In GNU nettle, I use function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48568
Summary: Missing documentation for __attribute__((visibility
(protected))) on variables.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
--- Comment #12 from Niels Möller ---
It would be nice with some way to annotate the asm to have it treated in the
same as a possibly trapping division or pointer dereference.
E.g., adding "trap" to the clobber list, somewhat similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
Niels Möller changed:
What|Removed |Added
CC||nisse at lysator dot liu.se
--- Comment
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nisse at lysator dot liu.se
Target Milestone: ---
The naïve understanding of unique_ptr, is that it is handled the same
way as a raw pointer, with just
* additional compile time safety checks, and
* automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #2 from Niels Möller ---
(In reply to Jonathan Wakely from comment #1)
> The ABI dictates the calling conventions and there's certainly nothing that
> libstdc++ can do about it.
My impression was that C++ ABI is under the control of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #5 from Niels Möller ---
(In reply to Jonathan Wakely from comment #4)
> Why wouldn't you take unique_ptr&& instead of passing by value?
Because passing unique_ptr (and other move-only types) by value seems to be the
mainstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #10 from Niels Möller ---
I was just made aware of this paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1863r0.pdf
arguing that C++ standards community and implementers ought to decide on how to
prioritize C++
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nisse at lysator dot liu.se
Target Milestone: ---
Consider the following program:
---8<--
/* To avoid including limits.h */
#d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #32 from Niels Möller ---
I've checked out the gcc sources, to see if I can understand how to move the
warning around. The example input I'm looking at now is
unsigned
shift_dead (unsigned x)
{
if (0)
return x >> 32;
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94773
Niels Möller changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
Niels Möller changed:
What|Removed |Added
CC||nisse at lysator dot liu.se
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #41 from Niels Möller ---
(In reply to Manuel López-Ibáñez from comment #39)
> You can easily find which pass does something by dumping (-ftree-dump-*)
> all of them and comparing them.
It's -ftree-dump-all, and also -fdump-passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #37 from Niels Möller ---
(In reply to Manuel López-Ibáñez from comment #35)
> There is no such place. Dead code is identified in the middle-end and by
> then, there is no parse tree, only GIMPLE and SSA:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #36 from Niels Möller ---
(In reply to Martin Sebor from comment #34)
>
> The front ends can eliminate simple subexpressions (as in '0 ? x >> 32 : x
> >> 1') but they don't do the same for statements. Moving the warning from
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #38 from Niels Möller ---
Just a brief update.
1. Tried adding fprintf warnings to c_gimplify_expr (btw, what's the right way
to display a pretty warning with line numbers etc in later passes?). But it
seems that's too early, I still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #42 from Niels Möller ---
Created attachment 48678
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48678=edit
Add a new pass for emitting the warning (not working)
Since adding a new pass seems to be the right way, I've given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91356
--- Comment #11 from Niels Möller ---
Here's a bit more docs on using std::unique_ptr [[clang::trivial_abi]] with
clang and its C++ library.
https://libcxx.llvm.org//DesignDocs/UniquePtrTrivialAbi.html
As for "No, it needs co-operation between
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: nisse at lysator dot liu.se
Target Milestone: ---
Hi,
my project includes C and assembly for a couple of different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868
--- Comment #13 from Niels Möller ---
(In reply to Peter Bergner from comment #11)
> This is clearly a stage1 patch, so we'll wait until
> then before submitting it.
I'm not that familiar with gcc development procedures. Do I understand you
21 matches
Mail list logo
