https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #6 from Stas Sergeev ---
I think the fix (of at least 1 problem here)
would be to move this line:
https://code.woboq.org/gcc/libsanitizer/asan/asan_thread.cc.html#109
upwards, before this:
https://code.woboq.org/gcc/libsanitizer/asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #7 from Stas Sergeev ---
Created attachment 52221
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52221&action=edit
test case
This is a reproducer for both problems.
$ cc -Wall -o bug -ggdb3 -fsanitize=address bug.c -O1
to see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #9 from Stas Sergeev ---
(In reply to Martin Liška from comment #8)
> Please report the problem to upstream libsanitizer project:
> https://github.com/llvm/llvm-project/issues
I already did:
https://github.com/google/sanitizers/issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #11 from Stas Sergeev ---
The third bug here seems to be
that __asan_handle_no_return:
https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_rtl.cpp#L602
also calls sigaltstack() before
unpoisoning stacks. I believe th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #13 from Stas Sergeev ---
Found another problem.
https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/asan/asan_posix.cpp#L53
The comment above that line talks about
SS_AUTODISARM, but the line itself does
not account for any f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #15 from Stas Sergeev ---
(In reply to Martin Liška from comment #14)
> Please report to upstream as well.
I'd like some guidance on how should that
be addressed, because that will allow to
specify the upstream.
I am not entirely su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #16 from Stas Sergeev ---
I think I'll propose to apply something like this to linux kernel:
diff --git a/kernel/signal.c b/kernel/signal.c
index 6f3476dc7873..0549212a8dd6 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -4153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #17 from Stas Sergeev ---
I sent the small patch-set here:
https://lore.kernel.org/lkml/20220126191441.3380389-1-st...@yandex.ru/
but it is so far ignored by kernel developers.
Someone from this bugzilla should give me an
Ack or Revi
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
---
Similarly, access by taking the address, casting the resulting po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502
--- Comment #2 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #1)
> I think you misunderstood what precise means in this context really.
> "Higher levels correspond to higher accuracy (fewer false positives). "
So was it a false-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502
--- Comment #4 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #3)
> Because GCC can optimize that pun+dereference pattern without _not_ breaking
Did you mean to say "without breaking the code"?
I will assume it is the case:
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502
--- Comment #5 from Stas Sergeev ---
Note that this code example
is trivial. If the warning have
disappeared as a false-negative,
then I am surprised you close this
as NOTABUG, as there is definitely
something to fix or improve here.
Not detecti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103502
--- Comment #7 from Stas Sergeev ---
(In reply to Eric Gallager from comment #6)
> -Wstrict-aliasing is kind of confusing in this regards since it's different
> from how other warnings with numerical levels work. Normally a higher
> numerical va
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 53804
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53804&action=edit
test case
$ gcc -Wrestrict -O1 -c www.c
In file included from /usr/include/strin
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 53124
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105936
Stas Sergeev changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #6 from Stas Sergeev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104777
--- Comment #14 from Stas Sergeev ---
(In reply to Uroš Bizjak from comment #13)
> Please backport the patch also to gcc-10 branch.
9.4.0 fails for me on ubuntu-20.
8.5.0 also fails.
Please back-port to all possible
branches.
: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 58940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58940&action=edit
test case
Attached is a small test-case.
Just run make:
```
cc -fpic -fpie -c -o weak.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116393
--- Comment #2 from Stas Sergeev ---
Can -fpic win, rather than to rely on a
command line args order, which is very fragile?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116393
--- Comment #5 from Stas Sergeev ---
The documentation says:
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
I checked and I get these defines with no -fpic and with
"-fpic -fpie" which supposedly discards -fpic. The onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116393
Stas Sergeev changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #7 from Stas Sergeev
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 58941
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58941&action=edit
test case
$ gunzip a.c.gz
$ gcc -c a.c
[ no output ]
$ gcc -m32 -c a.c
d
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Maybe this is a documentation issue.
Documentation says:
-fpic:
When this flag is set, the macros __pic__ and __PIC__ are defined to 1.
It doesn't say anything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116395
--- Comment #3 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #1)
> va_list can't be used that way.
> in x86 (32bit) va_list is a pointer while in x86_64, it is an array.
https://stackoverflow.com/questions/77647307/expression-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116395
Stas Sergeev changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #5 from Stas Sergeev
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Use any dummy source like this:
void foo(void) {}
Then:
$ cc -Wall -o libmain.so -shared main.c -static
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/crtbeginT.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217
--- Comment #1 from Stas Sergeev ---
So as #7516 suggests, it is now indeed
rejected. :(
And at the same time clang has no problem
with that combination of options.
Please make that a valid option combination
again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217
--- Comment #4 from Stas Sergeev ---
(In reply to Richard Biener from comment #3)
> -static-pie is now marked as the negative of -shared, so it works with that
> (the later cancelling out the earlier). It isn't handled that way for
> -static vs
++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 55063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55063&action=edit
test case
struct a {
short aa;
};
typedef struct a less_al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
--- Comment #1 from Stas Sergeev ---
Sorry, copied the output from wrong place.
The real error msg looks like this:
$ g++ -Wall -c a.cpp
a.cpp: In member function ‘less_aligned_a& t1::get_ref()’:
a.cpp:17:16: error: cannot bind packed field ‘(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
The standard says:
https://eel.is/c++draft/class.mem.general#7.2
A complete-class context of a class (template) is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #4 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #3)
> One more note, default argument clause does not apply here as the it is not
> an argument of a method of that class but rather a different context (the
> lamdba d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #6 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #5)
> Nope, lamdba's are not a nested class.
But according to this:
https://timsong-cpp.github.io/cppwp/n3337/expr.prim.lambda#3
The type of the lambda-expression (whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #7 from Stas Sergeev ---
Also I verified your assumption in
comment #5 by this code:
struct A {
struct dummy {
static constexpr const int foo(const int off = offsetof(A, a)) { return
off; }
static constexpr const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #8 from Stas Sergeev ---
Added a few experts who can probably
answer that. While I do not doubt that
Andrew is right, I am sure having the
properly spelled explanation will help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #10 from Stas Sergeev ---
OMG, not what I intended to get. :(
All I need is to use offsetof() in templates.
Last time I started to use reinterpret_cast
for that, you disallowed reinterpret_cast in
constexpr context. Now this...
Why i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #11 from Stas Sergeev ---
So if I understand correctly, before
your proposal the following code was
conforming:
template
struct B {
static constexpr int off = O();
};
struct A {
char a;
B<[]() static constexpr ->int {
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 58550
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58550&action=edit
preprocessed source
Compiling the attached preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115729
--- Comment #2 from Stas Sergeev ---
> rejects-valid
You meant accepts-invalid?
Anyway, constexpr makes it consistent, thanks!
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
The test code below works with
clang but is rejected by gcc:
---
#include
#if 0
#include
#else
typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #4 from Stas Sergeev ---
No, this is wrong.
I am perfectly aware that it doesn't
restore the full register set. I need
it to only restore stack. But it simply
doesn't compile.
Why on clang it works properly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #6 from Stas Sergeev ---
In order to restore the stack, I
need it to be inlined. Otherwise
it won't restore the right stack.
But even in that case it generates this:
Dump of assembler code for function setjmp:
=> 0x00401160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
Stas Sergeev changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #12 from Stas Sergeev ---
Well I can move %rsp with an
inline asm to some pre-defined
buffer before recovering regs
with swapcontext. Or I can manually
adjust it in jmpbuf, in which case
I won't be on a wrong stack even
temporarily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #17 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #16)
> A warning
> would be OK.
Sure!
Add an UB warning and rephrase the initial
error.
Replace this error:
'setjmp' can never be copied because it receives a non-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267
--- Comment #15 from Stas Sergeev ---
So in this case is this really good
to disallow the always_inline attribute?
- It just throws the meaningless error.
Its meaningless because clang has no
such problem, so stating "can never be copied"
is pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
--- Comment #9 from Stas Sergeev ---
Note that this silly (and wrong)
warning can't even be disabled.
Or at least the warning itself
doesn't hint how to do that.
I think all other warnings do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84440
--- Comment #3 from Stas Sergeev ---
Yes, this warning:
warning: unknown conversion type character 'P' in format [-Wformat=]
can be suppressed with -Wno-format,
but it seems to suppress the entire
format checking. I only need to suppress
"unkno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194
--- Comment #3 from Stas Sergeev ---
Explicitly packing non-POD
field seems to allow the packing.
How about saying so in the
warning?
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Just wondering how feasible would
that be to have the dedicate switch
for assignable temporaries?
This is quite a nice feature of
-fpermissive, w/o the good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120025
--- Comment #7 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #6)
> So the big problem with this extension is that it will not work with
> concepts (and SFINAE) in a decent form. This is why the extension was
> removed in the firs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120025
--- Comment #5 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #4)
> >I've got on clang forum
>
> I tried looking for that but I don't see it on discourse.llvm.org at all nor
> on as an issue at https://github.com/llvm/llvm-proje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120025
--- Comment #2 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #1)
> I am not even sure what assignable temporaries is. Do you have an example?
```
#include
struct A {
int a;
~A() { std::cout << "a=" << a << std::endl; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120025
--- Comment #8 from Stas Sergeev ---
The interesting thing is that
this works:
```
#include
struct A {
int a;
~A() { std::cout << "a=" << a << std::endl; }
};
int main()
{
(int&)A().a = 5;
return 0;
}
```
So I can just cast t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923
--- Comment #13 from Stas Sergeev ---
Just for the record, Richard Smith
pointed the correct syntax for my
problem, which I would never ever
find myself, and likely no one else
in the world, too:
#include
template
struct B {
public:
stat
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 61391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61391&action=edit
test case
Attached is a preprocessed source.
gcc -O2 -W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208
--- Comment #1 from Stas Sergeev ---
While I am at it, I wonder
how to ask gcc to ignore the
#lineno directives in a
preprocessed input. I've found
-P to not generate them, but
if they are added, then locating
the problematic spot in a
preproces
101 - 158 of 158 matches
Mail list logo
