This was created by a toolchain for cris architecture: gcc-4.2.3,
uClibc-0.9.29, binutils-2.17 compiling openssl-0.9.8h.
[EMAIL PROTECTED]
/work/stage/openwrt2/build_dir/cris/openssl-0.9.8h/crypto/cast $
cris-linux-uclibc-gcc -I.. -I../.. -I../../include -fPIC -DOPENSSL_PIC
-DZLIB_SHARED -DZLIB -
--- Comment #1 from hinko dot kocevar at cetrtapot dot si 2008-06-10 07:31
---
Created an attachment (id=15744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15744&action=view)
preprocessed source that caused the internal compiler error
Created with:
cris-linux-uclibc-gcc -I.. -I
--- Comment #1 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10
07:48 ---
This is actually a lot more serious than just a documentation issue (I've
changed it from a doc issue to a gcc issue) in that the use of this annotation
by the optimizer will break correctly-functioning co
gcc produces an error for the code below:
bit-field.C:6: error: attempt to take address of bit-field structure member
'S::j'
In this case field j is guaranteed to be byte-aligned.
gcc shouldn't have such a rigid requirement that one can't get an address of
any bit field variable but should allow
--- Comment #2 from walter dot zimmer at dlr dot de 2008-06-10 08:11
---
The workaround works fine, many thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36476
--- Comment #4 from aldot at gcc dot gnu dot org 2008-06-10 08:18 ---
pristine trunk is also broken:
sort.i:10318: internal compiler error: in insert_save, at caller-save.c:787
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-10 08:25 ---
No this is not a non documentation bug as non-null attribute says that the
argument has to be non null to work correctly. So if you pass a NULL argument
to the function, it will crash. So optimizing out the check fo
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:25 ---
This is required by the C/C++ standards.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36483
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
To reproduce the bug, get MPFR trunk, compile with CC=g++ (with or without
optimizations) and make check. The crash occurs on tprintf (and tsprintf and
tfprintf). I could reproduce it with both
g++-4.2 (GCC) 4.2.4 (Debian 4.2.4-2)
g++.real (Debian 4.3.1-1) 4.3.1
No problem with gcc.
(gdb) run
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:52 ---
Your configure line should not have LD_LIBRARY_PATH set.
Also this works for me ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:54 ---
You should try out 4.3.1. Also this is not a good testcase, we need the
preprocesed source that is producing the error with the exact command line that
is used to compile that file.
--
pinskia at gcc dot gnu dot
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-10 09:07 ---
The GCC attribute is an extension. What it is about is saying if it is NULL
then the program/function will crash and is not expecting a NULL argument. So
if you mark a function argument as non NULL, then the optimi
--- Comment #2 from vincent at vinc17 dot org 2008-06-10 09:09 ---
(In reply to comment #1)
> You should try out 4.3.1.
As I said, I could reproduce the problem with this version too (but there's a
bug in gmp.h, so I was not sure).
--
vincent at vinc17 dot org changed:
W
--- Comment #3 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10
09:02 ---
It's more than just a documentation bug, two different portions of gcc are
interpreting this attribute in completely different ways, and the interaction
between the two breaks otherwise perfectly valid cod
--- Comment #5 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10
09:15 ---
>Think printf with %s where it is supplied with a NULL argument or puts
>with a NULL argument.
Sure, I understand how that part of it works, but gcc doesn't just use it for
that, it applies two often mut
--- Comment #7 from pgut001 at cs dot auckland dot ac dot nz 2008-06-10
09:27 ---
>The developer of the API says that it must be non-NULL so when the developer
>of the API then tests for NULLness he is either being stupid or really just
>thinking that the user will not use it correctly
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-10 09:19 ---
>gcc doesn't just use it for that, it applies two often mutually exclusive
>interpretations to the same
> attribute.
They are no mutually exclusive at all. Think of it is this way. The developer
of the API says t
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-10 09:50 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-10 09:54 ---
Waiting for a testcase. Also, can you show disassembly of the relevant region
of code?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from cnstar9988 at gmail dot com 2008-06-10 10:07 ---
I build gcc 4.3.1 with --with-cld
./src/configure --prefix=/opt/gcc-4.3.1 --with-gmp=/opt/gcc-4.3.1/gmp
--with-mpfr=/opt/gcc-4.3.1/mpfr --enable-languages=c,c++ --disable-nls
--enable-bootstrap --disable-shared --enabl
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-10 09:56 ---
This works as designed (and documented). Whether the design is the best
possible
one is another question.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-10 09:51 ---
The diagnostic is required by the standard.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from bunk at stusta dot de 2008-06-10 10:11 ---
Created an attachment (id=15745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15745&action=view)
Mirco's usbcore.o
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
--- Comment #11 from bunk at stusta dot de 2008-06-10 10:28 ---
(In reply to comment #7)
> Looking at http://www.readcode.org/code/linux-2.6.20/include/linux/log2.h it
> seems that either the argument to ilog _is_ zero or the compiler thinks so.
If you disassemble Mirco's usbcore.o you'
--- Comment #3 from uros at gcc dot gnu dot org 2008-06-10 10:30 ---
Subject: Bug 36473
Author: uros
Date: Tue Jun 10 10:29:36 2008
New Revision: 136615
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136615
Log:
PR target/36473
* config/i386/i386.c (ix86_tune_fea
--- Comment #12 from aldot at gcc dot gnu dot org 2008-06-10 11:07 ---
smallish testcase, fwiw.
$ gcc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -fno-stack-protector
-mregparm=3 -freg-struct-return -mpreferred-
--- Comment #16 from rguenther at suse dot de 2008-06-10 10:56 ---
Subject: Re: [4.3/4.4 Regression] cld instruction is not
emitted anymore.
On Tue, 10 Jun 2008, cnstar9988 at gmail dot com wrote:
> --- Comment #15 from cnstar9988 at gmail dot com 2008-06-10 10:07 ---
> I bu
--- Comment #13 from aldot at gcc dot gnu dot org 2008-06-10 11:20 ---
should have been
int argh(void) __attribute__((error ("dce?")));
works without __builtin_constant_p and fails even with
-Os -ftree-dce -fweb -ftree-fre -ftree-pre
pr36359.c: In function 'foo':
pr36359.c:7: error: ca
i've configured gcc in this way:
$ ./xgcc -B. -v
Reading specs from ./specs
Target: x86_64-gnu-linux
Configured with: ../configure --target=x86_64-gnu-linux --with-arch=k8
--prefix=/local/devel/toolchain43/x86_64-gnu-linux
--with-sysroot=/local/devel/toolchain43/x86_64-gnu-linux
--libdir=/local/d
--- Comment #4 from vincent at vinc17 dot org 2008-06-10 11:26 ---
cmpb$42, -481(%rbp)
je .L458
jmp .L456
.L463:
cmpb$85, -481(%rbp)
je .L461
cmpb$90, -481(%rbp)
je .L462
jmp .L456
.L458:
--- Comment #9 from joseph at codesourcery dot com 2008-06-10 11:53 ---
Subject: Re: Use of the 'nonnull' attribute breaks
code
On Tue, 10 Jun 2008, pgut001 at cs dot auckland dot ac dot nz wrote:
> fully correct code suddenly breaks. In fact gcc seems to be doing the
> opposite
>
--- Comment #5 from ubizjak at gmail dot com 2008-06-10 11:58 ---
(In reply to comment #4)
> vasprintf.c:1846: note: (so you should pass 'int' not 'mpfr_rnd_t' to
> 'va_arg')
> vasprintf.c:1846: note: if this code is reached, the program will abort
>
> I don't know if this is related,
--- Comment #6 from vincent at vinc17 dot org 2008-06-10 12:37 ---
OK, but shouldn't g++ generate a SIGABRT instead of a illegal instruction? I've
never had thought that a compiler should generate an illegal instruction on
purpose, so making me think that the problem comes from the compi
--- Comment #7 from ubizjak at gmail dot com 2008-06-10 13:33 ---
Here is a short explanation from config/i386/i386.md on this matter:
--cut here--
;; We used to use "int $5", in honor of #BR which maps to interrupt vector 5.
;; That, however, is usually mapped by the OS to SIGSEGV, whi
--- Comment #8 from vincent at vinc17 dot org 2008-06-10 14:02 ---
I agree about SIGSEGV. But what about abort()? Wouldn't this be cleaner? This
builtin trap is quite similar to a failed assertion (often used to avoid
undefined behavior), isn't it?
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-10 14:38 ---
Calling abort() doesn't work with free-standing environments. To answer the
other questions we still need a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
g++ (at least versions 3.3.5, 3.4.4 and 4.1.1) accepts the following code,
which I think is ill-formed:
template struct F {};
template
int f(R (C::*f)() const, const F &n = F()) { return 0; } // f0
template
int f(const R &(C::*f)() const, const F &n = F()) { return 1; } // f1
struct X { const
--- Comment #1 from richard-gccbugzilla at metafoo dot co dot uk
2008-06-10 14:51 ---
FWIW, Microsoft's recent compilers agree that this is ill-formed also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36486
--- Comment #10 from vincent at vinc17 dot org 2008-06-10 14:52 ---
(In reply to comment #9)
> Calling abort() doesn't work with free-standing environments.
OK, but how about using an illegal instruction with free-standing environments
and abort() with hosted ones? After all, the abort(
--- Comment #11 from vincent at vinc17 dot org 2008-06-10 15:21 ---
Here's the testcase (I've never used va_list and so on myself, so I hope it is
correct; at least it shows the missing warning problem). With gcc -Wall
-std=c99 -Wc++-compat -pedantic -Wextra, I don't get any warning conc
--- Comment #5 from gunnar at greyhound-data dot com 2008-06-10 15:24
---
(In reply to comment #4)
> Could you please submit your patch to [EMAIL PROTECTED], including a
> ChangeLog entry and stating how you tested it.
>
As requested I did send the email last week.
Do you need anythin
The code generation by GCC 4.4 (trunk) for 68K/Coldfire will run slow on the
SuperScalar pipelines of the 68060 and Coldfire V4/V5 cores.
if you compilining this example:
uint32_t fletcher( uint16_t *data, size_t len )
{
uint32_t sum1 = 0x, sum2 = 0x;
while (len) {
--- Comment #3 from eric dot weddington at atmel dot com 2008-06-10 15:43
---
Fixed for 4.4.0.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #5 from eric dot weddington at atmel dot com 2008-06-10 15:43
---
Fixed for 4.4.0.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
+++ This bug was initially created as a clone of Bug #36487 +++
The code generation by GCC 4.4 (trunk) for 68K/Coldfire will run slow on the
SuperScalar pipelines of the 68060 and Coldfire V4/V5 cores.
if you compilining this example:
uint32_t fletcher( uint16_t *data, size_t len )
{
ui
--- Comment #2 from gunnar at greyhound-data dot com 2008-06-10 16:02
---
> Note that
>
> cmp.l #65535,%d0
> jbhi .L10
>
> can be replaced with
>
> swap %d0
> tst.w %d0
> jbne .L10
>
> A similar trick can be applied to signed comparisons as w
Hi,
This code :
int t[10][10] = {
[1][2] = 1,
[1][3] = 2
};
warns with "initialized field overwritten" under -Wextra with gcc 4.3.0,
although it's perfectly valid.
Antoine Levitt
--
Summary: Warning "initialized field overwritten" wrongly trigge
gcc returns:
niko.cpp: In function 'int gun()':
niko.cpp:7: error: 'A::A(const A&)' is private
niko.cpp:20: error: within this context
when compiling:
struct A {
A() ;
int fun() const ;
private:
A( const A& ) ;
} ;
int hun( const A& a ) {
return a.fun()*4 ;
}
int gun() {
--- Comment #60 from giovannibajo at libero dot it 2008-06-10 17:26 ---
If a knowledgable GCC developer could suggest *any* workaround at -O1 for this
bug in 4.2 (including disabling whatever alias analysys causes the problem), it
might be proposed as a fix within distros at least.
--
Gcc 4.2.4 (also 4.2.3) built for Solaris versions 2.5.1, 8 and 10 does not
handle a command line macro if the definition contains spaces. This was
discovered while building Ghostscript. Following is an example.
> gcc -DGX_COLOR_INDEX_TYPE="unsigned long long" test.c
gcc: long: No such file or di
I'm using the latest trunk version of gfortran. File gcc-trunk-x86_64.tar.gz.
Downloaded today, Tues., June 10, 2008.
For this line of code:
CHARACTER (MAX_FLD_HED, ASCIICharacterKind) :: DWFdHd(MAXFLD) = [(" ", i =
1, MAXFLD)]
the compiler issues the following error message:
Error: The CHAR
--- Comment #5 from vmakarov at gcc dot gnu dot org 2008-06-10 19:02
---
Subject: Bug 36450
Author: vmakarov
Date: Tue Jun 10 19:01:37 2008
New Revision: 136638
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136638
Log:
2008-06-10 Vladimir Makarov <[EMAIL PROTECTED]>
--- Comment #6 from aldot at gcc dot gnu dot org 2008-06-10 19:34 ---
Can you please also fix trunk?
Thanks alot
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from aldot at gcc dot gnu dot org 2008-06-10 19:42 ---
Fixed on the IRA branch.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
St
The following code aborts if built for i686-pc-linux-gnu with -msse2 -O3.
extern void abort (void);
int
main (void)
{
int i;
long x[12] __attribute__((aligned(16)));
x[0] = 1;
for (i = 0; i < 12; i++)
x[i] = i;
if (x[0] != 0)
abort ();
return 0;
}
The loop gets vectorized usin
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 20:18 ---
Are you sure that your gcc program is not a shell script that calls the real
gcc program.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from schulz at adi dot com 2008-06-10 20:45 ---
I just checked and it is a shell script. I should have thought of that.
Sorry for the noise.
--
schulz at adi dot com changed:
What|Removed |Added
-
I've seen this bug in 4.1.2, 4.2.0, 4.2.1, 4.2.2, 4.3.0 and 4.3.1 (and at least
with the version 4.1.2 and 4.3.0 of the avr-gcc-c++-compiler). What happens is
that when a char array gets a value assigned through a quoted string, the data
gets corrupted (or lost) in the compilation, but if it's init
--- Comment #2 from peterbindels at gmail dot com 2008-06-10 21:32 ---
It's still warning free on 4.3.1 (except with all turned on, when ti complains
about unused parameters but nothing else).
As far as I can tell the second template matches the subset of the matches for
the first templ
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
GCC ta
--- Comment #7 from hjl dot tools at gmail dot com 2008-06-10 22:05 ---
Please note that some mode alignments are the hard requirement.
This problem will go away after stack branch is merged with
trunk.
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #2 from mueller at gcc dot gnu dot org 2008-06-10 22:14 ---
so the code should be changed to
#elif defined(BOOST_PP_ITERATION_DEPTH) && BOOST_PP_ITERATION_DEPTH() == 1
?
it is confusing that #elif behaves more like "#if" and not like "#else\n#if"
--
http://gcc.gnu.org
--- Comment #2 from david dot kirkby at onetel dot net 2008-06-10 22:37
---
Subject: Re: gcc fails to build on Solaris x86 - it
forgets the locations of libmpfr
pinskia at gcc dot gnu dot org wrote:
> --- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:52
> ---
--- Comment #20 from jorg dot brown at gmail dot com 2008-06-11 00:07
---
Interesting, but I'm not sure this can legally be done.
Consider:
struct POD {
int x;
int y;
};
struct nonPOD {
int x;
int y;
nonPOD(int xx, int yy) : x(xx), y(yy) { }
};
I, for one, would love to se
--- Comment #4 from kkojima at gcc dot gnu dot org 2008-06-11 01:27 ---
Created an attachment (id=15746)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15746&action=view)
patch
>From the reports on gcc-testresults, cdce3.C fails on some
other targets:
arm-none-linux-gnueabi
http:/
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-06-11 02:17
---
Well if done correctly the compiler would see that nonpod.x was used for the
initialization and inline it as zero :). So really this can be still done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4131
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2008-06-11 02:35
---
Please post command line used to compile and assembler produced.
I cannot reproduce this on 4.4 or 4.2.2.
At high optimisation (-Os) it compiles to load PORTC with 3 directly.
(as one would expect):
13
--- Comment #10 from pgut001 at cs dot auckland dot ac dot nz 2008-06-11
03:47 ---
>13. Unlike for C9X, the consensus at the London meeting was that there should
>be no invention, without exception. Only those features that have a history
>and are in common use by a commercial implement
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-11 05:36 ---
Can you post a *complete* example? I tried to create a program based on your
single line, but here it simply works.
I tried both (gfortran -v) 4.4.0 20080609 [trunk revision 136577]
and 4.4.0 20080610 [trunk
and b[0] for equality with 0x3a)
are true.
This is with WinAVR 20080610 (4.3.0 + patches).
Please give us more information to be able to reproduce the problem.
--
eric dot weddington at atmel dot com changed:
What|Removed |
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:27 ---
Subject: Bug 36469
Author: jakub
Date: Wed Jun 11 06:27:04 2008
New Revision: 136650
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136650
Log:
PR libgomp/36469
* configure.ac: Add AC_CHECK_FUN
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-11 06:31 ---
Subject: Bug 36408
Author: jakub
Date: Wed Jun 11 06:30:55 2008
New Revision: 136651
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136651
Log:
PR c++/36408
* semantics.c (stmt_expr_value_expr)
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:44 ---
This ought to be fixed on the trunk - BT_BOOL is the C _Bool type even in
Fortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36208
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-11 06:48 ---
Subject: Bug 36408
Author: jakub
Date: Wed Jun 11 06:47:36 2008
New Revision: 136652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136652
Log:
PR c++/36408
* semantics.c (stmt_expr_value_expr)
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-11 06:48 ---
Fixed on the trunk as part of the OpenMP 3.0 support.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-11 06:53 ---
That's correct actually.
omp_set_num_threads sets the NTHREADS_VAR ICV, i.e. something that will be used
to determine the number of threads of the next #pragma omp parallel.
omp_get_num_threads returns the number of th
77 matches
Mail list logo
