http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
Bug #: 53760
Summary: attribute packed doesn't pack inner structs
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #2 from Stas Sergeev stsp at users dot sourceforge.net 2012-06-24
18:09:18 UTC ---
Even if attribute packed have nothing to do with this,
then why doesn't it pack regardless?
Eg,
struct {
char a:1;
char b:1;
char c:1;
}
would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #4 from Stas Sergeev stsp at users dot sourceforge.net 2012-06-24
18:20:00 UTC ---
Is this mandated in some spec or doc?
Any way to defeat that? :)
Btw, why can't the attribute packed be
allowed to pack on a bit boundary too?
Sounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #8 from Stas Sergeev stsp at users dot sourceforge.net 2012-06-25
10:29:40 UTC ---
I think gcc C could support it too by
some pack_harder attribute (and then not
allow pointers to such structs), but I've got
the point. :)
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Hello.
On x86 (both 32 and 64), linux doesn't set
FS and GS registers to the sane values when
invoking the signal handler. Therefore the
first thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #8 from Stas Sergeev stsp at users dot sourceforge.net ---
Note that O0 and O1 are fine.
Only O2 gives the problem. So there
might be a simple solution somewhere!
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Hello.
On x86 (32/64) gcc uses FS register for TLS.
When writing a signal handler, a special care
must be taken: FS register must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #7 from Stas Sergeev stsp at users dot sourceforge.net ---
(In reply to Andrew Pinski from comment #6)
(In reply to Stas Sergeev from comment #5)
(In reply to Andrew Pinski from comment #4)
(In reply to Stas Sergeev from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #3 from Stas Sergeev stsp at users dot sourceforge.net ---
The signal handler needs to do the following things:
1. Restore segment registers (init_handler() func)
2. Increment thread-local var (fault_cnt)
3. Do stuff including reads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #11 from Stas Sergeev stsp at users dot sourceforge.net ---
(In reply to Andrew Pinski from comment #9)
Clang is not GCC. Really you should not be using the fs segment register
for your own use as it is part of the ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #1 from Stas Sergeev stsp at users dot sourceforge.net ---
Please note that the shown code was generated
with gcc-4.8.2, but inability to clobber segreg
with inline asm was tested with gcc-5.1.1.
A bit of dissonance here, I can't do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #12 from Stas Sergeev stsp at users dot sourceforge.net ---
Note that on x86_64 you can't set FS without a syscall.
I would really hate doing that in asm it seems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #15 from Stas Sergeev stsp at users dot sourceforge.net ---
(In reply to Andrew Pinski from comment #13)
Those all have pure assembly code to handle this case.
No, they actually simply don't use TLS in a handler.
That's something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #5 from Stas Sergeev stsp at users dot sourceforge.net ---
(In reply to Andrew Pinski from comment #4)
(In reply to Stas Sergeev from comment #3)
The signal handler needs to do the following things:
1. Restore segment registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #16 from Stas Sergeev stsp at users dot sourceforge.net ---
Actually, Andrew, do you think this is even
TLS specific? No segregs are restored at all (not even DS,
I was wrong saying it is), so is it guaranteed, if FS
is restored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #18 from Stas Sergeev stsp at users dot sourceforge.net ---
(In reply to Andy Lutomirski from comment #17)
I'll chime in, possibly uselessly.
Before Linux 4.1, only CS was saved. (Unless you go *way* back.) In 4.1
or newer, SS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998
--- Comment #15 from Stas Sergeev ---
Btw, clang seems to allow same regs in input and clobber list.
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 37948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37948=edit
a test case
The attached test-case prints "1" when
compiled with -O0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70214
--- Comment #6 from Stas Sergeev ---
Thanks Andrew!
I'll fight with glibc a bit before giving up
on this. At least they should have documented it
in a more humble way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
--- Comment #4 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #3)
> If you want it to be initialized at runtime, do that yourself.
> The compiler can't do that, you could e.g. access bigarr from another
> compilation unit before
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Hello.
The following code:
---
int bigarr[1024*1024] = {1,};
int main()
{
return 0;
}
---
produces a 4Mb executable when compiled with -Os.
Shouldn't the trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
--- Comment #2 from Stas Sergeev ---
The question is not what happens now, but rather
can't it be done differently?
Is there any reason why gcc can't but it into .bss
anyway, and initialize from the startup code?
I realize this is not a bug but
++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 43055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43055=edit
test-case
The attached test-case demonstrates the problem:
---
$ LC_ALL=C g++ -Wall pod.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
--- Comment #5 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #3)
> warning_at
> (DECL_SOURCE_LOCATION (x), 0,
>"ignoring packed attribute because of unpacked non-POD field
> %q#D",
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
--- Comment #2 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #1)
> The warning might be using the old C++98 definition of POD.
Lets specify -std explicitly then:
$ g++ -std=c++11 pod.cpp
pod.cpp:11:16: warning: ignoring
++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 4
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=4=edit
test-case
Hello.
Attached is a fully automated test-case
for the problem. J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65674
Stas Sergeev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
Stas Sergeev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Format attribute is usually used with
the custom printf-alike funcs. It is not
unusual for those funcs to implement more
format
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
-Bsymbolic option is ignored by gcc.
-Wl,-Bsymbolic works correctly.
-Bsymbolic should either be rejected, or
passed to the linker, but not ignored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84440
--- Comment #2 from Stas Sergeev ---
(In reply to Richard Biener from comment #1)
> gcc tells you when warning which switch you can use to disable the
> diagnostics.
---
warning: unknown conversion type character 'P' in format [-Wformat=]
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
--- Comment #3 from Stas Sergeev ---
So a clang bug?
I wonder if ubsan is supposed to produce the
compile-time errors, rather than the run-time
warnings. Would it be possible to downgrade
this to a compile-time warning, and/or add a
switch to
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Hello.
The following example:
---
#include
int foo(uint64_t a)
{
switch (a) {
case (1 << 31):
return 1;
}
return 0;
}
int main(int argc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
--- Comment #5 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #4)
> The reason you get an error is that the expression isn't constant, because
> it needs to emit the runtime diagnostics. Just fix the bug and get away
> with that?
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87884
--- Comment #2 from Stas Sergeev ---
(In reply to Martin Liška from comment #1)
> In general we have issues with warnings when sanitizers are used.
More than that.
You also have a compile-time errors now!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331
--- Comment #7 from Stas Sergeev ---
(In reply to Jason Merrill from comment #4)
> But when we're in the middle of the class definition we don't know yet
> whether it's standard-layout, so we can't answer yet. A compiler is allowed
> to reorder
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
#include
class A {
public:
char a;
};
class B : public A {
public:
static constexpr size_t b = offsetof(B
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 45700
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45700=edit
test case
The following seemingly valid test-case can
be compiled with cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331
--- Comment #2 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #1)
> Simplified testcase:
> struct A { char a; };
> struct B : public A { static constexpr int b = __builtin_offsetof (B, a); };
>
> clang rejects this too, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334
--- Comment #4 from Stas Sergeev ---
Would it be possible to at least show the
correct line number where the register allocation
actually failed? gcc points to a rather "random"
line, and it required many hours of an engineer
work to find the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334
--- Comment #2 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #1)
> the same for -m64, but only al/bl/cl/dl for -m32, because there is no
> sil/dil/bpl for -m32.
But why does this matter?
I am perfectly fine with al/bl/cl/dl,
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Hello.
I tried to build gcc with non-empty DESTDIR.
It fails on libquadmath:
In file included from ../../../gnu/gcc-9.2.0/libquadmath/math/x2y2m1q.c:19:
../../../gnu/gcc-9.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #3 from Stas Sergeev ---
(In reply to Harald van Dijk from comment #1)
> archive from the DESTDIR directory and extracting it elsewhere. It is not
> supposed to be used at configure time to pick up other software, only at
> install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #4 from Stas Sergeev ---
(In reply to Harald van Dijk from comment #1)
> The ways to handle libc being installed in non-standard locations depend on
> your specific use case. GCC provides the --with-sysroot and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #16 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #15)
> For the record, this has moved to
> https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html
Thanks, I also would like to apologize to Joseph for
not following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #17 from Stas Sergeev ---
Created attachment 46991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46991=edit
the fix
Attached is the patch that I think is correct.
It also seems to work properly, i.e. the full
build process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #19 from Stas Sergeev ---
OK, but the setup when you want to override
the newly-built gcc, is also needed. Like, when
you want to build the "destdir" gcc with the one
installed directly into prefix (and therefore
working fine on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #6 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #5)
> Which makes sense, since the system headers are not part of GCC itself, so
> why would it expect them in the temporary staging area for GCC's own files?
OK, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
--- Comment #8 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #7)
> Using the non-standard packed attribute already makes the code non-portable.
It may be non-standard, but its still portable
as long as all compilers agree on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #10 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #9)
> It's possible the paths passed to -isystem should be prefixed with = when a
> sysroot is in use,
Great idea! Maybe it can even be unconditional,
as w/o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #8 from Stas Sergeev ---
(In reply to Andrew Pinski from comment #7)
> Have you looked into --with-build-sysroot ?
Thanks! Very helpful.
But now it has the same problem when configuring libstdc++:
---
configure:4574:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #12 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #11)
> Those -isystem paths are the *non-sysroot* kind of paths for headers for a
> cross compiler.
Unfortunately I wasn't able to fully understand the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Stas Sergeev changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #28 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #22)
> The build system design is that where A and B are both built at the same
> time, and the build of B uses A, it should use the *newly built* copy of A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #30 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #29)
> A common way of doing that is to make $host and $build textually different
> (after passing through config.sub) while still logically the same. E.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #31 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #29)
> A common way of doing that is to make $host and $build textually different
> (after passing through config.sub) while still logically the same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #32 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #29)
> A common way of doing that is to make $host and $build textually different
> (after passing through config.sub) while still logically the same. E.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #34 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #33)
> to, you can also make your build system set all the variables such as CC
> and CXX that are needed for the host).
As well as AS, LD and all the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #36 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #35)
> what you want. I'm familiar with many of the details through having
> written multiple such build systems myself.
But even you do make the wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #23 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #22)
> On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
> And overriding like that is fundamentally unsafe, because in general in a
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #27 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #26)
> On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote:
>
> > Ah, I am starting to understand.
> > So basically you m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #21 from Stas Sergeev ---
Hi Joseph, thanks for your assistance!
(In reply to jos...@codesourcery.com from comment #20)
> The only case where the newly built GCC should be overridden is the
> Canadian cross case,
Since today, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #25 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #24)
> > But isn't there always a possibility to add
> > one more stage? Say, in the example above where
> > at stage1 we only have a static-only compiler,
>
++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
#include
struct D;
struct B {
virtual operator D() = 0;
};
struct D : B
{
operator D() override { std::cout << "conv" << std::endl; return D(); }
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194
Stas Sergeev changed:
What|Removed |Added
Version|7.2.1 |9.2.1
--- Comment #2 from Stas Sergeev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #26 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #23)
> What you want (and what everybody I've seen asking for similar things)
But comment #17 shows the different use of
reinterpret_cast - offsetof in templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
$ gcc -E -Wp,-P -xc -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #4 from Stas Sergeev ---
Jakub, people use "cc -E -Wp,-P $CFLAGS" as a generic
preprocessor. $CFLAGS is needed to specify the includes,
but all other options do never affect -E.
But if CFLAGS contains -g3, you suddenly can't do that!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #10 from Stas Sergeev ---
Ah, cool, thanks.
Should this be re-opened?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #12 from Stas Sergeev ---
Will your patch also fix this:
$ cpp -g3 -P -xc -g0 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #14 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #13)
> Because without the -dD implicitly added for -g3 the -g3 option can't work
> as documented, in particular record the macros in the debug information.
> Because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #6 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #5)
> Then they just make bad assumptions. You can do:
> cc -E -Wp,-P $CFLAGS -g0
> instead if you are sure CFLAGS don't include the -d[DMNIU] options nor e.g.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #8 from Stas Sergeev ---
Thanks, but what will this patch do?
Will it allow the trailing -g0, or what?
For example if you implement -d0 or alike to undo
the effect of previously specified -dD, will this
still break the release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #18 from Stas Sergeev ---
IMHO the only thing that makes sense,
is whether or not this is useful in practice.
If there are no practical cases for current
"-g3 -P" behaviour, then to me the fact that
its documented that way, is more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #16 from Stas Sergeev ---
What do you think about, in addition
to your current patch, to also change
-P to disable debug?
Looks more user-friendly and clang-compatible?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #20 from Stas Sergeev ---
Ah, makes sense, thank you.
I was always wondering why under clang I
need to do "-fdebug-macro" for that (which
makes problems for gcc as being an unknown option).
But "clang -g3 -fdebug-macro -E -Wp,-P -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #21 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #19)
> It is just that clang doesn't support -g3 at all, as can be seen by clang
> not producing any .debug_macinfo nor .debug_macro sections.
So with -fdebug-macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989
--- Comment #23 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #22)
> -S -fpreprocessed test.i will not work
It doesn't seem to support -fpreprocessed though.
Thanks for explanations and sorry about
naively attributing that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
--- Comment #3 from Stas Sergeev ---
I can't use inline-asm gotos because
I can't manipulate such a label in a portable way.
For example:
---
asm volatile (
"push $1f\n"
"ret\n"
"1:\n"
);
---
This won't work with
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
The following code works as expected with
clang, but hangs with gcc with -O2 (works with -O1):
---
int main()
{
__label__ ret;
asm volatile ("jmp *%0\n" :: "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
--- Comment #4 from Stas Sergeev ---
I can achieve similar results with this:
---
void cont(void) asm("_cont");
asm volatile (
"push %0\n"
"ret\n"
"_cont:\n"
::"r"(cont));
---
But this doesn't work if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
--- Comment #8 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #7)
> It doesn't mean you can't use "r" (&),
Well, if not for Andrew telling exactly that
you can't, both here and in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
--- Comment #6 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #5)
> I think Andrew meant asm goto, which you haven't tried.
You are right.
Thanks for mentioning that.
But it doesn't work as well:
---
int main(void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
--- Comment #9 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #7)
> you need to tell the compiler
> the asm can goto to that label.
Of course the one would wonder what else
could be done to the passed label. :)
Maybe some
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 pointer
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
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:
>
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #3 from Stas Sergeev ---
Why does it check for a redzone
on a non-leaf function? GetAltStackSize()
calls to a glibc's getconf and that
overwrites a canary.
Maybe it shouldn't use/check the redzone
on a non-leaf function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #5 from Stas Sergeev ---
Another problem here seems to be
that pthread_cancel() doesn't unpoison
the cancelled thread's stack.
This causes dtors to run on a
randomly poisoned stack, depending
on where the cancellation happened.
That
1 - 100 of 130 matches
Mail list logo
