https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201
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 im
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=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.
Wh
++
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 -
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
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #2 from Stas Sergeev 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 be packed, no matter what.
Why does the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #4 from Stas Sergeev 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 like a useless limitation, no?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #8 from Stas Sergeev 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. :)
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 ti
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
> --with-native-system-
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 u
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:
/home/stas/src/b
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 --sysro
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
idea
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 #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 h
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 #17 from Stas Sergeev ---
Created attachment 46991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46991&action=edit
the fix
Attached is the patch that I think is correct.
It also seems to work properly, i.e. the full
build proc
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 host)
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 #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 #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,
>
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 mean s
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. E.g.
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 rest?
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 exp
++
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&action=edit
test-case
The attached test-case demonstrates the problem:
---
$ LC_ALL=C g+
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 packe
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",
>
++
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&action=edit
test-case
Hello.
Attached is a fully automated test-case
for the
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: 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, a
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 really
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&action=edit
test case
The following seemingly valid test-case can
be compil
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, neve
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 pro
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=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
ty: normal
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 m
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=]
---
T
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.
: 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 #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 dis
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
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 tr
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 a
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 th
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&action=edit
a test case
The attached test-case prints "1" when
compiled
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.
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
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 #1 from Stas Sergeev ---
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 both tests
with similar gcc.
Is th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #3 from Stas Sergeev ---
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 of fault_cnt var
Being thread-loca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #5 from Stas Sergeev ---
(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 (init_handler() func)
>
> Why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #7 from Stas Sergeev ---
(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 #3)
> > > > The signal hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #8 from Stas Sergeev ---
Note that O0 and O1 are fine.
Only O2 gives the problem. So there
might be a simple solution somewhere!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #11 from Stas Sergeev ---
(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 that is the TLS segment. Any
> other use it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #12 from Stas Sergeev ---
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 ---
(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 I'll be looking into too to save me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #16 from Stas Sergeev ---
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 by some other means, that gcc will not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
--- Comment #18 from Stas Sergeev ---
(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 is saved, too.
>
> In 64-bit
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.
: 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 #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.
> -fdire
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 branch
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 #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 #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 or
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 it
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 effec
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" :: "r&qu
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
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 opti
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)
{
__label__
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" (&&lab),
Well, if not for Andrew telling exactly that
you can't, both here and in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
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 distance
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
int main()
{
unsigned char a[1] = { -1 };
return a[0];
}
$ g++ -fpermissive nar.cpp
nar.cpp: In function ‘int main()’:
nar.cpp:3:28: error: narrowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
--- Comment #2 from Stas Sergeev ---
(In reply to Andreas Schwab from comment #1)
> It depends on the selected C++ standard. C++11 does not allow narrowing
> conversions unconditionally.
Yes, I am not disputing that.
But I used -fpermissive mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
--- Comment #4 from Stas Sergeev ---
(In reply to Jonathan Wakely from comment #3)
> It seems like you might be expecting more from -fpermissive than it actually
> provides. It only affects a very limited set of diagnostics, and isn't a
> genera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476
--- Comment #18 from Stas Sergeev ---
(In reply to Stas Sergeev from comment #5)
> And its running on a stack previously
> poisoned before pthread_cancel().
And the reason for that is because
the glibc in use is the one not built
with -fsanitiz
++
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
const.cpp:
---
const int AAA=5;
---
Good run:
---
$ g++ -O0 -c -o const.o const.cpp
$ nm const.o |c++filt
r AAA
---
Bad run:
---
$ g++ -O1 -c -o const.o
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 #4 from Stas Sergeev ---
Thread 3 "X ev" hit Breakpoint 4, __sanitizer::UnsetAlternateSignalStack () at
../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:190
190 void UnsetAlternateSignalStack() {
(gdb) n
194
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 158 matches
Mail list logo
