--- Comment #6 from dominiq at lps dot ens dot fr 2010-07-02 16:53 ---
Yes, please reduce and lets see if we can discover something more specific
wrong here. Then also consider Mikael's idea.
I don't think there is anything specific to discover. The fix for PR44582 is
too
--- Comment #8 from dominiq at lps dot ens dot fr 2010-07-01 12:16 ---
Fixed for 4.6, waiting a bit for 4.5.
Revision 161496 caused pr44699.
I think the PRINTs are of no use in the testsuite for gfortran.dg/pr44592.f90.
I'ld suggest to apply the following patch:
--- ../_clean/gcc
--- Comment #10 from dominiq at lps dot ens dot fr 2010-07-01 13:18 ---
The important question is if the testcase still ICEs with the fix reverted
when
you do that change.
The test aborts with revisions before 161496.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44744
--- Comment #7 from dominiq at lps dot ens dot fr 2010-07-01 14:25 ---
This may be a duplicate of pr44662. Could you try the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44662#c2 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-01 15:01 ---
I forgot to mention: I think this file is valid Fortran 2003 and only invalid
Fortran 95. Maybe using:
integer, dimension(4) :: y
is a better test case.
It is caught at compile time:
y = [y, (99,i=1,4)]
1
--- Comment #9 from dominiq at lps dot ens dot fr 2010-07-01 15:57 ---
(In reply to comment #8)
This may be a duplicate of pr44662. Could you try the patch in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44662#c2 ?
It is not.
Agreed for this pr (and pr44745 is a duplicate
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-01 20:23 ---
Lightly tested patch that does not create temporaries for the test in comment
#1
--- ../_clean/gcc/fortran/dependency.c 2010-06-21 17:31:37.0 +0200
+++ gcc/fortran/dependency.c2010-07-01 22:16
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44773
--- Comment #2 from dominiq at lps dot ens dot fr 2010-07-01 21:24 ---
I think it is not really a regression in terms of the code path.
Well, my definition of a regression is something working as expected at
revision n, no longer working as expected at revision n+1. Indeed revision n
: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10.4.0
GCC host triplet: x86_64-apple-darwin10.4.0
GCC target triplet: x86_64-apple-darwin10.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44726
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-30 16:16 ---
This is a duplicate of pr44726.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44730
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-30 16:41 ---
Subject: Bug 44034
Author: iains
Date: Wed Jun 30 14:33:40 2010
New Revision: 161606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161606
Log:
PR other/44034
* config/darwin.c
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-29 12:06 ---
On revision 161462 with the patch of revision 161496 I have located the problem
in:
static void
create_modes (void)
{
/* make_int_mode (BI, 1, 1, ../../work/gcc/machmode.def, 176); */
make_int_mode (QI, -1U, 1
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-29 13:24 ---
Created an attachment (id=21038)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21038action=view)
reduced test
The reduced test gives an ICE:
[macbook] f90/bug% /opt/gcc/gcc4.6bw/bin/gcc -c -O2 genmodes.c
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-29 13:30 ---
The backtrace for the reduced test of comment #5 is
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0022
0x0001007c320a in execute_vrp
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-29 14:36 ---
Is /opt/gcc/gcc4.6bw/bin/gcc a bootstrapped compiler or one created without
bootstrapping?
Sorry for the confusion. /opt/gcc/gcc4.6bw/bin/gcc was built with revision
161462 and the patch of revision 161496 (see
--- Comment #10 from dominiq at lps dot ens dot fr 2010-06-29 14:57 ---
Yes, but I'm asking if it was a bootstrapped compiler (in difference to one
built with configuring with --disable-bootstrap) or not.
If it was a bootstrapped compiler, are you saying that bootstrap fails
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44720
--- Comment #13 from dominiq at lps dot ens dot fr 2010-06-29 22:40 ---
Created an attachment (id=21042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21042action=view)
preprocessed tree.i
The patch in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03011.html fixes the
reported ICE
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-28 08:48 ---
This is likely the cause of recent failures for gfortran on ppc, see
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg02876.html
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg02871.html
The patch in comment #2
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-28 17:21 ---
Last successful bootstrap at revision 161470.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-28 18:55 ---
This is caused by revision 161496:
Author: matz
Date: Mon Jun 28 15:14:31 2010 UTC (2 hours, 52 minutes ago)
Changed paths: 4
Log Message:
PR middle-end/44592
* gimple-fold.c
--- Comment #7 from dominiq at lps dot ens dot fr 2010-06-28 20:42 ---
Fixed for 4.6, waiting a bit for 4.5.
Revision 161496 caused pr44699.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
for invalid SUM
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org
--- Comment #21 from dominiq at lps dot ens dot fr 2010-06-27 19:20 ---
With the patch in comment #19, the test suite pass with -m32 and -m64, but for
gfortran.dg/transpose_2.f90 which needs an adjustment of the dg-error.
AFAICT the SUM of the different tests are scalarized (it would
--- Comment #23 from dominiq at lps dot ens dot fr 2010-06-27 20:05 ---
(In reply to comment #22)
(although I am puzzled by the following error for the second test:
IF(DBUG.AND.NX.GT.0) THEN
1
Error: Operands of logical operator '.and.' at (1
--- Comment #24 from dominiq at lps dot ens dot fr 2010-06-27 21:30 ---
(In reply to comment #23)
Now I have forgotten another ICE with the patch: the second invalid test in
comment #2 gives
See pr44693.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
--- Comment #17 from dominiq at lps dot ens dot fr 2010-06-25 22:08 ---
With the patch in comment #13 I get the following failures:
FAIL: gfortran.dg/entry_10.f90 -O0 (internal compiler error)
...
FAIL: gfortran.dg/entry_13.f90 -O0 (internal compiler error)
...
FAIL: gfortran.dg
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-24 13:24 ---
Confirmed. Yet another bug or feature dilemma!-)
Using
make check-fortran RUNTESTFLAGS='dg.exp=data_invalid.f90'
works for me. I don't know what gfortran.dg/ is supposed to do.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-24 14:52 ---
It's supposed to specify the testsuite driver. That it does, but then
it forgets that it was supposed to run a specific test.
dg.exp=files_to_test
does it (without path).
What is not clear to me is what
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-21 08:55 ---
Is it not a duplicate of pr35203?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
--- Comment #12 from dominiq at lps dot ens dot fr 2010-06-20 20:10 ---
With the patch in comment #10, the modified test for pr31538 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31538#c5
integer :: a(-4:1), b(0:4)
b = 5
! a(-4:1) = b(0:4) ! Error: different shape for Array
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: *--apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44592
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-17 11:07 ---
Confirmed on thrunk after having added
integer :: dim = 2
in 'type :: lin_approx_cont_type'. The modified code compile with 4.5.0, hence
a regression I can trace between revisions 158215 (working) and 158921
--- Comment #14 from dominiq at lps dot ens dot fr 2010-06-17 12:30 ---
From comments #11 to #13, given links and
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01744.html closing as fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed
--- Comment #22 from dominiq at lps dot ens dot fr 2010-06-16 09:13 ---
(In reply to comment #20)
Could the patch in comment #17 explain the following failures? ...
False alarm! AFAICT the failures where due to messed up libs for mpfr and mpc
while trying to update to mpfr 3.0. Sorry
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-16 09:21 ---
The miscompilation occurs between -finline-limit=300 (works) and =400
(Segmentation fault). This seems related to the inlining of the subroutine
'fourir2d' (called 4 times with =400) instead of 'fourir' (called 14
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10.3.0
GCC host triplet: x86_64-apple-darwin10.3.0
GCC target triplet: x86_64-apple
: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44533
--- Comment #18 from dominiq at lps dot ens dot fr 2010-06-14 11:15 ---
With the patch in comment #17, x86_64-apple-darwin10 bootstrapped without
problem. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
--- Comment #20 from dominiq at lps dot ens dot fr 2010-06-14 12:32 ---
Could the patch in comment #17 explain the following failures?
FAIL: gcc.dg/torture/builtin-math-5.c -O0 scan-tree-dump-times original
cexpf 2
FAIL: gcc.dg/torture/builtin-math-5.c -O0 scan-tree-dump-times
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-13 09:52 ---
Confirmed on x86_64-apple-darwin10.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44505
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-13 11:46 ---
Could it be a duplicate of pr44509?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44512
--- Comment #16 from dominiq at lps dot ens dot fr 2010-06-13 11:47 ---
See also pr44512.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
at lps dot ens dot fr
GCC build triplet: *--apple-darwin*
GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-12 11:02 ---
Oops! fixed a typo in the summary.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-12 12:19 ---
On powerpc-apple-darwin9 at revision 160627, the minimal command is
/opt/gcc/darwin_buildw/prev-gcc/xgcc -B/opt/gcc/darwin_buildw/prev-gcc/ -c
-DIN_GCC_FRONTEND -g -mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-12 12:20 ---
Created an attachment (id=20901)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20901action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44509
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-12 14:31 ---
Just run
gdb ./cc1 -O2 pr44509.i
The *.i files compile without ICE, see comment #3:
The ICE disappears if -g is removed for any optimization, it also disappears
with -save-temps.
^^
[karma
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-12 15:01 ---
There should not be a /usr/include/float.h but the gcc internal header should
be included. Please check if that is the case
I don't understand what I am supposed to do (please use baby English;-). Why
did I
--- Comment #10 from dominiq at lps dot ens dot fr 2010-06-12 15:53 ---
Can you attach all headers that get included instead of attaching preprocessed
source? Thx.
How am I supposed to know what are all headers that get included? Please
assume zero knowledge from my side and provide
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-11 17:48 ---
For the record revision 160549 also broke boostrap on x86_64-apple-darwin10.3.0
near the end of stage 2:
echo CRTSTUFF_T_CFLAGS = '' tmp-libgcc.mvars
echo CRTSTUFF_T_CFLAGS_S = '' tmp-libgcc.mvars
echo
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 13:50 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
It does fix the bootstrap failure. I am currently
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-09 18:39 ---
The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html
It definitly avoids the ICE, but it would be nice to know if libstdc++
testsuite passes.
It does fix the bootstrap failure. I am currently
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 20:57 ---
*** Bug 2 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-09 20:57 ---
(In reply to comment #2)
This is a known limitation of array constructors handling by gfortran.
I was about to ask if this pr is a duplicate. From comment #3, it is; so I am
closing it as such.
For the record
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-08 08:53 ---
Created an attachment (id=20864)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20864action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-08 10:35 ---
Needs '-g -O1' to fails:
[macbook] i386/libjava% /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc
-nostdinc++ -DHAVE_CONFIG_H -I. -I../../../../work/libjava -I./include -I./gcj
-I../../../../work/libjava -Iinclude
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-08 10:37 ---
pr44460 is probably a duplicate. The test fails with -g -O1 and the backtrace
is
#0 fancy_abort (file=0x100ad07d0 ../../work/gcc/emit-rtl.c, line=1674,
function=0x100b42a40 set_mem_attributes_minus_bitpos
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-08 12:58 ---
Likely pr44453 and pr44460.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44467
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-07 13:49 ---
Useless temporaries are also emitted for PAD and ORDER optional arguments:
program main
integer :: i, k, l, m, n
real :: e1, e2
real, dimension(4,5) :: b
real, dimension(5,4) :: c
b = reshape([(i, i=1,20
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 08:00 ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00449.html
With this patch I am at stage 2, so this pr is a duplicate of pr44427 and
fixed.
*** This bug has been marked as a duplicate of 44427
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 08:00 ---
*** Bug 44428 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-06 08:05 ---
At r160335, I don't see the failure on x86_64-unknown-linux-gnu. Maybe it has
been fixed by some middle-end changes by now. Can anyone confirm that the
error
is gone?
No error for the flags I have tried
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-06 10:32 ---
gcc version 4.4.4 gives
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = foo
symtree: __convert_i4_i8 Ambig 0
symbol __convert_i4_i8 (INTEGER 8)(PROCEDURE
--- Comment #50 from dominiq at lps dot ens dot fr 2010-06-06 10:50 ---
On x86_64-apple-darwin10.3.0 between revisions 160235 and 160330 the failures
with -m32 went from
FAIL: gcc.c-torture/execute/builtins/abs-1.c compilation, -O2 -fwhopr
FAIL: gcc.c-torture/execute/builtins/memcpy
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-06 12:18 ---
It looks like a duplicate of the unfixed part of pr43945.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44434
--- Comment #51 from dominiq at lps dot ens dot fr 2010-06-06 13:46 ---
The 14 tests were fixed by revision 160258 (that has nothing to do with
darwin).
Also I see the following changes, 160257:
=== gcc tests ===
Schedule of variations:
unix/-m32
unix/-m64
--- Comment #52 from dominiq at lps dot ens dot fr 2010-06-06 20:23 ---
On powerpc-apple-darwin9 I see a similar improvement at revision 160335:
=== gcc tests ===
Schedule of variations:
unix/-m32
unix/-m64
Running target unix/-m32
Using /sw/share/dejagnu
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-06 20:39 ---
This was between rev. 149577 (works) and rev. 149607 (does not work).
The only candidate I see is 149586.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-05 09:52 ---
At revision 160309, I get
[macbook] lin/test% gfc -O3 -ffast-math -funroll-loops -fomit-frame-pointer
-fwhole-program -flto rnflow.f90 --param hot-bb-frequency-fraction=1000
[macbook] lin/test% time a.out /dev/null
--- Comment #28 from dominiq at lps dot ens dot fr 2010-06-05 09:54 ---
Is there any interest to understand what broke the test and what fixed it? If
not, I'll close this pr as fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: powerpc-apple-darwin9
GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-04 17:52 ---
Created an attachment (id=20842)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20842action=view)
assembly for recip-1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-04 17:52 ---
Created an attachment (id=20843)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20843action=view)
assembly for recip-2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-04 17:52 ---
Created an attachment (id=20844)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20844action=view)
assembly for recip-3.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
--- Comment #39 from dominiq at lps dot ens dot fr 2010-06-04 18:25 ---
I confirm that the failures for libjava reported in comment #33 were due to
some misconfiguration.
With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
http://gcc.gnu.org/bugzilla
--- Comment #33 from dominiq at lps dot ens dot fr 2010-06-03 14:52 ---
On x86_64-apple-darwin10.3.0 the patch in comment #26 applied on top of r160219
cause
=== libjava Summary for unix/-m64 ===
# of expected passes2459
# of unexpected failures62
--- Comment #35 from dominiq at lps dot ens dot fr 2010-06-03 15:21 ---
Extracted from x86_64-apple-darwin10.3.0/libjava/testsuite/libjava.log:
...
set_ld_library_path_env_vars:
ld_library_path=.:/opt/gcc/build_w/x86_64-apple-darwin10.3.0/./libjava/.libs
invoke: /opt/gcc/build_w/x86_64
--- Comment #70 from dominiq at lps dot ens dot fr 2010-06-03 18:23 ---
(In reply to comment #68)
That makes sense, so all we need to do in config/tls.m4 is probably:
1) move a_in_main_thread variable to file scope, and neither a_in_main_thread
nor a_in_other_thread should be static
--- Comment #37 from dominiq at lps dot ens dot fr 2010-06-03 20:57 ---
(In reply to comment #35)
Note the failures occur only with -m64, not with -m32.
This may due to a misconfiguration of libjava similar to pr43170. I am
bootstrapping with the latest patch and I'll redo the testing
--- Comment #32 from dominiq at lps dot ens dot fr 2010-06-02 08:59 ---
4.5-branch (as of r160013) has an error in config.gcc (which I just fixed on
trunk yesterday, with r159979) in which several t-make fragments are included
twice on x86_64-*-darwin*.
I wonder if this could
--- Comment #34 from dominiq at lps dot ens dot fr 2010-06-02 09:35 ---
can you do me a favor?
(a) copy the config.{log,out} files.
(b) rm -r and reconfigure/re-bootstrap w/out changing *anything*
.. I suspect a configure race condition - and would not be surprised if the
second
--- Comment #36 from dominiq at lps dot ens dot fr 2010-06-02 09:53 ---
Since I had a new comparison failure before your answer, I did the following:
(1) delete the various libgomp folders,
(2) resume make.
Indeed the new libgomp were correctly built and I am now building libgfortran
--- Comment #38 from dominiq at lps dot ens dot fr 2010-06-02 10:16 ---
make -jN all
or make -jn bootstrap?
make -j2 log_file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-02 16:35 ---
This looks like a duplicate of pr40873.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-02 16:51 ---
No, this is not fortran.
I am not sure that fortran matter here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44390
--- Comment #40 from dominiq at lps dot ens dot fr 2010-06-02 17:09 ---
Can you (someone with darwin) ...
I have tried:
[macbook] f90/bug% gcc46 pthread_create.c
[macbook] f90/bug% a.out ; echo $?
0
Is it the correct way to do the test? (so far I only got zeros).
--
http
--- Comment #42 from dominiq at lps dot ens dot fr 2010-06-02 18:22 ---
I am using the following script:
#!/bin/sh
i=0
tls.ex
while [ $? == 0 ]
do
i=`expr $i + 1`
tls.ex
done
echo $i
tls.ex is generated by
/opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/ -g -O2
--- Comment #43 from dominiq at lps dot ens dot fr 2010-06-02 18:36 ---
The following variant
#!/bin/sh
i=0
while [ $i != 1000 ]
do
i=`expr $i + 1`
tls.ex
if [ $? != 0 ]
then
echo $i
fi
done
gives
26
84
87
90
266
386
426
587
611
614
617
637
640
647
653
656
962
--- Comment #44 from dominiq at lps dot ens dot fr 2010-06-02 19:06 ---
This seems linked to the optimization:
[macbook] f90/bug% /opt/gcc/build_w/prev-gcc/xgcc -B/opt/gcc/build_w/prev-gcc/
-O2 -pthread pthread_create.c -o tls.ex
[macbook] f90/bug% rm -f tmp ; tls_1.sh tmp ; cat tmp
--- Comment #47 from dominiq at lps dot ens dot fr 2010-06-02 20:08 ---
At the risk of stating the obvious - since there are no DYLD_LIBRARY_PATH in
your posts...
Are you doing this uninstalled?
I guess you have to be sure that the right libgcc_s is being found -- or
emutls
--- Comment #50 from dominiq at lps dot ens dot fr 2010-06-02 20:19 ---
What is the output of
grep -i tls your_paths/libgomp/config.log
on darwin9?
For me the answer is gcc_cv_have_tls=no for both powerpc-apple-darwin9 gcc
4.6 r160081 and i686-apple-darwin9 gcc 4.5 r156693
--- Comment #53 from dominiq at lps dot ens dot fr 2010-06-02 20:39 ---
Created an attachment (id=20814)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20814action=view) [edit]
adds some TLS torture tests to gcc.dg
Hm - the placeholder, temporary fix for EMUTLS doesn't appear
--- Comment #55 from dominiq at lps dot ens dot fr 2010-06-02 20:59 ---
and on D10 - no @ stage1 (correct)
I see
[macbook] gcc/build_w% grep -i tls
stage1-x86_64-apple-darwin10.3.0/libgomp/config.log
| #define HAVE_TLS 1
| #define HAVE_TLS 1
| #define HAVE_TLS 1
| #define HAVE_TLS 1
201 - 300 of 2212 matches
Mail list logo
