[Bug c/201] Switch statement will not accept constant integer variable as case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #6 from Stas Sergeev --- Is there some switch to enable that as an extension?
[Bug c++/83732] wrong warning about non-POD field
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 implementing the particular extension. And the "packed" extension is AFAIK the very old one and most widely used. Unsupporting it is far from good decision. Non-standard things should not be automatically treated as "non-portable" IMO. Kenman Tsang: This bug was initially not about the wrong object size. It was about the wrong diagnostic that says "ignoring packed attribute" but actually packs an object perfectly well. Your example demonstrates the case where the "packed" attribute is really ignored (and the diagnostic is in line with that), so this is a different problem. For which I opened another ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194 You may want to join that ticket, leaving this one just for the diagnostic problem.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
Stas Sergeev changed:
What|Removed |Added
CC||stsp at users dot
sourceforge.net
--- Comment #17 from Stas Sergeev ---
The following code now breaks:
---
#include
#include
template
struct offset_of {
constexpr operator size_t() const {
return (std::uintptr_t)&(static_cast(nullptr)->*M);
}
};
template
struct B {
char aa[10];
static const int off = offset_of();
};
struct A {
char a;
char _mark[0];
B b;
};
int main()
{
A a;
std::cout << "size " << sizeof(A) << " off " << a.b.off << std::endl;
return 0;
}
---
There is no other way of making offsetof(), rather
than by a reinterpret cast in constexpr (unless you
try very hard - I was still able to work around these
new gcc checks, but its tricky).
Would you consider adding this into -fpremissive?
Suddenly removing an extensions that people got used to,
is not the best treatment of users, AFAICT. Isn't -fpermissive
a right place for the extensions that people got used to?
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
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.
What work-around would you suggest for that case?
> A more limited extension that solves the problem is a lot more reasonable.
If it would have been done before the feature
is removed, and for every possible use-case, then
yes. :)
In any case, what limited extension would you
suggest for the offsetof case?
Would something like the below[1] considered as such extension
(currently doesn't compile):
---
template
struct B {
static constexpr int off = O();
};
struct A {
char a;
B<[](){ return offsetof(A, a); }> b;
};
---
Below is the very similar code[2] that actually compiles:
---
template
struct B {
static constexpr int off = O();
};
struct A {
char a;
static constexpr int off(void) { return offsetof(A, a); }
B b;
};
---
So given that [2] compiles and works, and [1]
can be used as a limited work-around for the
offsetof case (at least in my case [1] is enough),
I wonder if it can be considered as a possible extension.
[Bug c++/93984] New: spurious Wclass-conversion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93984
Bug ID: 93984
Summary: spurious Wclass-conversion warning
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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(); }
};
.
int main()
{
D obj;
B& br = obj;
(D)br; // calls D::operator D() through virtual dispatch
return 0;
}
$ LC_ALL=C g++ -Wall -o vconv vconv.cpp
vconv.cpp:9:5: warning: converting 'D' to the same type will never use a type
conversion operator [-Wclass-conversion]
9 | operator D() override { std::cout << "conv" << std::endl; return
D(); }
| ^~~~
$ ./vconv
conv
The example above shows that the warning
is spurious. Converting to the same type
will indeed never use the conversion
operator. But the above case converts
from B to D, so the warning does not apply.
It may be quite difficult to check properly,
but in this particular example the "override"
keyword is a clear hint that it is going
to be used via the virtual dispatch.
[Bug c++/84194] fails to pack structs with template members
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 --- Why it is still unconfirmed?
[Bug c/53760] New: attribute packed doesn't pack inner structs
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
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@users.sourceforge.net
The following code:
---
#include
struct A {
char a:1;
struct {
char a:1;
} __attribute__((packed)) s1;
struct {
char a:1;
} __attribute__((packed)) s2;
struct {
char a:1;
} __attribute__((packed)) s3;
} __attribute__((packed));
int main()
{
printf("%lu\n", sizeof(struct A));
return 0;
}
---
prints '4' instead of '1'.
Every bitfield seems to be occupying an entire byte.
[Bug c/53760] attribute packed doesn't pack inner structs
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 same not happen to the struct?
Any way to force such a packing? There is an
obvious (IMHO) need for that.
[Bug c/53760] attribute packed doesn't pack inner structs
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?
[Bug c/53760] attribute packed doesn't pack inner structs
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. :)
[Bug other/91879] New: DESTDIR support seems incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Bug ID: 91879
Summary: DESTDIR support seems incomplete
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
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/libquadmath/quadmath-imp.h:24:10: fatal error: errno.h:
No such file or directory
24 | #include
| ^
The problem is that the system headers are searched in a
prefix path that doesn't account for DESTDIR. This is because
of the explicit -isystem in the command line. I looked at a
build system and found that -isystem is built from the "tooldir"
variable of the configure script. So I made the following change
to confirm my findings:
--- configure.ac.old2019-09-24 03:44:28.141779422 +0300
+++ configure.ac2019-09-24 03:30:59.022308759 +0300
@@ -2572,7 +2572,7 @@
# Some systems (e.g., one of the i386-aix systems the gas testers are
# using) don't handle "\$" correctly, so don't use it here.
-tooldir='${exec_prefix}'/${target_noncanonical}
+tooldir='${DESTDIR}${exec_prefix}'/${target_noncanonical}
build_tooldir=${tooldir}
# Create a .gdbinit file which runs the one in srcdir
And with that change the build worked.
So I suppose this is a build system bug.
[Bug other/91879] DESTDIR support seems incomplete
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 time to determine the location to install into. Yes, I understand that. And yet what I see is that when gcc is building its libs, it looks for the system headers under prefix, not under destdir. But you are right, I probably should try mail list for the help with that. (In reply to Jonathan Wakely from comment #2) > (In reply to Stas Sergeev from comment #0) > > Hello. > > > > I tried to build gcc with non-empty DESTDIR. > > What exact commands did you run? I have the script that runs basically "make all-gcc" and "make" after setting some env vars. And what fails is the plain "make" step. I can show you how exactly: --- libtool: compile: /home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/xgcc -B/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/ -B/usr/local/cross/i586-pc-msdosdjgpp/bin/ -B/usr/local/cross/i586-pc-msdosdjgpp/lib/ -isystem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem /usr/local/cross/i586-pc-msdosdjgpp/sys-include -DHAVE_CONFIG_H -I. -I../../../gnu/gcc-9.2.0/libquadmath -I ../../../gnu/gcc-9.2.0/libquadmath/../include -g -O2 -MT math/x2y2m1q.lo -MD -MP -MF math/.deps/x2y2m1q.Tpo -c ../../../gnu/gcc-9.2.0/libquadmath/math/x2y2m1q.c -o math/x2y2m1q.o In file included from ../../../gnu/gcc-9.2.0/libquadmath/math/x2y2m1q.c:19: ../../../gnu/gcc-9.2.0/libquadmath/quadmath-imp.h:24:10: fatal error: errno.h: No such file or directory 24 | #include | ^ compilation terminated. --- > I don't see why DESTDIR should matter until the 'make install' step. Please note the -isystem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem /usr/local/cross/i586-pc-msdosdjgpp/sys-include above. Clearly it misses the DESTDIR, and feeding the DESTDIR there makes the problem to go away.
[Bug other/91879] DESTDIR support seems incomplete
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-header-dir configure options, These ones specify the locations permanently. My problem is that I need a different sysroot/system-header-dir only for the time of building the gcc libs. This is when DESTDIR is set. When the package is installed on the target, then DESTDIR is unset and the prefix locations should be used. So I think the options you pointed, do not help in my case. Somehow I need the build system to pick up DESTDIR while building its libs. If I could pass the variable name to --with-native-system-header-dir, like -with-native-system-header-dir=\$DESTDIR/somedir (dollar is "escaped" in that example to not expand immediately) then that would work, but I don't suppose passing the variable name is possible?
[Bug other/91879] DESTDIR support seems incomplete
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 understand. But then its a bit unclear to me how to build the cross-compiler. I build both gcc and its libs on the host, so somehow I need to provide it with the location of the headers _on host_, which is different with what will it be later on the target. > You didn't show how. What exact commands did you run? If only that would be so easy to tell with the script I have. :) > I'm not interested in the libtool command that GCC runs, I want to know what > your script does. Not what it runs basically, but precisely. The configure > command, and the make commands. OK, still "basically", but hopefully more informative than before: --- export DESTDIR=/path/to/somedir cd builddir ../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp -- disable-nls --enable-libquadmath-support --enable-version-specific-runtime-libs --enable-fat --enable-libstdcxx-filesystem-ts --target=i586-pc-msdosdjgpp --pref ix=/usr/local/cross --enable-languages=c,c++ make all-gcc make install-gcc make [ fails here ] make install-strip --- Some things are still stripped, as the script also sets pathes after make install-gcc and does some other things. If this is still not enough, I'll work on a minimal reproducer. > So if you need it defined before that step, you're doing something wrong. We > can't tell what you're doing wrong, because you haven't said what you're > doing. I am trying to get this build script to work: https://github.com/stsp/build-gcc/tree/master to build djgpp tool-chain w/o root privs. The current strategy of that script is to install built gcc on host (needs root), then build gcc libs from there. I want to confine it to the DESTDIR, including the headers installation, so the way I run that script (I don't expect you are going to try it yourself of course): --- QUIET=1 DESTDIR=`pwd`/ttt ./build-djgpp.sh gcc-9.2.0 ---
[Bug other/91879] DESTDIR support seems incomplete
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/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/x gcc -B/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/ -B/usr/loc al/cross/i586-pc-msdosdjgpp/bin/ -B/usr/local/cross/i586-pc-msdosdjgpp/lib/ -isy stem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem /usr/local/cross/i586- pc-msdosdjgpp/sys-include --sysroot=/home/stas/src/build-gcc/ttt/usr/local/cross -c -g -O2 conftest.c >&5 conftest.c:10:10: fatal error: stdio.h: No such file or directory 10 | #include | ^ --- As you can see, it added the correct --sysroot. But unfortunately -isystem is still unaffected. If I change -isystem in the command line above, then conftest.c can be compiled. Here's the full top-level configure invocation: --- ../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp -- disable-nls --enable-libquadmath-support --enable-version-specific-runtime-libs --enable-fat --enable-libstdcxx-filesystem-ts --with-build-sysroot=/home/stas/sr c/build-gcc/ttt/usr/local/cross --target=i586-pc-msdosdjgpp --prefix=/usr/local/ cross --enable-languages=c,c++ --- As you can see, I added --with-build-sysroot.
[Bug other/91879] --with-build-sysroot doesn't work as expected
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 --sysroot it won't change anything? I hacked that solution in. Also I've found that I was setting --with-build-sysroot wrongly in the previous example: I included prefix into it, but it shouldn't be there. Now with your = idea I've got further only for a tiny bit. It fails on the same conftest as before. It now finds the headers! But fails to find libs... --- configure:4135: /home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/x gcc -B/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/ -B/usr/loc al/cross/i586-pc-msdosdjgpp/bin/ -B/usr/local/cross/i586-pc-msdosdjgpp/lib/ -isy stem=/usr/local/cross/i586-pc-msdosdjgpp/include -isystem=/usr/local/cross/i586- pc-msdosdjgpp/sys-include --sysroot=/home/stas/src/build-gcc/ttt -o conftest - g -O2 conftest.c >&5 /home/stas/src/build-gcc/ttt/usr/local/cross/bin/i586-pc-msdosdjgpp-ld: cannot f ind crt0.o: No such file or directory /home/stas/src/build-gcc/ttt/usr/local/cross/bin/i586-pc-msdosdjgpp-ld: cannot f ind -lc collect2: error: ld returned 1 exit status --- If I correct -B options above, then it links! Any firther ideas? :) We are really getting close to the solution. > but prefixing them with $DESTDIR is definitely wrong. I renamed the ticket. Sorry for misleading conclusions.
[Bug other/91879] --with-build-sysroot doesn't work as expected
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 you explain. You mention "sysroot" and "non-sysroot"
builds, and you suggest to use --with-build-sysroot=
together with --with-sysroot= (without providing an example
of how to set --with-build-sysroot=, so I assume it should
be equal to $DESTDIR). May I assume that in the "sysroot"
build all the -isystem pathes will be changed the way the
sysroot prefix is replaced with build-sysroot prefix during
libs build?
OTOH I found a very simple way of implementing the Andrew Pinski
suggestion. Here it is:
---
--- configure.ac.old2019-09-25 17:00:34.973324924 +0300
+++ configure.ac2019-09-25 17:45:33.958152993 +0300
@@ -2327,6 +2327,7 @@
[use sysroot as the system root during the build])],
[if test x"$withval" != x ; then
SYSROOT_CFLAGS_FOR_TARGET="--sysroot=$withval"
+ build_sysroot_path=${withval}
fi],
[SYSROOT_CFLAGS_FOR_TARGET=])
AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
@@ -2573,7 +2574,7 @@
# Some systems (e.g., one of the i386-aix systems the gas testers are
# using) don't handle "\$" correctly, so don't use it here.
tooldir='${exec_prefix}'/${target_noncanonical}
-build_tooldir=${tooldir}
+build_tooldir=${build_sysroot_path}${tooldir}
# Create a .gdbinit file which runs the one in srcdir
# and tells GDB to look there for source files.
--
What do you think guys? Does it break something?
It definitely works for me.
[Bug other/91879] --with-build-sysroot doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 Stas Sergeev changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #14 from Stas Sergeev --- OK, thanks, lets close this. If I won't succeed, I'll use ML.
[Bug other/91879] --with-build-sysroot doesn't work as expected
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 his suggestion and instead keeping to
fight with the gcc build system. I can't help feeling
there is a bug here, and I think I am quite close to
getting it solved, so I'd be upset having to change the
approach after so many investigations, at least for now.
I've found this patch of Paolo Bonzini:
https://gcc.gnu.org/ml/gcc-patches/2006-01/msg00823.html
---
(GCC_TARGET_TOOL): Do not use a host tool if we found a target tool
with a complete path in either $with_build_time_tools or $exec_prefix.
---
That made me think that --with-build-time-tools=
should override the in-tree tools, but it is
not what actually happens. More details here:
https://gcc.gnu.org/ml/gcc-help/2019-10/msg2.html
Basically, the idea was to build one djgpp on host,
and then use that one for building the target libs
in another build tree. But it doesn't pick up the
host-installed tools.
After looking at the Paolo's patch, I tried the following
change:
--- config/acx.m4.old 2019-10-02 02:39:31.976773572 +0300
+++ config/acx.m4 2019-10-02 02:08:57.223563920 +0300
@@ -522,7 +522,7 @@
fi
else
ifelse([$4],,,
- [ok=yes
+ [ok=no
case " ${configdirs} " in
*" patsubst([$4], [/.*], []) "*) ;;
*) ok=no ;;
And indeed got the build done, as --with-build-time-tools=
now found all the host tools in preference of the in-tree tools.
So currently I suspect Paolo's patch is at fault.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 Stas Sergeev changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- Summary|--with-build-sysroot|--with-build-time-tools |doesn't work as expected|doesn't work as expected
[Bug other/91879] --with-build-time-tools doesn't work as expected
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 process passes (previous patches were only tested for the part of the build process that was failing). This patch allows --with-build-time-tools= to override the in-tree compiler, which I think this option is for. Please let me know if it is good or bad.
[Bug other/91879] --with-build-time-tools doesn't work as expected
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). Would you suggest a new option for that? I've seen the variables CC_FOR_TARGET and alike, but they do not work that way too. So I think currently there is no way of doing that, and so some patch should be created. How should it look like?
[Bug other/91879] --with-build-time-tools doesn't work as expected
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 is no longer true. :)
https://code.launchpad.net/~stsp-0/+recipe/djgpp-daily
I managed to get the build working, and this build
only works when possibility exist to override the
in-tree tools.
It works as follows:
- The stage1 cross-compiler is built with --prefix=${DESTDIR}${stash_area}
and installed with DESTDIR unset (it is already in the prefix).
This is a non-sysroot build so it can work on host.
- The stage2 compiler is built with --prefix=/usr and
installed with the DESTDIR set to the build dir. As the
result, this stage2 compiler can't build its libs! (libgcc, libstdc++)
It can't build its libs because it is never installed
into its prefix dir on host, and so I override its
in-tree tools with the ones from the stage1 compiler.
> Your problem as originally described was with finding non-sysroot headers.
Yes, I attempted the 1-stage build back then.
But why not to support the 2-stage build, as this is
what I already have? It only required a tiny patch
above, and since it can't be applied as-is, I can take
a look into making it a separate option. What I want to
point out is that there is already the use for such option,
because it is already used in my build (in the form of
the --with-build-time-tools hack for now, but can be extended).
> A plausible approach to fixing that if you can't use sysroots is to add a
> a new configure option whose purpose is to point to the build-time
> non-sysroot location of headers that should be used in building target
> libraries.
I think I tried this already, see comment #10.
I did a hack to change the header pathes. And
that worked, but then there are those -B options
that prevented the libs from being found during
configure process. So I found the change-headers-path
approach infeasible and implemented a 2-stage solution.
Do you still think that the path-altering games
can lead to a solution?
And since I already succeeded with overriding the
in-tree tools, why not to implement that route as
a new configure option? It looks very simple.
[Bug other/91879] --with-build-time-tools doesn't work as expected
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 > multi-stage build (such as for a cross to GNU/Linux where the first stage > is a static-only C-only compiler) the libraries have to be built with the > more-fully-featured compiler built in the same stage - not with the > previous stage's compiler. 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, we could add stage2 and stage3. stage2 is a fully-featured compiler to build stage3. I think this approach will always work, just use N+1 stages. > Then maybe an option is needed to find both headers and libraries in the > non-sysroot case (where the option for libraries gives the top-level > directory under which subdirectories for each multilib, using the multilib > OS suffix, can be found). An option to find the build-time equivalent of > $exec_prefix/$target, with lib and include subdirectories, say. And then why such an option is not called --with-build-sysroot? In comment #11 you say "there is no non-sysroot-headers equivalent of --with-build-sysroot", but I don't understand what do you mean. Can we use --with-build-sysroot w/o --with-sysroot, making it exactly an option you describe above? > 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 Lets do A --> B' --> B then. :) > "make all-target-libstdc++-v3" or whatever). In general, if you don't > want to build with the newly built copy of A you should configure and > build in such a way that there isn't a newly built copy of A at all. Mm, yes, I was thinking about renaming the dirs during build to hide stuff from configure, but decided against doing so as being too hackish. Would you suggest this way for the wide adoption?
[Bug other/91879] --with-build-time-tools doesn't work as expected
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, > > we could add stage2 and stage3. stage2 is a fully-featured > > compiler to build stage3. I think this approach > > will always work, just use N+1 stages. > > It's desirable to reduce the number of stages, not increase it. I think it depends. :) So if someone wants to increase the amount of stages, why not to support also that, together with the approaches you propose. To me, its all about flexibility. > (Bootstrapping such a GNU/Linux toolchain used to take three stages, which > was successfully reduced to two by fixing glibc to build with the > first-stage GCC.) Reduced amount of stages is also good to support. :) Why not to implement both ways? > The --with-build-sysroot option gives the location of a directory that > uses the sysroot layout, which is not the same as that of a non-sysroot > $exec_prefix/$target - unless your non-sysroot layout does not use /usr. > > If you set up the toolchain so that it thinks /include rather than > /usr/include is the native system header directory, then you can use > --with-sysroot and --with-build-sysroot without any temporary usr -> . > symlinks. Ah, I am starting to understand. So basically you mean something like this: --with-sysroot=$prefix/$target --with-build-sysroot=$DESTDIR$prefix/$target --with-prefix=/ This way we simulate the cross-layout and also are changing the build pathes of headers and libs at once. And if we use the default prefix, /usr, then we'd also need to symlink everything back to $sysroot/ because, while buildable even w/o the symlinks, we'll get the wrong target layout, right? In which case we can add the symlinks after the build is completed, correct? > Those -isystem paths are the *non-sysroot* kind of paths for headers > for a cross compiler. So do you mean that on a sysroot build those -isystem will look much differently? How exactly? Or will they look similar but alterable with --with-build-sysroot? Knowing how -isystem will behave in a sysroot case is the last piece of the puzzle for me concerning your suggested solution. So your suggestion is to have some option like --with-build-time-prefix, which can be set to $DESTDIR$prefix, right? In this case the compiler will replace $exec_prefix/$target with $build_time_prefix/$target during build, right? But the question is still, why not to support both ways, if adding an extra stage is also the legal and simple way of getting the work done.
[Bug other/91879] --with-build-time-tools doesn't work as expected
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 something like this: > > --with-sysroot=$prefix/$target --with-build-sysroot=$DESTDIR$prefix/$target > > --with-prefix=/ > > It's --with-native-system-header-dir=/include not --with-prefix=/, but > that's the idea. Ah, yes, indeed. So can I assume that in the -isystem path and -B path, the sysroot part will be swapped with the build_sysroot during build? If so, then I would finally understand your sysroot suggestion. But there are still 2 more suggestions, yours and mine, and I am not sure what is to do with them. I think your suggestion is to add something like --with-build-time-prefix to be able to specify the alternative location of headers and libs for non-sysroot build. Mine is to add --with-build-time-compiler=dir. I think we can have both, and I can try to implement mine (--with-build-time-compiler) if you think this is acceptable (i.e. the _possibility_ to add an extra build stage is acceptable).
[Bug other/91879] --with-build-time-tools doesn't work as expected
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
> as long as that is for _$host = $build_.
Indeed! I missed this "$host = $build" part initially.
When I build djgpp that _runs_ under DOS, then it is not
used during the compilation, as that would simply be impossible.
So such config is already supported.
Is there any way to convince the build system that the
resulting compiler is alien and cannot be used? I think
$host = $build check is just insufficient; there may be
more cases when the resulting compiler can't be used on
a build system, like different prefix.
If there is no such option currently, what do you think
about replacing the
if test "${build}" != "${host}"
with
if test "${build}" != "${host}" -o "$non_native_build"
or something like this?
[Bug other/91879] --with-build-time-tools doesn't work as expected
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. > x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. Thanks, I'll explore that and will post back in a day or 2. But... this one and your sysroot suggestion are _tricks_. I wonder why the one should use tricks for just the basic task of building a cross-compiler, this just looks strange.
[Bug other/91879] --with-build-time-tools doesn't work as expected
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. > x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. And being a trick, it appears non-trivial. I would want the CPU part to be the same. I.e. x86_64-pc-linux-gnu --> x86_64-unknown-linux-gnu i686-pc-linux-gnu --> i686-unknown-linux-gnu The problem here is that I can't hard-code $host to any of that value. It must be evaluated from $build somehow. Do you have a trick also for that? Probing manually for uname before configure? Or maybe its time to add a new option after all? :)
[Bug other/91879] --with-build-time-tools doesn't work as expected
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. > x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. OK, I did the following: $ ../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp --disable-nls --enable-libquadmath-support --enable-version-specific-runtime-l ibs --enable-fat --enable-libstdcxx-filesystem-ts --target=i586-pc-msdosdjgpp --build=x86_64-unknown-linux-gnu --host=x86_64-pc-linux-gnu --enable-languages =c,c++ --prefix=/usr --with-build-time-tools=/home/stas/src/build-gcc/build/tm pinst/usr After which we can see in the log: configure:2360: checking build system type configure:2374: result: x86_64-unknown-linux-gnu configure:2421: checking host system type configure:2434: result: x86_64-pc-linux-gnu configure:2454: checking target system type configure:2467: result: i586-pc-msdosdjgpp ... which looks correct? But the reaction was absolutely inadequate. It started to look for fully-prefixed host tools: configure:8235: checking for x86_64-pc-linux-gnu-ar configure:8265: result: no configure:8376: checking for x86_64-pc-linux-gnu-as configure:8406: result: no configure:8517: checking for x86_64-pc-linux-gnu-dlltool configure:8547: result: no configure:8658: checking for x86_64-pc-linux-gnu-ld configure:8688: result: no And of course found nothing. If I do not explicitly specify --host, then it takes $host from $build, so no matter if I altered the --build, the $host and $build would match. So they either match, or it looks for the fully-prefixed host tools... Any solution to this one? :)
[Bug other/91879] --with-build-time-tools doesn't work as expected
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? But that defeats the entire purpose of configure. I need it to work on my PC, on launchpad build-farm, and who knows where else. So I would need to write a supplementary configure script to just fill in these variables. OTOH the new option could affect it exactly the way that configure would treat the newly-built compiler as alien (as if $host!=$build) and yet get the unprefixed tools. And will not require me to evaluate the (im)proper --build with manual uname probes (in fact, I don't do uname probes, I instead grep it from the stage1 configure log and fix up with sed). Why not to fix the mess, it just seems like its broken literally everywhere we look in... (if the total lack of controlling switches can stand for being "broken").
[Bug other/91879] --with-build-time-tools doesn't work as expected
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 expectations. Most of your suggestions (which are very reasonable by themselves) do not work or require additional tweaks. configure reacts inadequately on them. > The non-sysroot form of configuring cross toolchains is to a large extent > considered a *legacy* way to configure such a toolchain and so has > received less attention to making it feature-complete in its interactions > with other features (e.g. building with installed libc at a different > path) because most people prefer to use sysroots. OK, that's an interesting point. I didn't know its legacy. The problem is that I still do not fully understand that route. Does --with-sysroot disable prefix, or prefix should be set to '/' explicitly? Or to something else? If I naively do --with-build-sysroot=$DESTDIR --with-sysroot=/ why this won't work? I suppose there will be some differences in a directory layout, like no $target dir, but otherwise it can work? You suggest --with-sysroot=$prefix/$target but I don't understand why is so, as normally I have (1) $prefix/bin/$target-gcc and (2) $prefix/$target/bin/gcc If I set --with-sysroot=$prefix/$target then I can get (2), but how to get (1)? I think this is an rtfm point, is this sysroot trick documented anywhere?
[Bug c++/83732] New: wrong warning about non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732 Bug ID: 83732 Summary: wrong warning about non-POD field Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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++ -Wall pod.cpp pod.cpp:11:16: warning: ignoring packed attribute because of unpacked non-POD field 'ttt tst::a' struct ttt a; $ ./a.out size1=5 size2=8 --- As can be seen from the output, the attribute was actually not ignored. I actually think there are no non-POD members, so the warning is spurious and the resulting code is correct. And indeed, clang++ generates no such warning and the packing works fine there too.
[Bug c++/83732] wrong warning about non-POD field
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 packed attribute because of unpacked non-POD field 'ttt tst::a' struct ttt a;
[Bug c++/83732] wrong warning about non-POD field
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", >x); > cant_pack = 1; I wonder why this "cant_pack" is getting ignored somewhere later? The things are still packed.
[Bug c++/84194] New: fails to pack structs with template members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194
Bug ID: 84194
Summary: fails to pack structs with template members
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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 problem. Just run "make" and it
will compile test-case with clang and with
gcc, and will compare the output:
---
$ LC_ALL=C make
clang++ -std=c++11 -o p_clng pod.cpp
g++ -std=c++11 -o p_gcc pod.cpp
pod.cpp:16:23: warning: ignoring packed attribute because of unpacked non-POD
field 'SymWrp lol::_n'
SymWrp _n;
^~
./tst.sh
Test FAILED (sizeof returns 6 instead of 4)
---
This is somewhat similar to bug #83732, but
in #83732 it was considered a diagnostic problem.
Unfortunately it actually produces the bad code,
which is what the test-case demonstrates.
The test code is:
---
#include
#include
template
class SymWrp : public T {
public:
SymWrp() = default;
};
struct dhdr {
uint16_t dh_attr;
};
struct lol {
unsigned char _l;
SymWrp _n;
unsigned char _nj;
} __attribute__((packed));
int main()
{
printf("%zi\n", sizeof(struct lol));
return 0;
}
---
[Bug target/65674] stack smashing protector must be controllable per-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65674
Stas Sergeev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Stas Sergeev ---
This FR was implemented in
__attribute__((optimize("no-stack-protector")))
but nobody cared to write that to this ticket. :(
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
Stas Sergeev changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #19 from Stas Sergeev ---
Various work-arounds appeared since, like
__attribute__((optimize("no-stack-protector"))).
And even though I still can't tell gcc that
I clobbered the segregs, I can make it not
to use them behind my back, which is sufficient
for my needs.
[Bug c++/89331] New: internal compiler error: in build_simple_base_path, at cp/class.c:589
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331
Bug ID: 89331
Summary: internal compiler error: in build_simple_base_path, at
cp/class.c:589
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
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);
};
$ c++ -Wall -c overl.cpp
In file included from /usr/include/c++/8/cstddef:50,
from overl.cpp:1:
overl.cpp:10:41: internal compiler error: in build_simple_base_path, at
cp/class.c:589
static constexpr size_t b = offsetof(B, a);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
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 sure if it is valid or not.
Thanks for taking a look!
A slight off-topic: any idea why even this rejects:
struct A {
char a;
static constexpr int b = __builtin_offsetof (A, a);
};
and is there any work-around when I want to
pass offsetof value into a template non-type,
which also rejects:
struct A {
char a;
B<__builtin_offsetof(A, a)> b;
};
Does the standard explicitly forbids that, of just gcc?
[Bug inline-asm/89334] New: unsupported size for integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334 Bug ID: 89334 Summary: unsupported size for integer register Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm 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 compiled with clang, but fails with gcc with -O2: $ gcc -Wall -m32 -O2 -S -o foo.s foo.c foo.c: In function ‘do_work’: foo.c:60:1: error: unsupported size for integer register
[Bug inline-asm/89334] unsupported size for integer register
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, never asked to use sil/dil/bpl. What is the rationale? If "r" is plain invalid for 8bit values, then shouldn't the error be different and not to depend on an opt level? Could you please explain a bit more what exactly the error is and why it works with -O1? Why invalid registers (sil/dil/bpl) even matter at all?
[Bug inline-asm/89334] unsupported size for integer register
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 problematic spot in a large project. It really is not the good handling of this problem. And I don't understand why it is impossible to add error or warning if gcc emits 8bit reference for "r" and knows it is not supposed to work.
[Bug inline-asm/89334] unsupported size for integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89334 Stas Sergeev changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #6 from Stas Sergeev --- Thanks Andrew! Please, make gcc better, not worse. Prev versions generated "%sil", which, while silly, was at least traceable. And now the things are completely cryptic.
[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589
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 fields of a non-standard-layout class.
Thanks, that clears some things for me.
I definitely am not going to turn this ticket
into a forum, but I am still puzzled why the
below works (on gcc at least, not on clang):
---
#include
#include
class L {};
template
struct offset_of {
constexpr operator size_t() const {
return (std::uintptr_t)&(((T*)nullptr)->*M);
}
};
template
struct B {
char aa;
static const int off = offset_of();
};
struct A {
char a;
L _mark[0];
B b;
};
int main()
{
A a;
std::cout << "size " << sizeof(A) << " off " << a.b.off << std::endl;
return 0;
}
---
Here I do 2 emulation tricks.
I use address-of on the zero-sized mark to emulate
offsetof() in the not yet fully defined class.
And I use reinterpret cast in a constexpr to emulate
offsetof() that doesn't want to work with the template
arguments for some reason.
This works perfectly on gcc (I filled a bug report to clang).
So if the emulation works, why doesn't the original?
Are there any possibility to somehow extend __builtin_offsetof()
to cover either of those 2 cases where I currently have
to emulate it? While I understand the problem you described,
why does the above example avoids it?
[Bug driver/84440] New: unrecognized command line option '-Wno-format-invalid-specifier'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84440 Bug ID: 84440 Summary: unrecognized command line option '-Wno-format-invalid-specifier' Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: 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 more format specifiers than printf() does. clang has '-Wno-format-invalid-specifier' to avoid checking those, and only check the printf-compatible subset. But gcc only says this: --- cc1: warning: unrecognized command line option '-Wno-format-invalid-specifier' --- Would be nice to have this option, as it increases the usability of the format-checking attributes. Plus the better compatibility with clang.
[Bug driver/84440] unrecognized command line option '-Wno-format-invalid-specifier'
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=] --- This [-Wformat=] doesn't give me any clue. What does this mean? > There's a whole family of -Wformat-* options. But I can't find -Wno-format-unknown-specifier, am I missing something?
[Bug driver/84731] New: -Bsymbolic switch ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84731 Bug ID: 84731 Summary: -Bsymbolic switch ignored Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver 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.
[Bug c/87857] New: case label does not reduce to an integer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
Bug ID: 87857
Summary: case label does not reduce to an integer constant
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: 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, char *argv[])
{
return foo(argc);
}
---
doesn't compile with -fsanitize=undefined:
---
$ gcc -Wall -fsanitize=undefined lswitch.c
lswitch.c: In function ‘foo’:
lswitch.c:6:5: error: case label does not reduce to an integer constant
case (1 << 31):
---
But if you use g++ or clang with the same
switches, then it compiles fine.
[Bug c/87857] case label does not reduce to an integer constant
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 disable it? IMHO its absolutely unexpected to get the compilation failure just because of ubsan.
[Bug sanitizer/87857] case label does not reduce to an integer constant
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? 1U<<31 will do. I of course already "fixed" my code as per earlier comments here. So you can close this if you want. But I am sure gcc is not doing the right thing here. Just make it a warning, and, more importantly, -W warning, independent of any -f. Then people will get this warning with -Wall or whatever, and will not get a compilation failure with -fsanitize on otherwise warning-less code. I am not sure I understand how the run-time diagnostic makes the expression non-const.
[Bug sanitizer/87884] New: ubsan causes wrong -Wformat-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87884 Bug ID: 87884 Summary: ubsan causes wrong -Wformat-overflow warning Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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: --- Created attachment 44959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44959&action=edit test case Hello. Attached is the reduced test-case. It gives: --- gcc -c -Wall -fsanitize=undefined -O2 mangle.c -I. mangle.c: In function 'name_convert': mangle.c:57:3: warning: null destination pointer [-Wformat-overflow=] sprintf(s,"%s","test"); --- Which is wrong. Plus, I am not sure if "-Wformat-overflow=" is a correct switch for this type of warning.
[Bug sanitizer/87884] ubsan causes wrong -Wformat-overflow warning
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=87857 Which is completely unacceptable IMHO. > Martin: What about notifying users that one should not combine sanitizers > and warnings? It's becoming a very common issue. Could you please clarify? Do you mean, -Wall should not have been used together with -fsanitize? Also I wonder how do you mean to notify users, and why not to fix the code instead.
[Bug c/70060] New: array initialization adds to executable size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70060
Bug ID: 70060
Summary: array initialization adds to executable size
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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 initialization be optimized?
[Bug c/70060] array initialization adds to executable size
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 feature request, can it be treated as such?
[Bug c/70060] array initialization adds to executable size
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 the constructors of this CU are executed etc. OK, but in my example only the first element of an array needs an initialization. Wasn't it possible in that case to reserve just 1 page in rodata and not waste the megabytes of space for all zeros? But yes, I understand having sparse rodata would be a difficult task to achieve...
[Bug c/70214] New: external call is not considered a barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70214 Bug ID: 70214 Summary: external call is not considered a barrier Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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 with -O0, and "0" when compiled with -O1. I checked with clang - always "1", no matter what optimization level is. The bug is that gcc seems to no longer consider the external function call (pthread_kill() in this case) as an optimization barrier.
[Bug tree-optimization/70214] [4.9/5/6 regression] pthread_kill is not considered a barrier
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.
[Bug target/65674] New: stack smashing protector must be controllable per-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65674 Bug ID: 65674 Summary: stack smashing protector must be controllable per-function Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement 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 the sig handler should do is to restore these registers if the program itself can ever modify them. Unfortunately gcc uses them in prolog/epilog for ssp, and so the "stack smashing detected". I think attribute "no_instrument_function" or "naked" should do that, but currently they don't, which is almost a bug, at least "no_instrument_function" is supported but doesn't give the desired effect. I can't even think of any reasonable work-around. For example I could do the small asm wrapper that restores these regs, but on x86_64 this is not enough: you need to set their base separately, via the prctl() syscall. Doing this all from asm is too nasty, I really think gcc should allow writing the proper sighandler.
[Bug inline-asm/66631] New: inability to clobber segment regs makes tls problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631
Bug ID: 66631
Summary: inability to clobber segment regs makes tls
problematic
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
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 be restored by
hands, together with all other segment registers,
because linux unfortunately does not do that
(except cs and ds).
Then signal handler can access the thread-local
data safely... except that it can't.
After calling the function that restores the
segment registers, I need to specify that FS was
clobbered, which is currently not possible with
the inline asm.
As a result, the following code is generated:
0x004438c0 <+0>: push %r14
0x004438c2 <+2>: mov%edi,%r14d
0x004438c5 <+5>: push %r13
0x004438c7 <+7>: mov%rdx,%r13
0x004438ca <+10>:push %r12
0x004438cc <+12>:lea0x28(%rdx),%r12
0x004438d0 <+16>:push %rbp
0x004438d1 <+17>:mov%r12,%rdi
0x004438d4 <+20>:mov%fs:0x0,%rbp
0x004438dd <+29>:push %rbx
0x004438de <+30>:add$0xff80,%rsp
0x004438e2 <+34>:callq 0x4441b0
0x004438e7 <+39>:mov0x35070a(%rip),%rbx# 0x793ff8
0x004438ee <+46>:mov0x0(%rbp,%rbx,1),%eax <-- STACK FAULT
init_handler() is a function that restore the segregs -
it is called first in a function:
---
{
init_handler(scp);
// asm volatile("":::"fs");
fault_cnt++;
---
fault_cnt is a thread-local var:
extern volatile __thread int fault_cnt;
As you can see, gcc doesn't move the access to
fault_cnt below init_handler(), but, unfortunately,
it moved the address calculation. To prevent this,
I need to clobber the FS, but it doesn't seem to be
possible.
Please let me know if there are any work-arounds to that.
It seems to be a bug that gcc does not allow clobbering
the segregs that it use.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 there some magic -mno-xxx option that will prevent gcc from moving the addr caclulus too far away from the access to the volatile var?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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-local, fault_cnt var is being accessed
with the help of FS, but FS is only valid after the
call to init_handler().
Since fault_cnt is marked as volatile, gcc does not
move the access to it above the init_handler() call,
so that part is fine. What is NOT fine is this:
0x004438d4 <+20>:mov%fs:0x0,%rbp <-- (bad) TLS
access
0x004438dd <+29>:push %rbx
0x004438de <+30>:add$0xff80,%rsp
0x004438e2 <+34>:callq 0x4441b0<-- FS now
valid
0x004438e7 <+39>:mov0x35070a(%rip),%rbx# 0x793ff8
0x004438ee <+46>:mov0x0(%rbp,%rbx,1),%eax <-- STACK
FAULT
As you can see, gcc moved some TLS access above init_handler(),
which results in a stack fault later when trying to read from
fault_cnt.
To prevent moving any TLS access around init_handler(), I need
to do the following:
asm volatile("":::"fs");
but this gives a compilation error.
Is the explanation clear?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 are you doing this, that is the question I am trying to understand here. > What signal handler is happening? Ah, OK. This is a jit compiler. It uses segment registers at will, and it uses a memory protection too, so the signal is SIGSEGV. > Because you can't do this under Linux at > all. What exactly do you mean? > I am also trying to understand if you are writing a kernel/userspace why you > can't write this part in pure assembly function instead of using GCC here to > do this work. How am I supposed to access TLS in asm? init_handler() itself is mostly in asm though, yes. But the main sighandler is a huge convoluted func.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 handler needs to do the following things: > > > > 1. Restore segment registers (init_handler() func) > > > > > > Why are you doing this, that is the question I am trying to understand > > > here. > > > What signal handler is happening? > > Ah, OK. > > This is a jit compiler. > > It uses segment registers at will, and it uses > > a memory protection too, so the signal is SIGSEGV. > > That seems bogus usage really. And very unportable. Don't use segment > registers at all. Well, I can't, sorry. :) Please note that clang is getting this fixed already it seems: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110476.html http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140714/110481.html (not sure, just googled) Really, no even a -mno-xxx option to disable this optimization?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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!
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 of it is outside of the ABI and will break everything else. > Why can't you not use fs segment? Alien code in place (think of wine/dosemu). > Also why can't you write your segfault handler in assembly when you fixup > the fs segment and then call the C functions? In principle - yes, but in practice - looking into a source - too much work. It is large, and it also uses a syscalls: sys_prctl(ARCH_SET_FS, eflags_fs_gs.fsbase); Do syscalls in asm too? :( Of course this all is possible, but... Should I really resort to always using -O1 till that also break? :( Let me ask you from the other side: why not simply to allow clobber also segregs? Improvement for everyone IMHO. clang did that for chromium it seems - likely a jit either. IMHO gcc should allow writing the specific things like signal handlers, interrupt handlers in embedded systems, etc - they all have suprises and deviations from ABI, yet gcc usually has an extensions to cover all these needs. Why to suddenly change that good practice?
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 from all that pain, but its not like they write a part of sighandler in asm and do the syscalls in asm. > That is they have > wrapper code which handles the first part in pure C Guess you meant "pure asm" here. > and then pass it on to > the other code. If you have such an evidence - the URL would be nice. >From what I see they avoid the troubles simply by not using TLS. > I don't see why you need to do the first part in assembly code and then pass > it on to C code. Do you suggest syscalls in asm? int80h? sysenter? > Or why do you need to use the fs segment when it is part of the x86 Linux > ABI? It seems like you are outside of C/ABI at this stage and need pure > assembly to fix up your code. Again this is outside of the x86 Linux ABI > and GCC should not handle this at all. gcc handles many many things that are outside the ABI imho. It has many function attributes for all the weird cases... except this one of course. :) > Yes because you are setting the TLS segment. Again why are you abusing > the fs segment here not to be the TLS segment? IMHO linux itself should have been restoring FS. It doesn't, and as such, the signal handlers are violating the ABI. gcc can kindly fulfill the gap with just a small patch, as clang did, or even just by telling me the magic -mno-xxx option, or force the users to suffer.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 start using some "movs" instruction before init_handler(), or some ds-prefixed access? So, my guess is this: - If this is only TLS-specific and gcc really really doesn't want to implement a nice possibility of clobber segregs, then I'll probably start asking linux kernel people about a possible solution. After all, restoring TLS is their task. - BUT, if this is not TLS-specific but is unsafe with ANY segreg, then I think gcc should just allow clobber.
[Bug inline-asm/66631] inability to clobber segment regs makes tls problematic
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 code, DS and ES have no effect*, so I don't think it should affect > code gen. OK, so the problem is TLS-specific, and is therefore have less relevance to gcc. Indeed it then will be very good if the kernel can take care of TLS. My point was just that for gcc it may not be a big problem to implement a segreg clobbering, if the kernel devs don't want to restore TLS. > Anyway, I tend to agree with Andrew here, I think: if you want to fiddle > with FS and GS, write a little asm wrapper around the C code. Yes but what kind of wrapper? Should it do also the syscall to set the needed fs base? At one point I may start pestering glibc guys to provide such a wrapper, if everyone else is unhelpful. :)
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #14 from Stas Sergeev --- (In reply to Eric Botcazou from comment #12) > > the compiler may think that "something" do not modify eax. So next > > assignment > > may use eax ( mov eax, x ). So, "it does not make sense to have it as a > > clobber" is not correct. does not it ? > > Andrew was saying that it doesn't make sense to consider input operands as > clobbered by an inline asm, generically. How about allowing an ampersand in the input list? Just like early clobber in output list, in input list it may mean "late clobber" - that is, clobbered after the argument is taken. Then you won't contradict with any doc and will avoid any logical inconsistency. This makes a lot of sense for things like "rep; movsl" where you'd need 3 dummy values...
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
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.
[Bug debug/97989] New: -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 Bug ID: 97989 Summary: -g3 somehow breaks -E Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: stsp at users dot sourceforge.net Target Milestone: --- $ gcc -E -Wp,-P -xc -
[Bug debug/97989] -g3 somehow breaks -E
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! > -g3 enables -dD Not letting people to use "cc -E -Wp,-P $CFLAGS" as a generic preprocessor, is a very bad idea. If -g3 enables -dD, then perhaps -P should disable it?
[Bug debug/97989] -g3 somehow breaks -E
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. > -fdirectives-only. $ gcc -g3 -E -Wp,-P -xc -g0 -
[Bug debug/97989] -g3 somehow breaks -E
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 branches? I suppose not?
[Bug debug/97989] -g3 somehow breaks -E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97989 --- Comment #10 from Stas Sergeev --- Ah, cool, thanks. Should this be re-opened?
[Bug debug/97989] -g3 somehow breaks -E
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 -
[Bug debug/97989] -g3 somehow breaks -E
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 they would be irrecoverably lost during the preprocessing phase. I think there is a bit of misunderstanding. The question is: I re-checked and found that not only "gcc -g3" sets -dD for cpp (which I understand), but also "cpp -g3" does the same. Raw cpp, not gcc. Should cpp react on -gX directly, rather than on an implicitly set -dD? But: $ gcc -Wp,-g3 -E -Wp,-P -xc -
[Bug debug/97989] -g3 somehow breaks -E
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?
[Bug debug/97989] -g3 somehow breaks -E
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 less irrelevant. :) Besides, not every extension contradicts the documentation. If you extend -P that way, it will still suppress the line numbers, perfectly as documented before, so no old use-cases are supposed to be broken. > clang simply decided not to implement the documented > switches the way they were documented. But in a way that is most useful in practice. :) But whatever. I know such arguments (practical use vs documentation) were raised 1024+ times here, so not trying to say something new.
[Bug debug/97989] -g3 somehow breaks -E
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 -
[Bug debug/97989] -g3 somehow breaks -E
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 actually produces .debug_macinfo, but still no .debug_macro. Yet gdb is quite happy with that and can see the macros. So... Why "clang -g3 -fdebug-macro -E -Wp,-P -
[Bug debug/97989] -g3 somehow breaks -E
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 effect to -P.
[Bug c/98896] New: local label displaced with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896
Bug ID: 98896
Summary: local label displaced with -O2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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"(&&ret) : "memory");
ret:
return 0;
}
---
As can be seen from a disasm, the label is put before asm block.
[Bug middle-end/98896] local label displaced with -O2
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 -pie. But if I do "r"(&&ret) then the rip-relative reference is generated so pie works. > See PR 29305 and others too on why this is undefined. >From that PR I can only see that its undefined because the documentation didn't define such use, at best. I am not sure it immediately means "undefined". --- You may not use this mechanism to jump to code in a different function. If you do that, totally unpredictable things will happen. The best way to avoid this is to store the label address only in automatic variables and never pass it as an argument. --- Not sure if I violated that. I pass it as an argument to an inline asm only - does this count as passing as an argument or what? I suppose they meant "as an argument to a function". Inline asm is not a function. Anyway: - What is the point to misplace the label that is obviously (for gcc) used? - Why clang have no problem with that code?
[Bug middle-end/98896] local label displaced with -O2
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 optimizer inlines
the function, as you then get multiple definitions
of "_cont".
[Bug middle-end/98896] local label displaced with -O2
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__ cont;
asm volatile goto (
"push %l[cont]\n"
"ret\n"
cont);
cont:
return 0;
}
---
$ LC_ALL=C cc -Wall -ggdb3 -O2 -o jmpret2 jmpret2.c -pie -fPIE
/usr/bin/ld: /tmp/cc1UoxnD.o: relocation R_X86_64_32S against `.text.startup'
can not be used when making a PIE object; recompile with -fPIE
And in an asm file we see:
---
#APP
# 4 "jmpret2.c" 1
push .L2#
ret
---
Please compare this to the following:
---
int main(void)
{
__label__ cont;
asm volatile (
"push %0\n"
"ret\n"
::"r"(&&cont));
cont:
return 0;
}
---
And its asm:
---
.L2:
.loc 1 4 5 view .LVU1
leaq.L2(%rip), %rax #, tmp83
#APP
# 4 "jmpret3.c" 1
push %rax # tmp83
ret
---
So... it seems, only the second case can work,
and indeed does with clang?
[Bug middle-end/98896] local label displaced with -O2
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=29305
then indeed, it doesn't.
Because this seems to work:
---
int main(void)
{
__label__ cont;
asm volatile goto (
"push %0\n"
"ret\n"
::"r"(&&cont):"memory":cont);
cont:
return 0;
}
---
So... is this a correct, documented, supported etc
way of doing things, and it won't disappear in the
next gcc version?
Then perfectly fine.
Thanks for your help!
[Bug middle-end/29305] local label-as-value being placed before function prolog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #11 from Stas Sergeev --- Just for a heads-up. The solution to that problem was suggested here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98896#c7
[Bug middle-end/98896] local label displaced with -O2
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 was calculated by subtracting 2 labels, or alike. Maybe it wasn't jump. But why does it help to assume that something passed to volatile asm, remains unused? Just wondering. IMHO at least it deserves a warning.
[Bug c++/108538] New: unexpected -Wnarrowing errors in -fpermissive mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108538
Bug ID: 108538
Summary: unexpected -Wnarrowing errors in -fpermissive mode
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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 conversion of ‘-1’ from ‘int’ to ‘unsigned char’
[-Wnarrowing]
3 | unsigned char a[1] = { -1 };
While I know that some -Wnarrowing
warnings were promoted to an errors,
was it the right decision also in
-fpermissive mode, which accepts most
of the C code?
[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode
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 mode to compile the mix of c/c++. -fpermissive downgrades many C++ errors to a warning, eating most of the regular C. So my question here is explicitly about -fpermissive mode, I think it should downgrade -Wnarrowing back into the warning.
[Bug c++/108538] unexpected -Wnarrowing errors in -fpermissive mode
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 > general "compile invalid code" switch. I always used it to compile the (valid) C code in C++ mode. I thought that's what it is for. It violates the C++ standard up and down. And that -Wnarrowing case is "better" than others because it was a warning in c++03. Other problems that -fpermissive allows, were always an errors in any c++ mode.
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error and pthread_cancel
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 -fsanitize=address. When it calls its __do_cancel() which has attribute "noreturn", __asan_handle_noreturn() is not being called. Therefore the canceled thread remains with the poison below SP. I believe the glibc re-built with asan would not exhibit the crash. Note: all URLs above where I was pointing to the code, now either are a dead links or point to wrong lines. Its quite a shame that such a bug remains unfixed after a complete explanation was provided, but now that explanation is rotten...
[Bug c++/104053] New: const variable not exported with O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104053 Bug ID: 104053 Summary: const variable not exported with O1 Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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 const.cpp $ nm const.o |c++filt ---
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 Stas Sergeev changed: What|Removed |Added CC||stsp at users dot sourceforge.net --- Comment #2 from Stas Sergeev --- I have the very same crash with the multi-threaded app. The test-case from this ticket doesn't reproduce it for me either, but my app crashes nevertheless. So I debugged it a bit myself. gcc-11.2.1. The crash happens here: https://github.com/gcc-mirror/gcc/blob/master/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc#L10168 Here asan checks that sigaltstack() didn't corrupt anything while writing the "old setting" to "oss" ptr. Next, some check is later fails here: https://code.woboq.org/gcc/libsanitizer/asan/asan_thread.cc.html#340 Asan failed to find the canary value kCurrentStackFrameMagic. The search was done the following way: it walks the shadow stack down, and looks for the kAsanStackLeftRedzoneMagic to find the bottom of redzone. Then, at the bottom of redzone, it looks for the canary value. I checked that the lowest canary value is overwritten by the call to GetAltStackSize(). It uses SIGSTKSZ macro: https://code.woboq.org/llvm/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp.html#170 which expands into a getconf() call, so eats up quite a lot. Now I am not entirely sure what conclusion can be derived out of that. I think that the culprit is probably here: https://code.woboq.org/gcc/libsanitizer/asan/asan_interceptors_memintrinsics.h.html#26 They say that they expect 16 bytes of a redzone, but it seems to be completely exhausted with all canaries overwritten. Does something of the above makes sense? This is the first time I am looking into an asan code.
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
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?
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
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 altstack.ss_size = GetAltStackSize(); // Some sane value required on
Darwin.
(gdb) p /x $rsp
$128 = 0x7fffee0a0ce0
(gdb) p &oldstack
$129 = (stack_t *) 0x7fffee0a0d00
(gdb) p /x *(int *)0x7fffee0a0cc0 <== canary address
$130 = 0x41b58ab3
(gdb) p 0x7fffee0a0ce0-0x7fffee0a0cc0
$132 = 32
Here we can see that before a
call to GetAltStackSize(), rsp
is 32 bytes above the lowest
canary value. After the call,
there is no more canary because
32 bytes are quickly overwritten
by a call to getconf().
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
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 explains the "random" nature of a crash, and the fact that pthread_cancel() is in a test-case attached to that ticket, and in my program as well. So, the best diagnostic I can come up with, is that after pthread_cancel() we have this: --- #0 __sanitizer::UnsetAlternateSignalStack () at ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:190 #1 0x77672f0d in __asan::AsanThread::Destroy (this=0x7358e000) at ../../../../libsanitizer/asan/asan_thread.cpp:104 #2 0x769d2c61 in __GI___nptl_deallocate_tsd () at nptl_deallocate_tsd.c:74 #3 __GI___nptl_deallocate_tsd () at nptl_deallocate_tsd.c:23 #4 0x769d5948 in start_thread (arg=) at pthread_create.c:446 #5 0x76a5a640 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 --- And its running on a stack previously poisoned before pthread_cancel(). Then it detects the access to poisoned area and is trying to do a stack trace. But that fails too because the redzone canary is overwritten. So all we get is a crash.
