--- Comment #5 from rainer at emrich-ebersheim dot de 2009-12-04 08:24
---
Subject: Re: include search path composition is bogus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ktietz at gcc dot gnu dot org schrieb:
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-12-03
--- Comment #20 from dominiq at lps dot ens dot fr 2009-12-04 08:25 ---
At revision 154970, there are still 16 failures, but the error has changed for
libffi.call/cls_longdouble.c:
...
FAIL: libffi.call/cls_longdouble.c -O0 -W -Wall output pattern test, is 1 2 3 4
5 6 7 8: 36
...
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-04 08:50
---
Thanks Jason, it looks like the larger testcases we have also build fine now!
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo at gcc dot gnu dot org 2009-12-04 09:21 ---
Subject: Bug 42261
Author: paolo
Date: Fri Dec 4 09:20:58 2009
New Revision: 154975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154975
Log:
2009-12-04 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-04 09:21
---
Fixed for 4.4.3 too, arguably this is a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
Is it a silly bug or a contrived way of calling __sync_synchronize regardless
of the required memory_order?
--- atomic_2.h 2009-12-04 11:23:26.0 +0200
+++ atomic_2.h 2009-12-04 11:23:35.0 +0200
@@ -108,7 +108,7 @@
{
// write_mem_barrier();
_M_i = __v;
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-04 09:31
---
Benjamin, can you check this?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 09:48 ---
SMARTA a();
This does not declare an object of type SMARTA, it declares a function called
'a' which returns SMARTA
You need to change that to:
SMARTA a;
or
SMARTA a = SMARTA();
--
redi at gcc dot gnu dot org
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-12-04 09:52
---
The catch for the first null pointer exception in libjava.lang/Array_3
is not caught but I don't know why.
Very likely because of the adjustment made in libjava/pa-signal.h:
#define
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2009-12-04 09:58
---
Very likely because of the adjustment made in libjava/pa-signal.h:
libjava/hppa-signal contains a slight variant:
#define MAKE_THROW_FRAME(_exception)\
do
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2009-12-04 10:18
---
That's not true if you set fs-signal_frame to 1 in the fallback routine.
And I need to do the same clean-up in include/dwarf2-signal.h and
include/sparc-signal.h for SPARC...
--
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-04 10:49
---
Let's add DaveK in CC
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 10:54 ---
the suggested change is correct
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42273
--- Comment #3 from redi at gcc dot gnu dot org 2009-12-04 11:00 ---
Although as I noted in Bug 40297 comment 2 I think that function should also
have a memory barrier when m == memory_order_release, which the current code
has by accident because of this bug ... so arguably it's better
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 11:40 ---
P4 unless this affects primary or secondary targets.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-04 12:03 ---
This also happens when I try to reproduce the tramp3d profile mismatch
(well, if checking is enabled only obviously).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-04 12:06 ---
The ICE goes away with -fno-ipa-cp.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2009-12-04 12:15 ---
The problem is still present with:
arm-elf-gcc (GCC) 4.5.0 20091203 (experimental)
--
sebastian dot huber at embedded-brains dot de changed:
What|Removed
--- Comment #6 from flameeyes at gentoo dot org 2009-12-04 12:54 ---
Created an attachment (id=19222)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19222action=view)
Proposed patch
With this patch applied, gcj cross-builds fine (not a canadian cross though).
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-04 13:00 ---
So we come in
tree-inline.c:
1695 if (id-transform_call_graph_edges ==
CB_CGE_MOVE_CLONES)
1696cgraph_create_edge_including_clones
as we figure out a new direct call.
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-04 13:04 ---
patches need to be sent to gcc-patc...@gcc.gnu.org
please specify if older gcc versions work for you.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dominiq at lps dot ens dot fr 2009-12-04 13:17 ---
The smaller testcase of comment #1 is fixed with
Confirmed
The original fails because the vtable cannot be found. THis is due to:
use grid_module, only : grid
Removing the ,only : grid restores correct
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2009-12-04 13:31 ---
This one works:
arm-elf-gcc (GCC) 4.4.3 20091201 (prerelease)
I think that r150545 introduced the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
--- Comment #7 from hjl dot tools at gmail dot com 2009-12-04 13:45 ---
It is caused by revision 154200:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00421.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-04 14:21 ---
It may be related to PR 42202.
If I am not mistaken this has been fixed by revision 154944 (see
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00343.html ).
However this pr is not fixed at revision 154970.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|--- |4.5.0
--- Comment #29 from dominiq at lps dot ens dot fr 2009-12-04 14:24 ---
AFAICT the inner loop of PR42108 is still unrolled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-04 14:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from dominiq at lps dot ens dot fr 2009-12-04 14:25 ---
AFAICT fixing pr42131 does not help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
--- Comment #18 from bernds_cb1 at t-online dot de 2009-12-04 14:26 ---
Unfortunately it causes failures. Tracking these mismatches really is quite
tricky.
I'll try to fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216
The attached code gives an ICE against the fortran-dev branch as of r154975.
[sfili...@donald bug12]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured
--- Comment #1 from sfilippone at uniroma2 dot it 2009-12-04 14:30 ---
Created an attachment (id=19223)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19223action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
--- Comment #19 from rguenther at suse dot de 2009-12-04 14:34 ---
Subject: Re: [4.5 Regression] changes in scheduling
regress 464.h264ref 20%
On Fri, 4 Dec 2009, bernds_cb1 at t-online dot de wrote:
--- Comment #18 from bernds_cb1 at t-online dot de 2009-12-04 14:26
---
http://gcc.gnu.org/viewcvs/trunk/libffi/
does not have a libffi.pc.in in its source tree, which that is present in the
tree the code got imported from:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libffi/?cvsroot=libffi
This caused issues elsewhere, e.g.
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 14:48 ---
Fortran people - if you want to use bugzilla for fortran-dev please add a
fortran-dev version people can report bugs against.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dominiq at lps dot ens dot fr 2009-12-04 14:58 ---
The code compiles with [trunk revision 154654]. It looks like a regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42274
--- Comment #4 from sfilippone at uniroma2 dot it 2009-12-04 15:02 ---
(In reply to comment #3)
The code compiles with [trunk revision 154654]. It looks like a regression.
Yes, I know, this is due to the recent work by Paul Thomas and Janus Weil about
the dynamic dispatching
--- Comment #1 from flameeyes at gentoo dot org 2009-12-04 15:06 ---
Created an attachment (id=19224)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19224action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42276
--- Comment #1 from ensonic at hora-obscura dot de 2009-12-04 15:39 ---
Also is the copy of the lib actually needed, could gcc not use the standalone
libffi instead?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42275
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-04 15:57 ---
(In reply to comment #3)
Richard is probably right, it should be clearly marked against the branch,
I have now set Reported against to 'fortran-dev', marked it in the Subject
line and in 'known to work/fail'
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-04 16:20
---
I'm recategorizing as other, because actually the demangler doesn't belong to
the library.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #21 from dominiq at lps dot ens dot fr 2009-12-04 16:27 ---
At revision 154983, I get
=== libffi tests ===
Running target unix
FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0
FAIL: libffi.call/cls_longdouble_va.c -O0 -W -Wall
--- Comment #18 from jb at gcc dot gnu dot org 2009-12-04 16:28 ---
Subject: Bug 40812
Author: jb
Date: Fri Dec 4 16:28:44 2009
New Revision: 154984
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154984
Log:
PR libfortran/40812 Large file support for MinGW
Modified:
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-04 16:40 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #19 from jb at gcc dot gnu dot org 2009-12-04 17:02 ---
Fixed, closing.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-04 17:06 ---
(In reply to comment #5)
#3 0x004fa344 in mio_component (c=0x154b880) at
/home/tob/projects/fortran-dev/gcc/fortran/module.c:2362
The component here is 'is_null', and the parent symbol is
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Severity|normal |minor
Summary|pseudo-optimzation with
--- Comment #3 from debian dot templier at free dot fr 2009-12-04 17:12
---
Subject: Re: derived template default argument
redi at gcc dot gnu dot org wrote:
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-04 09:48 ---
SMARTA a();
This does not declare an object
// { dg-options -std=c++0x }
struct S { int s; };
template int N
void foo ()
{
S s;
decltype (s.s) i;
}
diagnoses:
t.C: In function âvoid foo()â:
t.C:6: error: type of âs.sâ is unknown
t.C:6: error: invalid type in declaration before â;â token
(but compiles just fine when template
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-04 17:30 ---
Just got awake in my $TZ, will look at this straight away and fix or revert in
the next couple of hours. Sorry for the inconvenience.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
--- Comment #4 from redi at gcc dot gnu dot org 2009-12-04 17:31 ---
(In reply to comment #3)
the pb is on line :
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
I don't understand, that line did not appear
--- Comment #5 from debian dot templier at free dot fr 2009-12-04 17:33
---
the pb is on line :
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
if i replace the line by
template typename XT2 = T , typename
--- Comment #6 from debian dot templier at free dot fr 2009-12-04 17:39
---
i want a constructor on template class SMARTT with reference parameter on
SMARTX value with the constraint of T on SMART instanciation is
T is unherited of X
class A
{
} ;
class B : virtual public A
{
} ;
--- Comment #7 from debian dot templier at free dot fr 2009-12-04 17:44
---
template typename X , typename XT2 =T , typename X2 = typename XT2 ::
X SMART(SMARTX value) : data(value.CastUp) {} ;
The code to do the constructor
--
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-04 17:44
---
.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #12 from daney at gcc dot gnu dot org 2009-12-04 17:46 ---
Subject: Bug 42164
Author: daney
Date: Fri Dec 4 17:46:23 2009
New Revision: 154987
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154987
Log:
2009-12-04 David Daney dda...@caviumnetworks.com
PR
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-04 17:58 ---
Created an attachment (id=19225)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19225action=view)
Simple fix
The comment in the patch should explain. Namespace macros are defined at the
top of c++config.h before
--- Comment #6 from davek at gcc dot gnu dot org 2009-12-04 18:00 ---
I didn't anticipate any of the os-specific config headers trying to use the
namespace macros, since all the necessary defines and stuff are only half-way
through being set up, but I didn't imagine the possibility of
--- Comment #2 from amonakov at gcc dot gnu dot org 2009-12-04 18:00
---
(In reply to comment #0)
Janis,
Thank you for the testcase. This bug and PR42249 are fixed by Andrey's old
patch:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01930.html
The patch in that message still
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu dot
|
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu dot
|
I faced an error ERROR: ctfconvert: die 37: base type without name
when run ctfconvert on some object files which were produced by gcc-4.4.2
The error like this:
/opt/onbld/bin/i386/ctfconvert -g -l NDISWRAPPER example.o
ERROR: ctfconvert: die 37: base type without name
I
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2009-12-04
18:13 ---
Have you tried r154983 with
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
--- Comment #13 from daney at gcc dot gnu dot org 2009-12-04 18:20 ---
Fixed by the patch.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-12-04
18:22 ---
Subject: Re: os_defines.h:60:1: error: expected '{' before
'_GLIBCXX_PSEUDO_VISIBILITY'
JDA, I don't have headers and libs to test a hpux cross-compiler, could you
test the patch?
I'll test tonight.
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-04 18:23 ---
(In reply to comment #7)
I'll test tonight.
Thanks. So sorry for the aggro :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42271
--- Comment #23 from dominiq at lps dot ens dot fr 2009-12-04 18:34 ---
Have you tried r154983 with
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html?
Not yet!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
Libmudflap receives the host CPP to test the headers with, instead of receiving
the target CPP.
I noticed it having a linux gnu system with glibc and targetting a uclibc
linux.
I will attach a patch with the fix I used.
--
Summary: libmudflap checks with the wrong CPP for execinfo.h
--- Comment #7 from uros at gcc dot gnu dot org 2009-12-04 18:42 ---
Subject: Bug 41908
Author: uros
Date: Fri Dec 4 18:41:59 2009
New Revision: 154988
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154988
Log:
PR libffi/41908
* src/x86/ffi64.c
--- Comment #4 from bkoz at gcc dot gnu dot org 2009-12-04 18:43 ---
Agree with #2. This is a one-liner to fix.
Jonathan, can you put your comments in 40297 into the wiki page for atomics?
I'd forgotten about this whole commentary. We are just starting in again on
this.
See:
--- Comment #8 from ubizjak at gmail dot com 2009-12-04 18:43 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from viriketo at gmail dot com 2009-12-04 18:44 ---
Created an attachment (id=19226)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19226action=view)
Fix the CPP needed by libmudflap when cross-compiling
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
--- Comment #5 from redi at gcc dot gnu dot org 2009-12-04 18:46 ---
will do
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC|
Trying to build a gcc 4.4.2 for 'baremetal' targets, in my case for later libc
building, I find that the libiberty configure script at some stage checks for
some libc headers to be available.
I'm calling the gcc main configure with --without-headers. The total flags
are:
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-12-04 19:22 ---
Janus, I just re-checked the patch from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478#c12
and found that that is all that's needed.
OK to commit to trunk and, after a few days, to 4.4 with the
testcase from
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-04 19:43 ---
(In reply to comment #6)
I think the problem is that c-tb-ppc is not set correctly for the PPCs
inside
vtype.
The following patches fixes it:
Index: gcc/fortran/symbol.c
[Code]
template class T
int doSomething(T const aT)
{
return aT.a();
}
class A
{
public:
int a() const
{
return 1;
}
};
class B
{
public:
int b() const
{
return 1;
}
};
template class T
inline bool
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-12-04 19:52 ---
Jerry, this might be involved in PR41165 as well?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-04 19:56 ---
One issue is Koenig lookup does not apply to fundamental types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42281
With 20091201 trunk on Linux/amd64 ICE does not happen with GCC 4.4.1-ubuntu8.
Appears to be bad interaction
between -O2 and -funswitch-loops. Either alone is fine, but together the crash
occurs. The commandline below reproduces the issue, but removing all but -O2
and -funswitch-loops will also
While bootstrapping trunk from 20091201 on amd64. Crash doesn't happen with GCC
4.4.1-ubuntu8.
The ICE occurs when -ftree-loop-distribution is combined with -O2
-ftree-loop-linear. The commandline below reproduces the issue as well, but can
be reduced to the forementioned options as well.
gcc -c
--- Comment #14 from tkoenig at gcc dot gnu dot org 2009-12-04 20:33
---
The problem is with the allocatable components for
intrinsics, at least.
This has the same problem:
program main
type :: container_t
integer, dimension(:), allocatable :: entry
end type container_t
--- Comment #15 from tkoenig at gcc dot gnu dot org 2009-12-04 20:36
---
Very probably a dup of PR 40850.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
GCC trunk gets an internal compiler error when building SPEC CPU2000 test
164.gzip with -O2 -floop-interchange on powerpc-linux, as demonstrated by a
minimized testcase that I'll attach to this PR.
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -O2 -floop-interchange
bug.c
bug.c: In
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-04 20:39 ---
Created an attachment (id=19227)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19227action=view)
Minimized testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42284
GCC trunk gets an internal compiler error when building SPEC CPU2006 test
416.gamess with -O2 -floop-interchange on powerpc-linux, as demonstrated by
this minimized testcase:
SUBROUTINE EFGRDM(NCF,NFRG,G,RTRMS,GM,IOPT,K1)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
DIMENSION
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #24 from dominiq at lps dot ens dot fr 2009-12-04 21:00 ---
Have you tried r154983 with
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00255.html?
The patch does not change anything, I get the same failures with or without it.
--
--- Comment #16 from tkoenig at gcc dot gnu dot org 2009-12-04 21:03
---
We get this right on assignment, so it is probably just a matter
of copying over the logic from there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
The October 23rd, 2009 change to tree-ssa-pre.c breaks calculix on powerpc with
-ffast-math. When you start up the benchmark with reference input, it fails
almost immediately because the calculations don't converge.
At this point, I don't have a narrowed down test case, but the following
change:
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-04 21:18 ---
This change merely turns off PRE in cold code regions. So if -fno-tree-pre
breaks calculix for you I'd guess some later optimization manages to
miscompile it (my guess: the vectorizer).
What options do you build
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-04 21:24 ---
Please send patches to gcc-patc...@gcc.gnu.org
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42279
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-12-04
21:28 ---
Subject: Re: October 23rd change to tree-ssa-pre.c breaks calculix on powerpc
with -ffast-math
On Fri, Dec 04, 2009 at 09:18:45PM -, rguenth at gcc dot gnu dot org wrote:
--- Comment #1
--- Comment #2 from jezz at hkfree dot org 2009-12-04 21:30 ---
I have tried to simplify the code, but I have created only problem with int
(not with user structure). In real code we have also something like this:
Tested with same compilers:
template2.cc: In function #8216;bool
--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-04 21:37 ---
With the patch in comment #7 the tests in pr41829 and the following ones
segfault at runtime.
!
module m
type :: t1
integer :: i = 42
contains
procedure, pass :: prod =
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-04 21:41 ---
Confirmed on x86_64-apple-darwin10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42285
--- Comment #2 from dominiq at lps dot ens dot fr 2009-12-04 21:47 ---
Confirmed on x86_64-apple-darwin10:
[macbook] f90/bug% gcc45 -O2 -floop-interchange -c pr42284.c
pr42284.c:6:14: warning: conflicting types for built-in function 'malloc'
pr42284.c: In function 'inflate_fixed':
Attempting to build GCC for a powerpc-linux-gnu target. Host machine is i686
running Linux 2.6.31.6-145.fc12.i686.PAE
Get the dreaded checking for suffix of object files... configure: error:
cannot compute suffix of object files: cannot compile See `config.log' for
more details. message.
--- Comment #1 from mark at advancedtechcorp dot com 2009-12-04 21:55
---
Created an attachment (id=19228)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19228action=view)
config log
configuration log where the crash is shown.
--
1 - 100 of 172 matches
Mail list logo
