--- Comment #5 from bauhaus at futureapps dot de 2005-11-29 08:56 ---
Created an attachment (id=10359)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10359action=view)
source file set for the 4.1 Bug Box
To reproduce,
$ cd src
$ gcc -c -gnatwecfijkmruv -gnaty3abcefhiklmnoprstx
--- Comment #35 from marc dot waeckerlin at siemens dot com 2005-11-29
09:13 ---
I had a look in google about #ifdef _REENTRANT, and it gets about 20'200
entries, so this is a widely used funtinality that must not be broken!
Imagine all the code the does the #ifdef _REENTRANT to
--- Comment #36 from marc dot waeckerlin at siemens dot com 2005-11-29
09:27 ---
New information:
_REENTRANT is definitively defined in the headers:
echo | g++ \
-I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \
-E -dM -c - | grep REENTRANT
echo | g++
--- Comment #6 from bauhaus at futureapps dot de 2005-11-29 09:30 ---
Created an attachment (id=10360)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10360action=view)
source file set for the 4.2 Bug Box
To reproduce,
$ cd src
$ gcc -c -gnatwecfijkmruv -gnaty3abcefhiklmnoprstx
--- Comment #37 from marc dot waeckerlin at siemens dot com 2005-11-29
09:33 ---
Correction: The above work around only works, as long, as your file is not
included by another file...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
--- Comment #7 from harald dot vogt at desy dot de 2005-11-29 09:42 ---
(In reply to comment #6)
Subject: Re: sqrt, csqrt may give a wrong result if real part of compex
argument is zero
On Thu, Nov 24, 2005 at 05:05:12PM -, pinskia at gcc dot gnu dot org
wrote:
(In
--- Comment #39 from pcarlini at suse dot de 2005-11-29 10:24 ---
Eric, I'm sorry, any news?!? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-29 11:21
---
Confirmed. Reminds a bit of PR 24705, except here we have an interface only.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from reichelt at gcc dot gnu dot org 2005-11-29 11:26
---
The command line flags -O -fgcse are sufficient to reproduce the bug.
The constructor of DummyType can be omitted.
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-29 11:27
---
Confirmed. Reminds a bit of PR 24705.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-29 11:30
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from ebotcazou at gcc dot gnu dot org 2005-11-29 11:51
---
Eric, I'm sorry, any news?!? Thanks.
Bootstrap was broken last week and I was away for the week-end... I'll need to
re-compute baseline results first, so maybe at the end of this week.
--
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-29 12:00
---
Reduced testcase:
SUBROUTINE s(n)
CHARACTER(LEN=n), EXTERNAL :: a
write(6,*) a(n)
END SUBROUTINE s
The problem, unless I'm missing something, is that the external function a
would need an explicit interface.
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-11-29 12:06
---
(In reply to comment #2)
Reduced testcase:
SUBROUTINE s(n)
CHARACTER(LEN=n), EXTERNAL :: a
write(6,*) a(n)
END SUBROUTINE s
The problem, unless I'm missing something, is that the external function a
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-29 12:12
---
Well, since it relies on uninitialized variables, it's a bit hard to reproduce.
The following code (I believe it is legal) reproducibly fails for me on
i686-linux:
integer dat(5)
dat = (/ 0, 0, 0, 0,
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-11-29 12:29
---
The testcase can be reduced further:
integer dat(5)
dat = (/ 0, 0, 0, 0, 1 /)
write(11) dat,dat,dat,dat
rewind 11
write(11) dat
read(11,end=1008) dat
1008 continue
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2005-11-29 12:47 ---
Subject: Re: sqrt, csqrt may give a wrong result if real part of compex
argument is zero
On Tue, Nov 29, 2005 at 09:42:05AM -, harald dot vogt at desy dot de wrote:
Comment #7 from
the attached program generates wrong code with -O -fstrict-aliasing (-O works),
although -Wstrict-aliasing doesn't issue a warning.
The bug was not present in gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)
(the generated code was OK even with -O3).
The bug is present in :
- gcc version 4.0.1
--- Comment #1 from frederic dot devernay at m4x dot org 2005-11-29 13:30
---
Created an attachment (id=10361)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10361action=view)
test case
this source generates wrong code without issueing a warning, using:
g++ -DMAIN -O
--- Comment #3 from aoliva at gcc dot gnu dot org 2005-11-29 13:50 ---
Sorry, I totally misread the testsuite output.
Can you tell what part of the execution test that fails? I find it very
unlikely that this is a compiler error; it's far more likely to be a linker
failure to handle
--- Comment #4 from aoliva at gcc dot gnu dot org 2005-11-29 13:55 ---
Make it a weak alias, then.
Anyhow, the point is that the alias infrastructure in GCC is available for all
ports. If some port limits what kinds of aliases you can use, then, well, too
bad. But the smarts to get
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-29 13:55 ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01889.html
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #41 from pcarlini at suse dot de 2005-11-29 14:00 ---
Ok, agreed. I'm eager to finally close the oldest open libstdc++ PR... ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-29 14:03 ---
Fixed in 4.0.3 and later by:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01889.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19227
--- Comment #4 from hp at gcc dot gnu dot org 2005-11-29 14:08 ---
Yes, it may be a linker error. This target uses the generic linker machinery
(since linking from ELF to mmo), which is not exactly the hot-path for other
targets.
I know of no particular way of telling *which* part of
--- Comment #5 from ghazi at gcc dot gnu dot org 2005-11-29 14:25 ---
These two patches fixed the problem on mainline/4.1 and need to be backported:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02322.html
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02828.html
I'll do it after testing.
--- Comment #9 from aoliva at gcc dot gnu dot org 2005-11-29 14:27 ---
Created an attachment (id=10362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10362action=view)
Tentative patch to accomodate expressions, absent functions et al
Dave, could you please give this patch a try?
The code below compiles fine with gcc 3.3.1 and 3.4.0 (and does the right
thing); it produces a compile time error in 4.0.2. Lookup of the operator
in the definition of serializable::implX::value fails when it is instatiated
via the bar or baz templates but succeeds when instantiated via the foo
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 15:12 ---
4.2 warns:
t.cc: In function 'CvStatus icvSet_8u_C4MR(int*, int, const uchar*, int,
CvSize, const int*)':
t.cc:21: warning: dereferencing type-punned pointer will break strict-aliasing
rules
Because the warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 15:19 ---
Fixed in 4.0.3 already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 16:01 ---
A start is done on the branch libobjc_noheaders. I almost forgot about
thrd-objc.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24775
I don't know whether it is a bug or not.
Consider the following example:
short int sh1 = 1;
short int sh2 = 2;
printf(Size of short: %d\n, sizeof(short));
printf(Size of int: %d\n, sizeof(int));
printf(Size of expr: %d\n, sizeof(sh1+sh2));
Output:
Size of short: 2
Size of int: 4
Size of expr:
--- Comment #38 from carlo at gcc dot gnu dot org 2005-11-29 16:05 ---
That never works because it always defines _REENTRANT.
You probably mean:
#ifdef _REENTRANT
#define GCC_BUGFIX 1
#endif
#include iostream
#undef _REENTRANT
#ifdef GCC_BUGFIX
#define _REENTRANT 1
#endif
The drawback
bool func()
{
return;
}
a.cc:3: error: return-statement with no value, in function returning 'int'
--
Summary: wrong error message (int instead of bool)
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: minor
Priority:
--- Comment #1 from schwab at suse dot de 2005-11-29 16:13 ---
This is the effect of the integer promotion rules.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 16:40 ---
Confirmed, all an integer types give the wrong error (well except for int).
3.3 gave:
t.c: In function `bool func()':
t.c:3: error: return-statement with no value, in function declared with a
non-void return
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 16:46 ---
Hmm, it is looking at the wrong type, it is looking at the RESULT_DECL's type
instead of the FUNCTION_TYPE's type which has the correct type, I might fix
this later tonight.
--
--- Comment #2 from tromey at gcc dot gnu dot org 2005-11-29 17:09 ---
*** This bug has been marked as a duplicate of 15411 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2005-11-29 17:09 ---
*** Bug 25040 has been marked as a duplicate of this bug. ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tromey at gcc dot gnu dot org 2005-11-29 17:13 ---
Fix checked in everywhere.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-29 17:34 ---
(In reply to comment #5)
Note this was the simple fix which exposes those latent bugs as far as I can
see that should work, we get the correct range but the rest of VRP goes
bonkers:
I should also note it does
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-29 17:36 ---
I should also note that compare_values is does not respect -fwrapv either as
shown by the testcase in PR 25145 in comment #1 and comment #6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25148
--- Comment #3 from frederic dot devernay at m4x dot org 2005-11-29 17:42
---
I know it breaks aliasing rules, but this problem was not present in gcc-3.3.
Most gcc users consider -O2 as being a safe optimizing option, (e.g. redhat
RPMs are compiled with gcc -O2), and generating wrong
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-29 17:47 ---
(In reply to comment #3)
I know it breaks aliasing rules, but this problem was not present in gcc-3.3.
So ...
GCC 4.1 includes more optimization than 3.3 did which takes advantage of the
aliasing rules.
Note
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-29 17:48
---
Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of
bool)
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Hmm, it is looking at the wrong type, it is looking at the
--- Comment #5 from bonzini at gnu dot org 2005-11-29 17:55 ---
Frederic, -Wstrict-aliasing is only working for C up until 4.1 (included).
Your code, rewritten to C, would issue a warning with 4.1 and earlier compilers
as well. Also note that -Wstrict-aliasing does not prevent the
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-29 18:02
---
Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of
bool)
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Hmm, it is looking at the wrong type, it is looking at the
make[1]: Entering directory `/xxx/gnu/gcc-3.3/objdir/libdecnumber'
source='../../gcc/libdecnumber/decNumber.c' object='decNumber.o' libtool=no gcc
-I../../gcc/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings
-Wstrict-prototyp
es -Wmissing-prototypes -Wold-style-definition
At all optimizations:
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c
/
mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf-lib.c
/
At -O1, -O2 and -O3:
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fputs.c
/mn
t/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/builtins/fputs-lib.c
/mnt/
--- Comment #2 from tromey at gcc dot gnu dot org 2005-11-29 18:31 ---
In the version of ant I have (1.6.2) the class is
org.apache.tools.ant.launch.Launcher
not
org.apache.tools.ant.launcher.Launcher
So I think this is just a typo in the --main argument.
--
tromey at gcc dot gnu
--- Comment #8 from tromey at gcc dot gnu dot org 2005-11-29 18:35 ---
Subject: Bug 18278
Author: tromey
Date: Tue Nov 29 18:34:58 2005
New Revision: 107676
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107676
Log:
gcc/java:
PR java/18278:
* expr.c
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-29 18:36 ---
A regression hunt identified the following patch (not terribly useful):
r81764 | dnovillo | 2004-05-13 06:41:07 + (Thu, 13 May 2004) | 3 lines
Merge tree-ssa-20020619-branch into mainline.
Andrew, are you
--- Comment #5 from janis at gcc dot gnu dot org 2005-11-29 18:37 ---
The question in my previous comment should have been to Volker, not Andrew.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24996
--- Comment #4 from jb at gcc dot gnu dot org 2005-11-29 18:37 ---
It doesn't have anything to do with array transfers. The following test program
is equivalent to the one in #3, but uses the scalar transfer_integer instead of
transfer_array:
program test3
integer dat(5)
dat = (/
--- Comment #6 from reichelt at igpm dot rwth-aachen dot de 2005-11-29
18:44 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE on throw code
On 29 Nov, janis at gcc dot gnu dot org wrote:
Andrew, are you sure about 3.4.0 crashing for this testcase? I tried mainline
as far back as
--- Comment #9 from tromey at gcc dot gnu dot org 2005-11-29 18:58 ---
Subject: Bug 18278
Author: tromey
Date: Tue Nov 29 18:58:23 2005
New Revision: 107677
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=107677
Log:
gcc/java:
PR java/18278:
* expr.c
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-29 19:03
---
Confirmed.
Here's a reduced testcase.
Compile with g++ --param ggc-min-expand=0 --param ggc-min-heapsize=0.
templateint, int, int struct Dummy;
/head-glibc-2.3.3/powerpc-linux-gnuspe
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 4.2.0 20051129 (experimental)
According to the documentation
--- Comment #9 from toon at moene dot indiv dot nluug dot nl 2005-11-29
19:20 ---
FX,
Your patch solved the problem for me.
AFAICS, this patch is indeed the correct fix for this problem.
Please apply it to (at least) 4.1 and trunk.
It might be appropriate for the 4.0 branch, too.
--
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-29 20:33
---
This is not a bug in GCC. The code is invalid.
Let's consider the following simplified example which is just a
part of the diamond:
A0
|
A
/
B
==
struct A0
{
A0(int);
};
GCC version :
4.0.2
Complete C file :
int a;
char buf[(int)a];
command line :
gcc-4.0 -c file.c
Error message :
t.c:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-29 20:37 ---
(In reply to comment #4)
| instead of the FUNCTION_TYPE's type which has the correct type, I might fix
| this later tonight.
Try this
this patch is incomplete.
--
gdr at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 20:41 ---
The patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02046.html
Should fix it (but I have no warranties).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pda at freeshell dot org 2005-11-29 20:41 ---
Subject: Re: Failure to build, command line:1:2: error: missing '(' after
predicate
On Sun, Nov 27, 2005 at 06:57:05PM -, danglin at gcc dot gnu dot org wrote:
The -Aa option is likely the problem. It's probably
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 20:44 ---
I would assume this was caused by the patch which fixed PR 25022.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from andreast at gcc dot gnu dot org 2005-11-29 20:45
---
Compilation succeeded on sparc-solaris8 this morning, just after bje ci'ed I
had to use the same patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25157
export OMP_NUM_THREADS=2
gfortran-gomp -v Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gomp
--program-suffix=-gomp --enable-threads=posix --enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0-gomp-20050608-branch 20051126
The test g++.dg/abi/vtt1.C is failing with -funit-at-a-time
(or optimization -O or higher since this enables -funit-at-a-time
by default).
GCC 4.x.y doesn't seem to be affected.
Since this behaviour can be triggered with just -O2 I rate this as
a regression (although -funit-at-a-time was
--- Comment #1 from reichelt at gcc dot gnu dot org 2005-11-29 20:53
---
The test g++.dg/abi/vtt1.C is failing with -funit-at-a-time
(or optimization -O or higher since this enables -funit-at-a-time
Sorry, this should read -O2 instead of just -O.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 20:57 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #5 from pda at freeshell dot org 2005-11-29 21:03 ---
Subject: Re: Failure to build, command line:1:2: error: missing '(' after
predicate
On Fri, Nov 25, 2005 at 08:27:34PM -, pinskia at gcc dot gnu dot org wrote:
How did you configure GCC?
From using google it
--- Comment #10 from tromey at gcc dot gnu dot org 2005-11-29 21:14 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-29 21:46 ---
Hmm this is convoluted, but I think I know what's going on:
We're running the builtin fprintf check. I recently added a small sanity check
to ensure that fprintf_unlocked also works. Now we're getting an unresolved
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2005-11-29
22:00 ---
Subject: Re: Failure to build, command line:1:2: error: missing '(' after
predicate
On Sun, Nov 27, 2005 at 06:57:05PM -, danglin at gcc dot gnu dot org
wrote:
The -Aa option is likely the
--- Comment #6 from tromey at gcc dot gnu dot org 2005-11-29 22:37 ---
I tried the included test case with current svn head.
I had to add '.' to classpath, then it worked for me:
opsy. CLASSPATH=test.jar:. gij test1
Microsoft is crap
Compiling as in comment #4 also worked fine.
I
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-29 23:08 ---
Shorter testcase:
template typename T struct F;
template typename T FT operator(FT, const char*);
templatetypename T
struct F
{
friend F operator (F, const char*);
};
typedef Fchar F1;
templatetypename struct X;
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-29 23:20
---
Subject: Re: New: [3.4 Regression] g++.dg/abi/vtt1.C failure with
-funit-at-a-time
reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The test g++.dg/abi/vtt1.C is failing with -funit-at-a-time
|
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-29 23:23
---
(In reply to comment #1)
This is a duplicate of 11242 which was (incorrectly) closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11242
That is because it was not reported against mingw32 but a GNU/Linux OS.
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/conversion.c -w
-O
0 -fno-show-column -lm -o
/mnt/gnu/gcc-3.3/objdir/gcc/testsuite/conversion.x
0(timeout = 300)
/usr/bin/ld: Unsatisfied symbols:
--- Comment #11 from ed at catmur dot co dot uk 2005-11-29 23:55 ---
This is not invalid. Yes, reiser4 is broken, but so is gcc.
gcc (3.4.4, I haven't used 4.x yet) dies when it encounters an inaccessible
directory as a subdirectory of a member of the include path. See comment 6.
--
--- Comment #7 from danglin at gcc dot gnu dot org 2005-11-29 23:55 ---
The same errors occur on hppa2.0w-hp-hpux11.11 except that ld also dumps
core:
collect2: ld terminated with signal 10 [Bus error], core dumped
/usr/bin/ld: Unsatisfied symbols:
wf1 (first referenced in
--- Comment #1 from danglin at gcc dot gnu dot org 2005-11-29 23:58 ---
The same error also causes the failure of
gcc.dg/torture/fp-int-convert-long-double.c:
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/
--- Comment #2 from danglin at gcc dot gnu dot org 2005-11-30 00:00 ---
And gcc.dg/torture/fp-int-convert-timode.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25166
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-30 00:00 ---
This is a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc
-B/mnt/gnu/gcc-3.3/objdir/gc
c/ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c -O2 -fno-common
-f
no-show-column -lm -o ./weak-14.exe(timeout = 300)
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/weak/weak-14.c:20: error: alias
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../g++
-B/mnt/gnu/gcc-3
.3/objdir/gcc/testsuite/../
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/g++.old-deja/g++.
abi/cxa_vec.C -nostdinc++
-I/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/libst
dc++-v3/include/hppa2.0w-hp-hpux11.11
--- Comment #1 from joseph at codesourcery dot com 2005-11-30 00:34 ---
Subject: Re: New: FAIL: gcc.dg/weak/weak-14.c
Isn't this just bug 24478?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25167
--- Comment #4 from joseph at codesourcery dot com 2005-11-30 00:35 ---
Subject: Re: New: FAIL: gcc.c-torture/execute/conversion.c
compilation
As explained in bug 24998, I can't test on PA at present but the fix is
probably similar to that for IA64.
--
On i686-unknown-linux-gnu with the 4.0.x branch, I'm getting tree checking
failures in gcc.dg/20040203-1.c, cast-1.c, cast-2.c, cast-3.c. From the
logfile, the errors in 20040203-1.c are of this form:
20040203-1.c:17: internal compiler error: tree check: expected class
'constant', have 'unary'
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-11-30 00:44 ---
Based on the date it started failing, I'm guessing it was this patch that
triggered it:
2005-11-07 Paolo Bonzini [EMAIL PROTECTED]
PR c/24599
* c-typeck.c (build_c_cast): Try using a shared
--- Comment #5 from geoffk at geoffk dot org 2005-11-30 01:01 ---
Subject: Re: aliases, including weakref, break alias analysis
On 29/11/2005, at 5:55 AM, aoliva at gcc dot gnu dot org wrote:
Make it a weak alias, then.
A weak alias is still an alias and still not supported by
Here is the test code:
typedef struct
{
int ele;
} tstruct;
#define TST(r,t) r##t = 1
void test()
{
tstruct ts;
TST(ts,.ele);
}
It generates the error:
error: pasting ts and . does not give a valid preprocessing token
In previous
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran
-B/mnt/gnu/
gcc-3.3/objdir/gcc/testsuite/../
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/
mixed_io_1.f90 -O0 -pedantic-errors
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfor
tran.dg/mixed_io_1.c
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran
-B/mnt/gnu/
gcc-3.3/objdir/gcc/testsuite/../
/mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/
module_equivalence_1.f90 -O0 -pedantic-errors
-L/mnt/gnu/gcc-3.3/objdir/hpp
a2.0w-hp-hpux11.11/./libgfortran/.libs
I refer to the very frequent warnings about signed/unsigned mismatches.
Can I please say this:
What does it matter if the signedness of pointers don't match? Surely it only
*really* matters when a pointer is actually dereferenced. That is the only
time when signedness really matters. The rest
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 01:33 ---
This has been an error since 3.0.x.
And it is an error in your code.
*** This bug has been marked as a duplicate of 7976 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-11-30 01:33
---
*** Bug 25170 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-30 01:36 ---
Because the code is really invalid C.
that is:
int *a;
unsigned int *f(void)
{
return a;
}
Is invalid C. We used to just output a warning with -pedantic but now the
warning is always on unless you add
gfortran seems to ignore explicit return types of functions.
Example follows:
-bug.for
PROGRAM BUG
external real function Mfunc
real*4 X,Y
X = Xfunc()
Y = Mfunc()
write(6,*) X,Y
stop
end
1 - 100 of 130 matches
Mail list logo
