--- Comment #15 from jakub at gcc dot gnu dot org 2008-06-09 06:59 ---
"Unless you can find a way to localize those environment changes only to
the tested compiler (by setting/restoring them around every call to the
compiler being tested for example), HOSTCC must set/clear all the
env
compiling trunk version 136578 failed. my $FFLAGS includes "-fimplicit-none".
omp_lib.f90:268.10:
function omp_get_ancestor_thread_num_8 (level)
1
Error: Symbol 'omp_get_ancestor_thread_num_8' at (1) has no IMPLICIT type
omp_lib.f90:281.10:
function omp_get_team_siz
AVR fails gcc.dg/utf32-1.c execution test.
As AVR has 16 bit int, I tried fixing this by using unsigned long for char_32.
This failed, I was surprised to find this is apparently due to incorrect size
of UTF-32 characters so that:
sizeof (U'\0')
sizeof (U'\u2029')
sizeof (U'\U00064321')
all giv
--- Comment #14 from hjl dot tools at gmail dot com 2008-06-09 02:28
---
(In reply to comment #13)
> Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
> with unstalled gcc
>
> hjl dot tools at gmail dot com wrote:
>
> 1. User puts libraries/headers in $pefix/{lib,include}
--- Comment #13 from mark at codesourcery dot com 2008-06-09 00:05 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
1. User puts libraries/headers in $pefix/{lib,include}
2. User builds GCC with correspondin
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-08 22:54
---
(In reply to comment #11)
> Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
> with unstalled gcc
>
> hjl dot tools at gmail dot com wrote:
>
> >> I suspect that if you remove the setting in site.exp you
--- Comment #5 from paolo dot carlini at oracle dot com 2008-06-08 21:28
---
Fixed for 4.4.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo at gcc dot gnu dot org 2008-06-08 21:26 ---
Subject: Bug 35242
Author: paolo
Date: Sun Jun 8 21:25:49 2008
New Revision: 136569
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136569
Log:
/cp
2008-06-08 Paolo Carlini <[EMAIL PROTECTED]>
PR c+
--- Comment #11 from mark at codesourcery dot com 2008-06-08 21:12 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
>> I suspect that if you remove the setting in site.exp you will break the
>> following scenario:
>>
--- Comment #10 from hjl dot tools at gmail dot com 2008-06-08 20:45
---
(In reply to comment #9)
> Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
> with unstalled gcc
>
> hjl dot tools at gmail dot com wrote:
>
> > How does gcc search the right paths when GCC_EXEC_PREFIX po
--- Comment #9 from mark at codesourcery dot com 2008-06-08 20:23 ---
Subject: Re: [4.3/4.4 Regression]: HOSTCC doesn't work
with unstalled gcc
hjl dot tools at gmail dot com wrote:
> How does gcc search the right paths when GCC_EXEC_PREFIX points
> to non-existent directory because
--- Comment #2 from gcc at david dot osborn dot name 2008-06-08 20:01
---
Created an attachment (id=15738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15738&action=view)
compiler output
This shows bad code being generated. The return value (12345) gets pushed into
eax on line
--- Comment #1 from aldot at gcc dot gnu dot org 2008-06-08 20:00 ---
Created an attachment (id=15737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15737&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36468
--- Comment #1 from gcc at david dot osborn dot name 2008-06-08 19:55
---
Created an attachment (id=15736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15736&action=view)
reduced testcase
This bug still exists in GCC 4.3.1. I've narrowed it down to line 183 in
bits/basic_ios.tc
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
CC||danglin at gcc dot gnu dot
|
The build of libgomp fails due to the use of strtoull in env.c
HPUX-PA does not know about this function, officially. On 32-bit the function
is available but not headerwise. On 64-bit this function is not available at
all.
The following snippet added to env.c cures the issue:
Index: env.c
==
$ /there.pentium4/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc -c
regex.i -o regex.o -Wall -std=gnu99 -Os -Wfatal-errors -flto -v
Using built-in specs.
Target: i686-linux-uclibc
Configured with: /there.pentium4/toolchain_build_i686/gcc-4.4.0/configure
--prefix=/there.pentium4/build_i686/sta
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-06-08 18:20
---
It makes sense in one respect
We don't have fast shift by 4 bits and code defaults to loop for Os. Seems we
should be selective as MUL is indeed shorter.
Though I think gcc may be confused by our poor cost d
--- Comment #3 from eric dot weddington at atmel dot com 2008-06-08 18:08
---
Generated code when structure size is 16 (test.i):
funct:
/* prologue: function */
/* frame size = 0 */
lds r24,head
mov r30,r24
clr r31
sbrc r30,7
com r31
ldi
--- Comment #2 from eric dot weddington at atmel dot com 2008-06-08 17:58
---
Created an attachment (id=15735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15735&action=view)
Test case with structure size == 17.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
--- Comment #1 from eric dot weddington at atmel dot com 2008-06-08 17:57
---
Created an attachment (id=15734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15734&action=view)
Test case with structure size == 16.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36467
>From AVR Freaks forum:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=453770#453770
Adding an offset to a pointer to a structure. If the structure size is 16, the
generated code is a loop with shifts. If the structure size is 17, the
generated code uses MUL* instructions and ge
--- Comment #4 from eric dot weddington at atmel dot com 2008-06-08 17:32
---
Fixed for 4.4.0.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #2 from manu at gcc dot gnu dot org 2008-06-08 17:32 ---
Anyway, this won't work at all until bug 34389 is fixed because fold with
convert each operand to the target type before considering the bit_and_expr.
--
manu at gcc dot gnu dot org changed:
What|Re
--- Comment #10 from manu at gcc dot gnu dot org 2008-06-08 17:30 ---
(In reply to comment #9)
> Does the patch also fix the warning for conditional expressions? For example:
>
> short f(int cond, short x, short y)
> {
> return cond ? x : y;
> }
>
No, that is a completely different
--- Comment #1 from manu at gcc dot gnu dot org 2008-06-08 17:25 ---
Ideally, one could just do:
msp->small = (unsigned int:1) sm;
Meanwhile, we will need to check that when converting to p bits that the mask
is less than 2^p - 1. I wonder if we already have a function to do that.
--- Comment #3 from s_gccbugzilla at nedprod dot com 2008-06-08 17:19
---
Created an attachment (id=15733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15733&action=view)
Failing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
--- Comment #2 from s_gccbugzilla at nedprod dot com 2008-06-08 17:19
---
This problem actually seems to be one of subclassing: child class rvalue
constructors invoke base class lvalue constructors!!!
I have attached an example. As is, it compiles and works. If however you throw
a Thin
--- Comment #1 from s_gccbugzilla at nedprod dot com 2008-06-08 17:07
---
Created an attachment (id=15732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15732&action=view)
Test Case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36461
--- Comment #2 from manu at gcc dot gnu dot org 2008-06-08 16:50 ---
In C++ we have:
unit size
align 8 symtab 0 alias set -1 canonical type 0x2b4fb9c0 precision 1
min max >
In C we have:
unit size
align 32 symtab 0 alias set -1 canonical type
--- Comment #1 from manu at gcc dot gnu dot org 2008-06-08 16:45 ---
Confirmed.
Notes:
foo.x = bar != 0; // only warns in C, not in C++.
foo.x = bar != 0 ? 1 : 0; // warning is not a problem of bitfields but for
every conditional expression, the following also warns
short x = (bar !=
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-06-08 16:37 ---
Note that a native build should be done to verify that my patch increases the
stack limit enough to fix this bug, before marking it fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36218
--- Comment #5 from jsm28 at gcc dot gnu dot org 2008-06-08 16:15 ---
Subject: Bug 36218
Author: jsm28
Date: Sun Jun 8 16:14:33 2008
New Revision: 136563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136563
Log:
PR tree-optimization/36218
* Makefile.def (flags_
--- Comment #3 from aesok at gcc dot gnu dot org 2008-06-08 16:08 ---
Subject: Bug 36424
Author: aesok
Date: Sun Jun 8 16:08:08 2008
New Revision: 136562
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136562
Log:
PR target/36424
* config/avr/avr.h (HARD_REGNO_RE
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-08 15:45
---
(In reply to comment #8)
> HJ, are you willing to prepare and test a patch? Many thanks in advance.
>
Sorry, I may not have time for it in the near future.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2881
--- Comment #4 from manu at gcc dot gnu dot org 2008-06-08 15:37 ---
Not target/host specific.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
GCC build trip
--- Comment #3 from manu at gcc dot gnu dot org 2008-06-08 15:36 ---
Confirmed.
The relevant gimple dump is:
int main(int, const char* const*) (D.2050, D.2051)
{
struct stringD.2032[0] * retval.0D.2067;
struct stringD.2032[0] * D.2055;
struct stringD.2032[0] * D.2056;
long intD
--- Comment #1 from aurelien at aurel32 dot net 2008-06-08 14:31 ---
Created an attachment (id=15731)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15731&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466
gcc fails to build the attached testcase with optimization levels above -O0.
The problem occurs with all versions from the gcc 4.x branch. Versions gcc 3.x
do not expose the problem. Note that the ICE occurs on both old-ABI and EABI.
Using built-in specs.
Target: arm-linux-gnueabi
Configured with:
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-06-08 14:12 ---
*** Bug 36465 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-08 14:12 ---
fipa-pta is known to be broken, don't use it.
*** This bug has been marked as a duplicate of 29212 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pattakosn at yahoo dot com 2008-06-08 14:10 ---
(In reply to comment #2)
> I downloaded and compiled 4.3.1 which seems to work well.
I am sorry, maybe I was not clear. I meant that I downloaded and compiled 4.3.1
and 4.4-20080606 and then gfortran 4.3.1 compiles my s
--- Comment #3 from pattakosn at yahoo dot com 2008-06-08 14:06 ---
Created an attachment (id=15730)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15730&action=view)
the file that the latest gfortran (4.4-20080606) fails to compile and the
produced .s file
This is the file relevan
--- Comment #2 from pattakosn at yahoo dot com 2008-06-08 13:49 ---
I downloaded and compiled 4.3.1 which seems to work well.
However I also downloaded the latest snapshot (4.4-20080606) and I get an other
bug :
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/nima
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from janus at gcc dot gnu dot org 2008-06-08 12:16 ---
Fixed in rev 136555. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pattakosn at yahoo dot com 2008-06-08 12:05 ---
Created an attachment (id=15729)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15729&action=view)
The source code and the generated .s file
This is the source file that crashes and the .s file that is generated.
--- Comment #1 from dominiq at lps dot ens dot fr 2008-06-08 12:01 ---
The code in comment #1 of PR35971 compiles without error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
--- Comment #4 from janus at gcc dot gnu dot org 2008-06-08 11:56 ---
Subject: Bug 36459
Author: janus
Date: Sun Jun 8 11:55:41 2008
New Revision: 136555
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136555
Log:
2008-06-08 Janus Weil <[EMAIL PROTECTED]>
PR fortran/3
There is a simulation code that I am trying to make run faster by trying
several compile optimization flags. It also uses OpenMP to utilize multiple
cores. Today I got this:
Driving: /home/nimar/opt/gcc-4.3.0/bin/gfortran -v -save-temps
-I/home/nimar/opt/gcc-4.3.0/include -O3 -fimplicit-none -fope
--- Comment #1 from mycae at yahoo dot com 2008-06-08 11:29 ---
It still crashes when I write my code properly too.
$ gcc -c -Wall --ansi -Wno-deprecated --verbose -save-temps -g -DDEBUG
`wx-config --cflags` -o wxsimple.o wxsimple.cpp
Using built-in specs.
Target: i386-redhat-linux
Co
To be honest, I don't know what some of these bug fields mean (triplet??), so
if you need more info please let me know.
I am trying to use precompiled headers to speed up my development time when
using wx-widgets. All of my source files crash when attempting to compile any
of them
Header file
---
--- Comment #1 from burnus at gcc dot gnu dot org 2008-06-08 11:20 ---
Note: Initially found by James Van Buskirk:
http://groups.google.com/group/comp.lang.fortran/msg/e90575a5a6a50e35
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
On i686-apple-darwin9 with revision 136554, I get the following ICEs on the
codes from pr35971 and the two codes from
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff7ae6c7a7860bca/60213205751117d4
(see pr36322):
pr35971.f90: In function 'gp':
pr35971.f90:46: internal co
--- Comment #15 from burnus at gcc dot gnu dot org 2008-06-08 07:50 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from burnus at gcc dot gnu dot org 2008-06-08 07:49 ---
Subject: Bug 35830
Author: burnus
Date: Sun Jun 8 07:48:53 2008
New Revision: 136554
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136554
Log:
2008-06-08 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
56 matches
Mail list logo