Bug#812255: g++-6: ICE with -fsanitize=undefined -fcheck-pointer-bounds -mmpx
Package: g++-6
Version: 6-20160117-1
Severity: minor
I was trying out the new -fcheck-pointer-bounds option (which requires -mmpx)
and found that in combination with -fsanitize=undefined it causes an ICE:
$ cat x.cc
int * a;
void f() { *a = 1; }
$ g++-6 -fsanitize=undefined -fcheck-pointer-bounds -mmpx -c x.cc
x.cc:2:20: internal compiler error: Segmentation fault
void f() { *a = 1; }
^
0xaadb6f crash_signal
../../src/gcc/toplev.c:334
0xb31e88 chkp_walk_pointer_assignments
../../src/gcc/tree-chkp.c:3725
0xb339af chkp_finish_file()
../../src/gcc/tree-chkp.c:3835
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Removing -fsanitize=undefined the problem seems to go away.
Cheers,
Olly
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages g++-6 depends on:
ii gcc-66-20160117-1
ii gcc-6-base 6-20160117-1
ii libc62.21-6
ii libgmp10 2:6.1.0+dfsg-2
ii libisl15 0.15-3
ii libmpc3 1.0.3-1
ii libmpfr4 3.1.3-2
ii libstdc++-6-dev 6-20160117-1
ii zlib1g 1:1.2.8.dfsg-2+b1
g++-6 recommends no packages.
Versions of packages g++-6 suggests:
pn g++-6-multilib
pn gcc-6-doc
pn libstdc++6-6-dbg
-- no debconf information
signature.asc
Description: PGP signature
Bug#752733: g++-4.9: PR61214 breaks packages linking against wxWidgets
On Thu, Jun 26, 2014 at 11:33:24PM +1200, Olly Betts wrote: > On Thu, Jun 26, 2014 at 10:34:41AM +0200, Matthias Klose wrote: > > Wondering if we can have a work-around in wxwidgets-3.0, building without > > -fvisibility-inlines-hidden, until this is fixed in gcc-4.9. This way we > > would > > have to touch only one package. At least the upstream test case works with > > it. > > Would removing and later (once GCC is fixed) re-adding > -fvisibility-inlines-hidden affect the ABI of the wxwidgets-3.0 libraries? I had a different idea for working around this in wxwidgets-3.0 - the testcase in the GCC PR compiles OK if I add an anonymous namespace to /usr/include/wx-3.0/wx/event.h containing a long list of lines like this, one for each wxEvent subclass: auto debian_wx3_gcc49_pr61214_wxWindowDestroyEvent_hack = &wxWindowDestroyEvent::Clone; This was a proof of concept - for an actual fix, "auto" would be the appropriate pointer-to-member type, so it works in non-C++11 mode. It also needs something to suppress -Wunused-variable warnings. This approach may add a small size overhead (if it's not optimised away), but removing -fvisibility-inlines-hidden adds about 0.3MB to the wx core libraries. I'd probably make this conditional on GCC 4.9 being in use, or maybe GCC >= 4.9, to minimise the chance of potential issues with other compilers. Thoughts or better ideas welcome. > FYI, I'm attempting to open a bug report with wx upstream to make sure they're > aware of this issue, and to see if they have a recommended workaround. Sadly > their bugtracker is giving me 500 errors when I try to submit it, but I'll > retry periodically. Still no luck here. Cheers, Olly -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140627072617.GA24434@pippikin
Bug#752733: g++-4.9: PR61214 breaks packages linking against wxWidgets
On Thu, Jun 26, 2014 at 10:34:41AM +0200, Matthias Klose wrote: > Wondering if we can have a work-around in wxwidgets-3.0, building without > -fvisibility-inlines-hidden, until this is fixed in gcc-4.9. This way we would > have to touch only one package. At least the upstream test case works with it. Would removing and later (once GCC is fixed) re-adding -fvisibility-inlines-hidden affect the ABI of the wxwidgets-3.0 libraries? FYI, I'm attempting to open a bug report with wx upstream to make sure they're aware of this issue, and to see if they have a recommended workaround. Sadly their bugtracker is giving me 500 errors when I try to submit it, but I'll retry periodically. Cheers, Olly -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140626113324.GA7447@pippikin
Bug#569571: [armel] gcc-4.4 generates non-aligned relocations
On Mon, May 17, 2010 at 03:41:33PM +0200, Matthias Klose wrote: > > gcc-4.4 generates non-aligned relocations > > I doubt it. is there a reason why xapian-bindings doesn't use the > standard way of linking and provides all files directly, including the > compiler version? It just uses libtool for linking. > please could you recheck after rebuilding all files involved with linking > the extension? > > /usr/lib/libxapian.so -L/usr/lib/gcc/arm-linux-gnueabi/4.4.3 > -L/usr/lib/gcc/arm-linux-gnueabi/4.4.3/../../.. -lstdc++ -lm -lc -lgcc_s > /usr/lib/gcc/arm-linux-gnueabi/4.4.3/crtendS.o > /usr/lib/gcc/arm-linux-gnueabi/4.4.3/../../../crtn.o -Wl,-soname > -Wl,_xapian.so -o .libs/_xapian.so I'm assuming that's aimed as Sascha. Cheers, Olly -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100517140427.gf10...@survex.com
Bug#569571: affects apt-xapian-index as well
affects 569571 - src:xapian-core affects 569571 + python-xapian thanks On Sun, Apr 18, 2010 at 01:44:45PM +0200, Sascha Silbe wrote: > affects 569571 src:xapian-core apt-xapian-index > thanks This sounds like an issue which affected xapian-bindings (not xapian-core) in 1.0.18-1, but 1.0.19-1 worked around this by compiling with "-g": http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576944 I've not seen any indication that this affects xapian-core, and your report doesn't provide any (apt-xapian-index is written in Python; _xapian.so is part of python-xapian, and not from src:xapian-core): > === Begin === > /etc/cron.weekly/apt-xapian-index: > Bus error > run-parts: /etc/cron.weekly/apt-xapian-index exited with return code 135 > === End === So fixing your "affectation" to python-xapian not src:xapian-core. Cheers, Olly -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419043718.ga10...@eisluft
Bug#296456: update of patch for #296456
On Thu, Sep 15, 2005 at 10:36:04PM +0200, Matthias Klose wrote:
> please could you send an updated patch? IIUC, then the patch has to be
> updated.
OK, new patch attached.
Cheers,
Olly
--- gij-wrapper-3.4-old 2005-09-15 22:19:07.772964328 +0100
+++ gij-wrapper-3.4 2005-09-15 22:18:48.353916472 +0100
@@ -28,12 +28,20 @@
# Build the command-line from the arguments given.
my $parsingOptions = 1;
+
+# Flag used to copy argument to -classpath or -cp.
+my $copyNext = 0;
foreach my $arg (@ARGV) {
if (not $parsingOptions) {
# We're done parsing options; just copy all remaining arguments directly.
push @commandLine, $arg;
next;
}
+ if ($copyNext) {
+push @commandLine, $arg;
+$copyNext = 0;
+next;
+ }
# Try to interpret Sun-style options.
if ($arg eq '-version') {
@@ -42,8 +50,10 @@
push @commandLine, '--help';
} elsif ($arg eq '-cp' or $arg eq '--cp') {
push @commandLine, '-cp';
+$copyNext = 1;
} elsif ($arg eq '-classpath' or $arg eq '--classpath') {
push @commandLine, '-classpath';
+$copyNext = 1;
} elsif ($arg =~ /^-Djava.library.path=(.+)$/) {
# A component of the JNI search path has been given.
if ($JNIPath) {
Bug#296456: Acknowledgement (java wrapper script mishandles command line options with arguments)
I think there's a bug in my patch - on further reading it seems "-jar" just controls the interpretation of the first non-option argument rather than taking an argument itself... If that's the case, the test for -jar or -D* should remain unchanged. Cheers, Olly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296456: java wrapper script mishandles command line options with arguments
Package: gij-3.4
Version: 3.4.3-9
Tags: patch
The "java" wrapper script doesn't correctly handle command line options
with arguments (e.g. -classpath and -jar) so it doesn't handle cases
like this correctly:
java -classpath myjavaclasses -Djava.library.path=myjni Foo
Once it sees "myjavaclasses", the script switches to just copying
remaining arguments, so it the special handling for -Djava.library.path
doesn't kick in.
I've attached a patch to fix this.
Cheers,
Olly
--- /usr/bin/java 2004-12-18 23:40:26.0 +
+++ java2005-02-22 15:20:11.135688449 +
@@ -28,12 +28,20 @@
# Build the command-line from the arguments given.
my $parsingOptions = 1;
+
+# Flag used to copy argument to -classpath, -cp, -jar.
+my $copyNext = 0;
foreach my $arg (@ARGV) {
if (not $parsingOptions) {
# We're done parsing options; just copy all remaining arguments directly.
push @commandLine, $arg;
next;
}
+ if ($copyNext) {
+push @commandLine, $arg;
+$copyNext = 0;
+next;
+ }
# Try to interpret Sun-style options.
if ($arg eq '-version') {
@@ -42,8 +50,10 @@
push @commandLine, '--help';
} elsif ($arg eq '-cp' or $arg eq '--cp') {
push @commandLine, '-cp';
+$copyNext = 1;
} elsif ($arg eq '-classpath' or $arg eq '--classpath') {
push @commandLine, '-classpath';
+$copyNext = 1;
} elsif ($arg =~ /^-Djava.library.path=(.+)$/) {
# A component of the JNI search path has been given.
if ($JNIPath) {
@@ -51,7 +61,11 @@
} else {
$JNIPath = $1;
}
- } elsif ($arg eq '-jar' or $arg =~ /^-D/) {
+ } elsif ($arg eq '-jar') {
+# Copy the argument directly.
+push @commandLine, $arg;
+$copyNext = 1;
+ } elsif ($arg =~ /^-D/) {
# Copy the argument directly.
push @commandLine, $arg;
} elsif ($arg =~ /^-/) {
g++ segfaults compiling C++ code
>Submitter-Id: net
>Originator: Olly Betts
>Organization: none
>Confidential: no
>Synopsis: Compiling the attach code causes g++ to segfault
>Severity: serious
>Priority: medium
>Category: c++
>Class: ice-on-legal-code
>Release: 3.0 (Debian) (Debian testing/unstable)
>Environment:
System: Linux roadkill 2.2.19 #1 Sat Jun 9 14:48:14 EST 2001 i686 unknown
Architecture: i686
host: i386-pc-linux-gnu
build: i386-pc-linux-gnu
target: i386-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,objc --prefix=/usr
--infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as
--with-gnu-ld --with-system-zlib --enable-long-long --enable-nls
--without-included-gettext --disable-checking --enable-threads=posix
--enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
>Description:
Compiling the attached file causes g++ to segfault.
I believe the code is legal C++ apart from the template parameter
being declared friend, and since g++ only makes that a warning, it
presumably is allowing the code as an extension to ISO C++.
>How-To-Repeat:
Compile with:
g++-3.0 -O -pedantic -c gcc3.cc
class A {
public:
class I;
I *i;
A(const A&);
virtual ~A()=0;
};
class S {
public:
S(const int &);
~S() { try { } catch(S&) { } }
};
class B {
private:
int m;
public:
bool d() const;
class T {};
};
template class P {
friend T;
private:
T *d;
public:
T *g() const;
P(const P &);
~P();
template P(const P &);
};
inline bool B::d() const { S s(m); return 1; }
template inline P::P(const P &o) : d(o.d) {}
template inline P::~P() { d->d(); }
template
template inline P::P(const P &o) : d(o.g()) {}
template inline T*P::g() const { return d; }
class A::I {
public:
class D;
P d;
};
class A::I::D : public B {
public:
D();
};
A::A(const A &o): i(new A::I(*o.i)) {}
>Fix:
Compiling without optimisation seems to avoid this problem:
g++-3.0 -pedantic -c gcc3.cc
