I think the problem is valgrind's Makefiles are passing -mcpu=cortex-a8
to the compiler. Cortex-a8 has Neon and the compiler now makes use of that.
On the subject of the configuration of GCC
--with-arch=armv7-a+fp
*is* the correct configuration for the baseline GCC; it adds a vfpv3
with 16
On 17/09/2021 11:23, Florian Weimer via Gcc wrote:
* Matthias Klose:
Starting with GCC 8, the configury allows to encode extra features into the
architecture string. Debian and Ubuntu's armhf (hard float) architecture is
configured with
--with-arch=armv7-a --with-fpu=vfpv3-d16
and now
On Wed, 30 Sep 2020, Ahzo wrote:
>
> Sep 29, 2020, 07:14 by rguent...@suse.de:
>
> > I've filed > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97236
> >
> > Someone needs to create a testcase or provide instructions how to
> > reproduce the bug.
> >
>
> Thanks for taking care of this issue
On Mon, 28 Sep 2020, Ahzo wrote:
> Control: reassign -1 gcc-10 10.2.0-9
> Control: retitle -1 gcc-10: regression in 10.2.0-9 causes segmentation fault
> in vlc
> Control: affects -1 vlc
> Control: severity -1 serious
>
> Hi,
>
> the vlc crash is caused by a compiler regression introduced in
Package: g++-5
Version: 5.2.1-23
$ type g++-5
g++-5 is /usr/bin/g++-5
$ dpkg -l g++-5 libstdc++-5-dev
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name
Package: libstdc++6
Version: 5.1.1-11
richard@deodand:~/junk$ cat t.cc
#include iostream
int main() {
std::cout std::hex;
return 0;
}
richard@deodand:~/junk$ clang++-3.6 -fsanitize=undefined -O0
-fno-optimize-sibling-calls -fno-omit-frame-pointer -g -o t t.cc
richard@deodand:~/junk$ ./t
to
‘__fread_chk_warn’ declared with attribute warning: fread called with
bigger size * nmemb than length of destination buffer
return __fread_chk (__ptr, __bos0 (__ptr), __size, __n, __stream);
^
richard@deodand:~/src/vbig$ dpkg -l libc6-dev gcc-4.9
Desired=Unknown/Install/Remove/Purge/Hold
good though.
Thanks,
Richard
--
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/8761n2eab2@sandifor-thinkpad.stglab.manchester.uk.ibm.com
with
that change -- I'll just make it locally before committing -- but please
give an idea how it's been tested.
Thanks,
Richard
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https
Yunqiang Su wzss...@gmail.com writes:
I think so.
Richard is the guy for upstream ?
Hmm, this still looks multiarch-related to me. It looks like it's changing
the default ABI for mips64-linux-gnu from n32 to n64. That might be right
for a Debian multiarch environment but all upstream mips64
/x86_64-linux-gnu/libXrandr.so.2.2.0
7fc1c5c34000-7fc1c5c35000 rw-p 7000 08:01 22931264
/usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
7fc1c5c35000-7fc1c5c9b000 r-xp 08:01 27312150
/home/richard/test/Diablo/DiabloMiner/target/libs/natives/linux
On Thu, Jul 14, 2011 at 06:47:28PM +, Thorsten Glaser wrote:
Richard dixit:
equiv_constant is called with NULL pointer, I would think this is
illegal and the problem happened one level up :
Probably.
(gdb) frame 1
#1 0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0
and
the problem
happened one level up :
#2 0x804b05fe in fold_rtx (x=0xc83c4f30, insn=0xc83cc1c0) at
../../src/gcc/cse.c:3279
Richard
---
Name and OpenPGP keys available from pgp key servers
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
$ pstotext /usr/share/doc/libstdc++6-4.3-doc/libstdc++/html/_form0.ps
GPL Ghostscript 8.62: Unrecoverable error, exit code 1
...specifically it is failing to open _form0.eps, which does not exist.
However, _form0.eps.gz does exist.
$ pwd
/usr/share/doc/libstdc++6-4.3-doc/libstdc++/html
$
Vincent Lefevre wrote:
I have no problems with:
[..]
This bug should probably be closed (or reassigned, if the problem
is with some sources).
Evidently someone has uploaded gcc-4.4-doc since I reported the bug l-)
I agree that the bug can be closed.
ttfn/rjk
--
To UNSUBSCRIBE, email
I've submitted this upstream (having found that it exists in GCC 4.5.0 too).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44511
ttfn/rjk
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
Package: gcc-doc
deodand:~# apt-get install gcc-doc
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some
reopen 526620
quit
Arthur Loiret wrote:
2009/12/24, Richard Kettlewell r...@terraraq.org.uk:
This function's return type is required to be 'void *' because it is
passed to pthread_create(); but it never actually returns. However,
gcc-4.4 -Wall generates the following warning
reopen 526620
quit
This function's return type is required to be 'void *' because it is
passed to pthread_create(); but it never actually returns. However,
gcc-4.4 -Wall generates the following warning for it:
playrtp.c: In function ‘queue_thread’:
playrtp.c:327: error: no return statement in
Hello,
Matthias Klose wrote:
please could you forward this upstream, and add the upstream link to the report?
I was slightly surprised to receive this reply as the bug reporting
instructions explicitly said I shouldn't do that:
Don't file bugs upstream
If you file a bug in Debian,
Package: gcc-4.4
Version: 4.4.0-1
I have the following code:
static void *queue_thread(void attribute((unused)) *arg) {
struct packet *p;
for(;;) {
/* Get the next packet */
pthread_mutex_lock(receive_lock);
while(!received_packets) {
pthread_cond_wait(receive_cond,
ed, section
17.4.1.7, page 489, Stroustrup says simply Erasing end() is harmless, which
I interpret as it has no effect.
Cheers,
Richard
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.28.7
!
Thanks,
Richard.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--- Comment #12 from richard dot guenther at gmail dot com 2007-11-08
09:08 ---
Subject: Re: [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely
recursive functions
On 11/7/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch keeps recursive functions from being
¡Tengo nueva dirección de correo!Ahora puedes escribirme a: [EMAIL PROTECTED]
- RICHARD OPENE
--- Comment #14 from richard at codesourcery dot com 2007-09-05 21:08
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
I've not forced -EB because that fails for -EL
multilibs, and we
--- Comment #16 from richard at codesourcery dot com 2007-09-05 21:22
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
My concern was that the bug only occurs for me with -EB, so running
--- Comment #18 from richard at codesourcery dot com 2007-09-05 21:44
---
Subject: Re: internal compiler error: in print_operand_reloc, at
config/mips/mips.c:5579
ddaney at avtrex dot com [EMAIL PROTECTED] writes:
richard at codesourcery dot com wrote:
--- Comment #16 from
Package: gcc-4.1
Version: 4.1.2-12
Severity: serious
I am not a package maintainer but think that this might be of interest
to you. There appears to be a problem when trying to link static libraries
using gcc on Debian amd64. The linker tries to link gcc (statically?)
and claims that it cannot
Package: gcc-4.1
Version: 4.1.2-8
Severity: important
Code that compiles/links fine on an x86 platform, using PIE fails to
link on amd64 - looks like crt1.o wasn't built -fPIC on amd
$ cc -g -Wall -O2 -fstack-protector-all -z relro -z now -fPIE
-Wl,-z,relro -Wl,-z,now -Wl,-pie
Subject: g++: Fails to compile a very simple file
Package: g++
Version: 4.0.3-7
Severity: important
Since an upgrade on Friday 02/02 (IIRC), I can't manage to compile
a very simple program with g++:
[EMAIL PROTECTED] /tmp/bug $ cat hello.cpp
#include iostream
int main()
{
std::cout Hello
Setting CXXFLAGS to -O instead of -O2 at least makde the package
compile. (I don't suppose that g++-4.1_4.1.1-16 made a difference.)
See
http://buildd.debian.org/fetch.cgi?pkg=ginac;ver=1.3.5-3;arch=arm;stamp=1160853197
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
. Apparently, that was not
the only failure. Note, that this time, a module compiled with
-fPIC -DPIC, but not without it.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
? If so, which
number is it?
-richy.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
it upstream. I recommend doing
that.
-richy.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: gcc
Version: 4.0.2-5
This is what happens if you accidentally put a stray semicolon in a
parameter-type-list:
[EMAIL PROTECTED]:~$ cat t.c
int foo(int x;) { }
[EMAIL PROTECTED]:~$ gcc-4.0 --version
gcc-4.0 (GCC) 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
Copyright (C) 2005
no trouble with
it. If I compile my own version of 4.0.1 I have no such problem.
- Richard
--
Richard C. Bilson, Research Assistant | School of Computer Science
[EMAIL PROTECTED] | University of Waterloo
http://plg.uwaterloo.ca/~rcbilson | 200 University Avenue West
Office: DC 3548F
On Wed, Mar 02, 2005 at 10:42:54AM +0100, Matthias Klose wrote:
Richard Zidlicky writes:
Hi,
the problem has been already discussed some time
ago upstream, now ocatve triggered the bug so
it seems the fix should be backported to 3.3
octave problem
http://lists.debian.org
://gcc.gnu.org/ml/gcc/2004-03/msg01007.html
http://gcc.gnu.org/ml/gcc/2004-03/msg01011.html
Attached patches, one per 3.3 and 3.4. I am leaving
tomorrow so the patches are essentially untested
although I have used very similar patch for 3.4
since almost a year.
Richard
--- gcc-3.3.1/gcc/config/m68k
skater is RGK in katharine of beach to k's with reeve.
carbonate am juneau going monogamous to 63159525 be rudy the butte
you can now have Softw @ re out of your p0cket m0ney:
http://hotmail.com.captive.mnlenekn.info/?nCpsVEn85ruMFTTpermute
H!t the ab0ve l!ink now
allotropic is
Package: gcc-3.3
Version: 1:3.3.4-1
Severity: normal
gcc-3.3.4-1 cannot bootstrap current mainline, it miscompiles
gengtype. Upstream cannot reproduce the problem, so it may be
debian patches to the 3.3.4 compiler that cause this problem.
More detailled information in the gcc bugzilla database
On Fri, 30 Apr 2004, I wrote:
I am not aware of a change in interface when turning off -fno-exception!
Is there one?
Just for the record, let me answer my own question:
No, there doesn't seem to be any change in interface.
-richy.
--
Richard B. Kreckel
http://www.ginac.de/~kreckel/
].
Cheers
-richy.
--
Richard B. Kreckel
http://www.ginac.de/~kreckel/
On Wed, 28 Apr 2004, Steffen Röcker wrote:
libcln segfaulted in cln::I_to_digits when I tried to convert numbers to
binary, all other conversions worked.
Thanks for your bugreport. This turns out to be a tricky one: libcln
segfaults in src/integer/conv/cl_I_to_digits.cc:409, right after the
the code in question was a macro in arm.h for 3.3 whereas
it's now a function in arm.c.
2004-02-25 Richard Earnshaw [EMAIL PROTECTED]
* arm.c (arm_legitimate_index_p): For QImode the range of an offset
is -4095...+4095 inclusive.
Phil, were you going to commit the back-port you had
I don't think there is a PR for it since the code in question does not
provoke the bug on a vanilla FSF build.
Now I'm confused. If the bug is not present in 3.3.3, then what is there
to backport?
The bug is present, by inspection.
Or are you saying that the bug is present, but that
reopen 46550
stop
This bug has reappeared at some point in the intervening years (in
libstdc++2.10-dev 2.95.4-11woody now).
Here's a patch to /usr/include/g++-3/std/bastring.h to put it back
right again.
ttfn/rjk
--- bastring.h.orig Sun Jun 8 22:47:05 2003
+++ bastring.h Sun Jun 8
Richard Kettlewell writes:
This bug has reappeared at some point in the intervening years (in
libstdc++2.10-dev 2.95.4-11woody now).
Here's a patch to /usr/include/g++-3/std/bastring.h to put it back
right again.
ttfn/rjk
Sorry, stupid me, it should be:-
--- bastring.h.orig Sun Jun
Maybe I've send the right patch this time; it does at last actually
correspond to the version that lets my code build. Apologies for
faffing.
Under the circumstances you'd better review the patch carefuly though
l-)
ttfn/rjk
--- bastring.h.orig Sun Jun 8 22:47:05 2003
+++ bastring.h Sun
=1.1.5-2arch=mipsstamp=1054072270file=logas=raw
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
an ELF/m68k bug.
important but probably not the solution for this problem.
I will try bootstrapping an unpatched 3.2 release in my
environment.
Richard
to be the version used during the build as well. Haven't
tested this version but the problems I mentioned were much older..
lets see what the new build does.
Richard
, because debian gcc-3.2 cannot build itself!
which binutils are used? Some older versions had bugs that were
only triggered by gcc-3.2
Richard
list to make gcc-3.2 the default
on m68k ?
would be the best solution imho.
AFAIK, the needed libgcc1-compat library is not yet built for m68k
(CCing the glibc people)
Anything new here ?
I hope you have fixed your mailer, last time I found no way to send you
a reply.
Richard
On Wed, 2002-09-25 at 10:05, Richard Earnshaw wrote:
python2.3 now builds fine on arm-linux with this patch. It's not yet
checked into the 3.2 branch.
Why on earth would a real application want to put part of a pointer into a
bit-field? That sounds like it is highly non-portable
template function.
Handled correctly by gcc-3.0.
Richard.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux mickey 2.4.19 #1 Sat Aug 3 13:55:48 CEST 2002 i686
Locale: [EMAIL PROTECTED], LC_CTYPE=
Versions of packages g++ depends on:
ii cpp 2
Package: g++-3.0
Version: 1:3.0.4-6
I can confirm the problem exists for the QGLViewer package (uses
qt, pthreads, GL) - SIGSEGV at the first dynamic_cast. gcc 2.95.x
do not have this problem. gcc-3_0 branch HEAD has the same problem.
The SIGSEGVs vanish, if I remove -lGLU from the final link
Package: g++-3.0
Version: 1:3.0.4-6
I can confirm removing -lGLU from the link command line solves the
same problem with the QGLViewer package (using Qt and GL - linking
with GLU is from the tmake configuration).
Note that this happens on a SuSE 7.2 system, too (g++ from HEAD of the
gcc-3_0
Package: g++-3.0
Version: 1:3.0.4-6
The problem is both libGLU.so and libstdc++ contain the symbol
__dynamic_cast which is used by gcc to apply the cast. Anytime
the GLU one takes over, the SIGSEGVs occour (can be checked by
LD_PRELOADing libGLU to any dynamic_cast using program!).
So libGLU is
to
everyone who contributed insight!
Cheers
-richy.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
to use CLN with other C++ compilers anyway...
Regards
-richy.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
for a couple of years...
Thanx and cheers
-richy.
--
.''`. Richard B. Kreckel
: :' : [EMAIL PROTECTED]
`. `' [EMAIL PROTECTED]
`-http://www.ginac.de/~kreckel/
63 matches
Mail list logo
