--- 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
--- 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 #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 #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 #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: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
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 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
--- 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 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 #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 #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 #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 #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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
GCC ta
--- 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
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 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
-
--- 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
--
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 #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
--- 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 #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]>
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
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
--- 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 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() {
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
--- 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
+++ 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 #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
--- 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
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 #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
--- 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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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:
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
--- 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 #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 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
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 #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
--- 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
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 -
77 matches
Mail list logo
