https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98669
Bug ID: 98669
Summary: SIGSEGV on pc=0 in crypt() with -fsanitize=address
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667
--- Comment #2 from Andrew Pinski ---
Is this directly on a i486 box or VirtualBox? VirtualBox might have a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596
--- Comment #2 from Kito Cheng ---
Few years ago, Monk and me has write a very detailed cost model for nds32 port,
that way might able to fix the issue and further optimized for the code size
and performance, but...it need lots time to fine tune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
--- Comment #5 from Marek Polacek ---
A better one:
// PR c++/98646
// { dg-do compile }
// { dg-options "-Wnonnull" }
struct B {
void foo();
};
struct D : B {
void show();
};
void
D::show()
{
constexpr void *p = nullptr;
if (p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
--- Comment #4 from Marek Polacek ---
The reduced testcase is unfortunately overreduced :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
--- Comment #3 from Marek Polacek ---
Started with r11-1697.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98668
Bug ID: 98668
Summary: unused branch found in
gcc/passes.c:do_per_function_toporder
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98664
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-01-14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667
--- Comment #1 from Matthew Whitehead ---
Here is the full set of compiler flags used.
readelf --string-dump='.GCC.command.line' /usr/lib/debug/$( which eix ).debug
String dump of section '.GCC.command.line':
[ 0] -I .
[ 5] -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667
Bug ID: 98667
Summary: gcc generates endbr32 invalid opcode on -march=i486
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596
Jim Wilson changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
--- Comment #5 from charliepdts at gmx dot at ---
Hi Jakub, thanks for the detailed description and the insights as to the
assumptions that the compiler uses when optimizing code like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
Jeff Gilbert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
--- Comment #4 from Jonathan Wakely ---
Right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
--- Comment #3 from Jeff Gilbert ---
Ok, but this is ok, right?
const auto& i2 = f().i;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
--- Comment #2 from Jonathan Wakely ---
If you make everything constexpr then Clang will correctly diagnose the UB, but
GCC fails to:
constexpr int IntSize() { return sizeof(int); }
#include
// -
template
class Maybe {
bool mIsSome =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
--- Comment #1 from Jonathan Wakely ---
Not a bug. This is equivalent to:
struct X { int i; };
X f() { return { 0 }; }
const int& g(const X& x) { return x.i; }
int main()
{
const auto& i = g(f());
}
The temporary's lifetime is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #17 from Segher Boessenkool ---
(What i was referring to in Comment 4 was asm_operand_ok in recog.c --
it may need some surgery if we need to hook into that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
--- Comment #3 from charliepdts at gmx dot at ---
While I appreciate the anything can happen, what surprised us was the lack of
any kind of warning.
Does the compiler not notice the access outside the array in this case?
background: we are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
--- Comment #2 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:796ead19f85372e59217c9888db688a2fe11b54f
commit r11-6652-g796ead19f85372e59217c9888db688a2fe11b54f
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98665
Bug ID: 98665
Summary: lvalue ref lifetime extension missing for via
sub-object of temporary expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #9 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #16 from Segher Boessenkool ---
No, this cannot be fixed in this hook, or in any other hook. The compiler
can never see *at all* what instructions there are, the template is just a
piece of text to it (there could be assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98664
Bug ID: 98664
Summary: inconsistent --Wfree-nonheap-object for inlined calls
to system headers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545
--- Comment #3 from Marek Polacek ---
(In reply to Marek Polacek from comment #2)
> but I need to figure out how to test this.
[[gnu::used]] to actually emit the function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
Dávid Bolvanský changed:
What|Removed |Added
CC||david.bolvansky at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98663
Bug ID: 98663
Summary: gcc generates endless loop at -O2 or greater depending
on order of testExpression
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
--- Comment #2 from anlauf at gcc dot gnu.org ---
This has nothing to do with character at all. Same issue with:
program p
implicit none
type t
integer, allocatable :: x(n) ! { dg-error "must have a deferred shape" }
end type
end
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545
--- Comment #2 from Marek Polacek ---
Candidate fix:
--- a/gcc/cp/mangle.c
+++ b/gcc/cp/mangle.c
@@ -3349,7 +3349,8 @@ write_expression (tree expr)
else if (dependent_name (expr))
{
tree name = dependent_name (expr);
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98662
Bug ID: 98662
Summary: checking ICE in friend_accessible_p since r227023
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96691, which changed state.
Bug 96691 Summary: Failure to optimize bitwise not+or+xor with constants to
and+xor with bitwise not-ed constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
Bug 89891 depends on bug 78746, which changed state.
Bug 78746 Summary: charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 78746, which changed state.
Bug 78746 Summary: charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||error-recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661
Bug ID: 98661
Summary: Valgrind errors during error recovery of invalid
derived type declarations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #14 from Martin Sebor ---
Smallish test case independent of libstdc++ that reproduces both the false
positive (due to the missing aliasing constraint) and its absence (due to a
bug/limitation in tree_inlined_location). With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #13 from Jakub Jelinek ---
Note, it is important to be able for -g0 to be able to optimize as many BLOCKs
as possible especially for LTO memory consumptions, so it should be just the
BLOCKs at inline boundaries that could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
--- Comment #12 from Martin Sebor ---
(In reply to Jeffrey A. Law from comment #10)
> What about fixing the -g interaction? Much like how -g shouldn't affect
> code generation, it probably shouldn't be affecting warnings like this.
>
> There
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96691
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8fc183ccd0628465205b8a88c29ab69bfe74a08a
commit r11-6651-g8fc183ccd0628465205b8a88c29ab69bfe74a08a
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #8 from David Malcolm ---
Saving and restoring the uids fixes the issue, so I'm working on a patch to the
analyzer pass to do that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
--- Comment #12 from Matheus Izvekov ---
Thank you!!!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98660
Bug ID: 98660
Summary: -Wold-style-cast should not warn on casts that look
like (decltype(x))(x)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
--- Comment #19 from Paul Sokolovsky ---
Vladimir Makarov, Przemyslaw Wirkus: Thanks looking into this issue and fixing
it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96688
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
--- Comment #3 from Dávid Bolvanský ---
Yes, runtime check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
--- Comment #30 from anlauf at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #29)
> > There's no testcase named "pr78746.f90" in the testsuite.
>
> Ideed! My prx.f90 are in the test suite only when they are fixed.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463
--- Comment #8 from Jakub Jelinek ---
With the patch for C++14 and older the problem is that the empty base has no
FIELD_DECL in the RECORD_TYPE at all, so it then doesn't find anything.
So for the empty_base && lval case it might be better to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
--- Comment #29 from Dominique d'Humieres ---
> There's no testcase named "pr78746.f90" in the testsuite.
Ideed! My prx.f90 are in the test suite only when they are fixed.
Now my "pr78746.f90" is exactly charlen_03.f90.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
--- Comment #1 from Marek Polacek ---
This seems to work...
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -9279,4 +9279,14 @@ push_operator_bindings ()
}
}
+/* Wrapper around push_local_binding to push the bindings for
+ a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98657
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #28 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644
Patrick Palka changed:
What|Removed |Added
Known to work||9.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98659
Bug ID: 98659
Summary: [11 Regression] ICE tree check: expected tree that
contains ‘decl common’ structure, have ‘error_mark’ in
maybe_instantiate_noexcept, at cp/pt.c:25445 since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
--- Comment #10 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:283c218a4846075c549f0215d6883e577b26e845
commit r8-10726-g283c218a4846075c549f0215d6883e577b26e845
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481
--- Comment #13 from CVS Commits ---
The releases/gcc-8 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:283c218a4846075c549f0215d6883e577b26e845
commit r8-10726-g283c218a4846075c549f0215d6883e577b26e845
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641
--- Comment #8 from Alex Richardson
---
(In reply to Jakub Jelinek from comment #3)
> I guess I have big questions on what exactly will it do during constexpr
> evaluation - if it is on a pointer to object with certain alignment, for
> smaller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597
--- Comment #10 from Jakub Jelinek ---
BTW, I'm not convinced it is ok to use TREE_TYPE (TREE_TYPE arg)) in the !addr
case for anything at all even for warnings, as in GIMPLE pointer conversions
are useless and therefore it very well could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
--- Comment #9 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4aeae11db66c9bce0aadf447e6ff0776a97bfccf
commit r9-9180-g4aeae11db66c9bce0aadf447e6ff0776a97bfccf
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481
--- Comment #12 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4aeae11db66c9bce0aadf447e6ff0776a97bfccf
commit r9-9180-g4aeae11db66c9bce0aadf447e6ff0776a97bfccf
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98625
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from Nathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597
--- Comment #9 from Jakub Jelinek ---
That would be then following (though I didn't want to touch the rest of
print_mem_ref so the patch doesn't remember op anywhere and resets byte_off
too).
--- gcc/c-family/c-pretty-print.c.jj2021-01-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
--- Comment #1 from Dávid Bolvanský ---
ICC produces memcpy:
https://godbolt.org/z/oKxxTM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98638
--- Comment #6 from Martin Liška ---
I see a similar ICE happening in libretro-mame package where a PCH is used:
../../../../../src/emu/screen.h: In member function
'std::enable_if_t::supports_callback::value, void>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98496
--- Comment #11 from Svante Signell ---
ping?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98658
Bug ID: 98658
Summary: Loop idiom recognization for memcpy/memmove
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #26 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:285fa338b06b804e72997c4d876ecf08a9c083af
commit r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98597
--- Comment #8 from Jakub Jelinek ---
So, before starting to fix all the bugs in the print_mem_ref routine, I think
we should add something like:
--- gcc/c-family/c-pretty-print.c.jj2021-01-13 08:02:09.425498954 +0100
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 98626, which changed state.
Bug 98626 Summary: UBSAN: vec.h:591:30: runtime error: member access within
null pointer of type 'struct vec'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626
Nathan Sidwell changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98632
--- Comment #2 from tilps at hotmail dot com ---
*rough sketch*
class TaskConsumer {
void run() {
if (taken_count_.load(std::memory_order_acquire) <
task_count_.load(std::memory_order_acquire)) {
taken_count_.fetch_add(1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98626
--- Comment #2 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:11cbea852b0ae2b0f17a9caeaf6344d689231c2f
commit r11-6647-g11cbea852b0ae2b0f17a9caeaf6344d689231c2f
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8d3636923a309074eb19240ebaa30c1a0801eaaf
commit r10-9267-g8d3636923a309074eb19240ebaa30c1a0801eaaf
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481
--- Comment #11 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8d3636923a309074eb19240ebaa30c1a0801eaaf
commit r10-9267-g8d3636923a309074eb19240ebaa30c1a0801eaaf
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641
--- Comment #7 from Jakub Jelinek ---
(In reply to Alex Richardson from comment #5)
> extern int i;
> _Static_assert(__builtin_is_aligned(__builtin_assume_aligned(, 16), 8),
> "");
> generates an "alignment of the base pointee object (4 bytes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641
--- Comment #6 from Alex Richardson
---
(In reply to Jakub Jelinek from comment #3)
> assume_aligned is something different, I guess __builtin_is_aligned expands
> to an actual runtime check (perhaps optimized away if the pointer can't be
>
1 - 100 of 146 matches
Mail list logo
