--- Comment #3 from stsp at users dot sourceforge dot net 2008-01-19 08:25
---
Yes, I know, but... without -m32 it compiles.
So either way it might be a bug - maybe it
should not compile without -m32 too? Why does
-m32 make the difference here?
--
Briefly: of all the ldexp variants only straight ldexp consistently get folded.
The overloaded c++ version, std::ldexp, is the easiest to derail, as this
testcase demonstrates (note: you can't get much more than 1 such call folded);
but it has also happened to me with ldexpf, it's just harder to
--- Comment #3 from stsp at users dot sourceforge dot net 2008-01-19 08:35
---
Yes, but the point was that the same
code should not compile/reject depending
only on an optimizer options.
If this code is invalid, then with -O2 it
should give the error as well, or at least
a warning.
The
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-01-19
08:33 ---
(In reply to comment #4)
Testing a patch.
Here it is:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00881.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
--- Comment #55 from steven at gcc dot gnu dot org 2008-01-19 09:41 ---
IMHO we can close this one now as fixed. Objections to that, anyone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400
A r131535 of trunk bootstrapped with --enable-langugages=c
--enable-checking=release,valgrind shows this indication for several
test-cases, the first being tmpdir-gcc.dg-struct-layout-1/t001
c_compat_x_tst.o compile
(just the first indication of several identical is shown):
Executing on host:
--- Comment #1 from hp at gcc dot gnu dot org 2008-01-19 10:43 ---
Using a later revision is recommended, at least = r131589.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-19 10:48 ---
merge_classes() itself is clear, so the problem must be in the caller.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34865
A r131535 of trunk bootstrapped with --enable-langugages=c
--enable-checking=release,valgrind shows this indication for
gcc.dg/cpp/Wmissingdirs.c and also an ICE:
Executing on host: /tmp/hptest8/obj/gcc/xgcc -B/tmp/hptest8/obj/gcc/
/tmp/hptest8/gcc/gcc/testsuite/gcc.dg/cpp/Wmissingdirs.c -s
--- Comment #1 from hp at gcc dot gnu dot org 2008-01-19 10:54 ---
Using a later revision is recommended, at least = r131589.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Following preprocessed program can not be compiled with -ff2c option due to
the internal compiler error (all the messages are listed below test.f).
beginning of test.f
function f(a)
implicit none
complex(8) :: f
real(8),intent(in) :: a(:)
A r131535 of trunk (a later revision is recommended, at least = r131589)
bootstrapped with --enable-langugages=c --enable-checking=release,valgrind
shows these error indications for gcc.dg/cpp/line5.c (as in gcc.log, but only
the first 3 are shown):
Executing on host: /tmp/hptest8/obj/gcc/xgcc
A r131535 of trunk (a later revision is recommended, at least = r131589)
bootstrapped with --enable-langugages=c --enable-checking=release,valgrind
shows these indications for gcc.dg/cpp/charconst.c (show as in gcc.log):
Executing on host: /tmp/hptest8/obj/gcc/xgcc -B/tmp/hptest8/obj/gcc/
--- Comment #1 from dragan at plusplus dot co dot yu 2008-01-19 11:39
---
Created an attachment (id=14974)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14974action=view)
a simple test case (the same as in the bug description)
--
This code should be legal:
template typename T
struct Foo
{
template typename Z
friend void func(const Foo ) {}
};
void check(const Fooint x)
{
// Fooint weird; // uncomment this line and all works
funcint(x);// -- GCC issues an ERROR
}
After a brief discussion on [EMAIL
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 11:34 ---
Confirmed on darwin9 (ppc/intel) with adifferent error:
pr34868.f90: In function 'f':
pr34868.f90:5: internal compiler error: in gimplify_expr, at gimplify.c:6285
--
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-01-19 12:03 ---
Does the regression on C2 duo show even without vectorizing? It looks like
generic SSE fpmath performance issue. There should be no reason why SSE math
in combination with SSE vectorization should result in
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-19 12:04 ---
It is constant folded but not until after inlining.
A simplier example is:
static inline int f(int a)
{
return a+2;
}
int g(int a)
{
const int b[] = {f(1), f(2), f(3) };
return b[a];
}
int g1(int a)
{
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-19 12:07 ---
Oh, in C++, const_var is a constant integral expression after all so that is
why it is accepted with C++ front-end, I had forgot the exact rules for C++ for
a second there.
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-19 12:08 ---
Well with x86_64, PIC addressing global variables is simpler as you have access
to the rip register. Try this on any other target, you will get a rejection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-19 12:11 ---
complex(kind=8) __result_f;
*__result_f = 0.0;
return __result_f;
:)
Well that is obviously wrong.
Also is there a reason why you are using -ff2c anyways? It does change the ABI
slightly.
--
pinskia
MODULE TESTS
dimension :: k(4)
CONTAINS
function k()
k = 35
end function k
END MODULE
is invalid (variable k vs. function k), but not detected.
Needs to be fixed in decl.c's get_proc_name; I have a patch, but it causes
regressions
--
Summary:
--- Comment #4 from aldot at gcc dot gnu dot org 2008-01-19 12:37 ---
Bruce,
Can you please have a look. How is that ment to work?
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-19 12:43 ---
Without -ff2c, gfortran uses (-fdump-tree-original):
complex(kind=8) __result_f;
__result_f = __complex__ (0.0, 0.0);
but for -ff2c it looks odd:
f (a)
{
complex(kind=8) __result_f;
*__result_f = 0.0;
--- Comment #5 from stsp at users dot sourceforge dot net 2008-01-19 12:47
---
OK, I understand, thank you.
Closing it then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34833
--- Comment #56 from zadeck at naturalbridge dot com 2008-01-19 13:09
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
Let me commit the patch first.
Sent from my iPod
On Jan 19, 2008, at 4:41 AM, steven at gcc dot gnu dot org
[EMAIL PROTECTED]
--- Comment #5 from aldot at gcc dot gnu dot org 2008-01-19 14:14 ---
Assuming build=i386-linux-*, host==target==sh4-linux-*, i.e. cross-compiling a
native compiler for SuperH:
-) sh*-* forces use_fixproto in config.gcc (why?)
See config.gcc: line 2308
-) stmp-install-fixproto:
--- Comment #5 from burnus at gcc dot gnu dot org 2008-01-19 14:16 ---
Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00236.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34760
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-01-19 15:31
---
Not that this reference is always right, but Metcalf, Reid, and Cohen state:
direct=dir where dir ... are character variables that are assigned the value
YES, NO, or UNKNOWN, depending on whether the file may be
When I compile the function listed below using the January 18 snapshot of
gfortran, I get the following error:
t.f90:2.2:
10 CONTINUE
1
t.f90:3.7:
GOTO 10
2
Error: Statement at (1) is not a valid branch target statement for the branch
statement at (2)
I believe it applies to all
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-19 15:41 ---
Subject: Bug 34760
Author: burnus
Date: Sat Jan 19 15:41:04 2008
New Revision: 131652
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131652
Log:
2008-01-19 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-19 16:03 ---
Confirm. I think it is a fallout of Paul's typespec patch (PR 34429 et alia).
In resolve_branch (which prints the error message), label-defined ==
ST_LABEL_BAD_TARGET.
The problem is probably that
-mfpmath=387 20.73 20.6420.69
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 CPU X6800 @ 2.93GHz
stepping: 5
cpu MHz : 2933.422
cache size : 4096 KB
gcc version 4.3.0 20080119
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12
---
(In reply to comment #4)
Reply to comment #2: I will update and see if that fixes it. Thanks Danny
I'm closing this: I have built new binaries and I still don't this it. Jerry,
if updating doesn't fix it,
--- Comment #7 from burnus at gcc dot gnu dot org 2008-01-19 17:13 ---
FIXED on the trunk (4.3.0).
Thanks for the bug report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jvdelisle at verizon dot net 2008-01-19 17:20 ---
Subject: Re: Formatted write of float broken (mingw32)
fxcoudert at gcc dot gnu dot org wrote:
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:12
---
(In reply to comment #4)
Reply
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:20
---
Works for me with a more recent version (version 4.3.0 20071231), on my MacOS
10.4.11/Intel Core Duo, so I'm closing this as fixed.
Could you try to update your compiler (see
--- Comment #1 from dominiq at lps dot ens dot fr 2008-01-19 17:21 ---
Some debuging (this as fas as I can go on my own):
note the line
5: csym-value = (struct gfc_expr *) warning: Got an error handling event:
Cannot access memory at
for the case that does not crash.
(gdb) run
--- Comment #6 from bkorb at gnu dot org 2008-01-19 17:23 ---
fixincludes has nothing to do with fixproto, other than both working
with fixing up headers and having names that start with fix. So,
I know little about it and even less about canadian crosses. fix-header
also starts with
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:25
---
(In reply to comment #5)
I do not have a strong feeling about it, and I would accept it if you
propose to close this issue.
[...]
A -ffake-lack-of-integer-kind-1 option would have made it easier to
resolve
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-01-19 17:33
---
Reproduced on powerpc-apple-darwin9.1.0, both with -m32 and -m64. It happens
with stabs, but not with dwarf.
$ gfortran -gstabs test.f -g -m32
can't find atom for N_GSYM stabs nrange:G(0,5) in
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-19 17:47
---
On x86-64 linux using valgrind:
==2713== Invalid read of size 8
==2713==at 0x45C16C: resolve_common_vars (resolve.c:657)
and
==2713== Invalid read of size 1
==2713==at 0x45C230: resolve_common_vars
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-01-19 17:48 ---
I'm 95% certain this was caused by my patch.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2008-01-19 17:50 ---
Subject: Bug 34610
Author: jakub
Date: Sat Jan 19 17:49:46 2008
New Revision: 131653
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131653
Log:
PR gcov-profile/34610
* tree-cfg.c (make_edges):
/usr/bin/gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I/there.pentium4/toolchain_build_i686/gcc-4.3.0/gcc
--- Comment #12 from jakub at gcc dot gnu dot org 2008-01-19 17:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from tbptbp at gmail dot com 2008-01-19 17:56 ---
Gah. Seems that i've managed to hit another issue than what i was after with my
simplistic testcase then, because in the original code there's no array
anywhere - but static definitions - and i get calls to ldexpf (at
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-19 18:04 ---
Why is a Fortran FE bug considered P2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34817
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-19 18:06 ---
I'm closing because the original reporter could not reproduce.
If you think this is in error, post a note here and I will reopen this.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-19 18:09 ---
It fails in array.c's
compare_bounds (gfc_expr *bound1, gfc_expr *bound2)
{
if (bound1 == NULL || bound2 == NULL
|| bound1-expr_type != EXPR_CONSTANT
|| bound2-expr_type != EXPR_CONSTANT
||
--- Comment #12 from danglin at gcc dot gnu dot org 2008-01-19 18:33
---
I also see the ICE reported in comment #12 on hppa-unknown-linux-gnu.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 18:42 ---
Is really SIZE(IDA2,NF3) done on purpose? or is this a typo for
SIZE(IDA2,3)? It does not change the ICE AFAICT.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34861
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-19
18:36 ---
Subject: Re: [4.3 regression] ICE with invalid variadic template functions
I also see the ICE reported in comment #12 on hppa-unknown-linux-gnu.
Sorry, comment #7.
Dave
--
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-19 19:47 ---
Further debug:
Breakpoint 2, resolve_common_blocks (common_root=0x40d02c50) at
../../gcc-4.3-work/gcc/fortran/resolve.c:692
692 {
(gdb) c
Continuing.
Breakpoint 3, resolve_common_vars (sym=0x40d06f50,
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_malloc_size_var.c (test for excess errors)
valgrind --tool=memcheck --db-attach=yes --error-limit=no
/home/zadeck/gbB2/gcc/cc1 -fpreprocessed wo_prof_malloc_size_var.i -quiet
-dumpbase
--- Comment #1 from zadeck at naturalbridge dot com 2008-01-19 20:13
---
I am about to commit the last fix to p34400 and at least on my machine, this
patch will make this failure disappear from the test suite. however the bug is
still there if you look with valgrind.
pinskia, i am
--- Comment #6 from pcarlini at suse dot de 2008-01-19 20:24 ---
This is not a bug, and already spuriously reported: yu *cannot* use
-D_GLIBCXX_FULLY_DYNAMIC_STRING, it's completely unsupported and not described
anywhere in the documentation. You can only completely rebuild the library
With compiler
4.3.0 20080109 (experimental) [trunk revision 131426] (GCC)
vector valued reads into an array don't appear to read in values.
The test program prints out
kind of qda =4
vector valued read failed
1 -100.00 1.
2 -100.00
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-19 20:49 ---
I can reproduce it on x86-64-linux. The first error valgrind shows is
==25404== Invalid read of size 8
==25404==at 0x44361B: gfc_match_common (match.c:2756)
==25404==by 0x4522B9: match_word (parse.c:64)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-19 21:06
---
I will have a look.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-19 21:21
---
I will check into this one while I am at it as well
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
The following program prints READ FAILED. A similar program
with an unformatted, rather than direct access, file also fails.
Dick Hendrickson
Program qi0011
CHARACTER(9) BDA(10)
CHARACTER(9) BDA1(10)
INTEGER J_LEN
ISTAT = -314
INQUIRE(IOLENGTH = J_LEN) BDA1
--- Comment #8 from aldot at gcc dot gnu dot org 2008-01-19 21:38 ---
From FSFChangelog.10:
Mon Feb 12 20:42:11 1996 Randy Smith [EMAIL PROTECTED]
* i386/x-osfrose (XCFLAGS{,_NODEBUG}): Remove $(SHLIB).
(XCFLAGS): New variable.
(libdir, mandir, bindir):
--- Comment #3 from rbuergel at web dot de 2008-01-19 22:38 ---
another testcase:
templatetemplatetypename... T class Comp, typename... T void f( T... Value)
{
static_assert( CompT::value 0, );
}
template typename... T
struct Foo
{
static const int value=1;
};
int main()
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-01-19 22:48 ---
Subject: Bug 34817
Author: tkoenig
Date: Sat Jan 19 22:47:47 2008
New Revision: 131660
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131660
Log:
2008-01-19 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-01-19 22:48 ---
Subject: Bug 34838
Author: tkoenig
Date: Sat Jan 19 22:47:47 2008
New Revision: 131660
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131660
Log:
2008-01-19 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-01-19 22:51 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-01-19 22:52 ---
Fixed. Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rsandifo at gcc dot gnu dot org 2008-01-20 00:05
---
Subject: Bug 34831
Author: rsandifo
Date: Sun Jan 20 00:05:07 2008
New Revision: 131662
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131662
Log:
gcc/
PR target/34831
* config/mips/mips.md
--- Comment #14 from rsandifo at gcc dot gnu dot org 2008-01-20 00:08
---
Fixed.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jsm28 at gcc dot gnu dot org 2008-01-20 00:49 ---
If confirmed, this is a serious regression.
Is the make -j 4 command at toplevel in a newly configured clean build tree
(not a build tree previously built with an older version of the sources, for
example)?
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 00:54 ---
I built last night with revision 131650 with -j3 and it worked.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 00:54 ---
How did you configure GCC? How exactly did you invoke make?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dick dot hendrickson at gmail dot com 2008-01-20 01:21
---
Subject: Re: ICE in function with entry (and result?)
Sorry, basically a typo on my part. This is part of a large test suite and I
cut it down to a small case. The variable NF3 has the value 3 and the
consider templatetypename T, typename... Args T max( T a, T b, Args... args
);
templatetypename T T max( T a)
{
return a;
}
templatetypename T, typename... Args T max( T a, T b, Args... args )
{
return a maxT(b, args...) ? a : maxT(b, args...);
}
#include iostream
int main()
{
--- Comment #2 from zadeck at naturalbridge dot com 2008-01-20 01:43
---
actually the commit for 34400 does not seem to effect this bug.
but the bug does have that nice heisenbug quality to it.
kenny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34874
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 01:46 ---
I think this is valid code as you specify maxT(b, args...) which means the
type for the first template argument will be unsigned so it will convert the
second argument to unsigned int.
Isn't that correct?
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 01:47 ---
Sorry Kenny I forgot to say we already have a bug report about this, PR 34472.
*** This bug has been marked as a duplicate of 34472 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-20 01:47 ---
*** Bug 34874 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #57 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 ---
Subject: Bug 34400
Author: zadeck
Date: Sun Jan 20 01:48:25 2008
New Revision: 131670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131670
Log:
2008-01-19 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #59 from zadeck at gcc dot gnu dot org 2008-01-20 01:49 ---
Subject: Bug 26854
Author: zadeck
Date: Sun Jan 20 01:48:25 2008
New Revision: 131670
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131670
Log:
2008-01-19 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-20 01:49 ---
This is accepted for the same reason why the code you have is accepted:
std::cout maxunsigned(3u, -1) std::endl;
If we write the second max as:
templatetypename T, typename... Args T max( T a, T b,
--- Comment #58 from zadeck at naturalbridge dot com 2008-01-20 02:13
---
The three patches that have been committed seem to have brought this under
control.
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
Bootstrap of revision 131654. Testsuite has one failure.
Executing on host: /home/kargl/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran
-B/home/kargl/gcc/obj4x/
gcc/testsuite/gfortran/../../
/home/kargl/gcc/gcc4x/gcc/testsuite/gfortran.dg/vect/fast-math-pr33299.f9
0 -O2 -ftree-vectorize
--- Comment #4 from kargl at gcc dot gnu dot org 2008-01-20 02:20 ---
Just a quick note. The bug is not present on i386-*-freebsd, but is
present on x86_64-*-*freebsd. This is most likely a 32-bit versus
64-bit pointer issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-01-20 02:56
---
Here is a reduced case that illustrates the problem. Not specifying the
negative stride in either the read or write results in a failure. See the
commented lines.
program qi0011
character(9) bda(10)
--- Comment #4 from hjl dot tools at gmail dot com 2008-01-20 03:06 ---
Revision 131671 passed the last failure point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34851
The test case is gcc.c-torture/execute/built-in-setjmp.c.
The __builtin_setjmp stores Y+1 in the setjmp buffer. With -O0 the first
instruction after the jmp does a sbiw r28, 1 that restores the
original value, but for some reason, with higher optimization levels,
this instruction is optimized
--- Comment #4 from pmarques at grupopie dot com 2008-01-20 03:41 ---
gcc.c-torture/execute/ffs-1.c and gcc.c-torture/execute/ffs-2.c also fail with
this message. The test case gcc.c-torture/execute/builtin-bitops-1.c shows some
more similar errors:
builtin-bitops-1.c:(.text+0x6b4):
gcc.c-torture/execute/float-floor.c depends on the target supporting an actual
64-bit double type.
Since the type double in the avr target is actually a 32-bit float, the test
always fails.
--
Summary: gcc.c-torture/execute/float-floor.c fails for targets
with no
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-20 04:09 ---
What instructions is causing the crash?
Are you testing on a machine which has SSE2 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34878
--- Comment #2 from sgk at troutmask dot apl dot washington dot edu
2008-01-20 04:17 ---
Subject: Re: fast-math-pr33299.f90 failure with illegal instruction due to
-ffast-math.
On Sun, Jan 20, 2008 at 04:09:19AM -, pinskia at gcc dot gnu dot org wrote:
What instructions is
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-01-20 04:19 ---
There is the issue, the testcase should be not run on your computer as it is
using SSE2. So this is a testsuite issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
The bootstrap fails at stage 3 for an up-to-date repo
The configure is:
../gcc/configure --prefix=/Users/ed/bin-4.3
--enable-languages=c,c++,objc,obj-c++,fortran,treelang
I do a search in the build directory and find:
MacOSX:~/obj-4.3 ed$ find . -name libgcc_s.10.4.\*
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34838
1 - 100 of 114 matches
Mail list logo
