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 {
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
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 #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
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109824
Stas Sergeev changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
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
++
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=edit
test case
struct a {
short aa;
};
typedef struct a less_aligned_a __attribut
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
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.
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=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
>
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
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
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=edit
test case
$ gcc -Wrestrict -O1 -c www.c
In file included from /usr/include/string.h:
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105936
Stas Sergeev changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #6 from Stas Sergeev
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=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
--- 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
@@
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
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
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
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://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=edit
test case
This is a reproducer for both problems.
$ cc -Wall -o bug -ggdb3 -fsanitize=address bug.c -O1
to see the
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://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
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 #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
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
++
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=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=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 #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 #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
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=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
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 #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=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 #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=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=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 #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 #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 #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 #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 #10 from Stas Sergeev ---
Ah, cool, thanks.
Should this be re-opened?
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 #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 #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!
: 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=201
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
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
++
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=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=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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
Stas Sergeev changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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
--- 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 #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=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
--- 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
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=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
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 #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
--- 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: ---
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
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
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!
: 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=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?
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
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=]
---
1 - 100 of 130 matches
Mail list logo
