--- Comment #42 from jv244 at cam dot ac dot uk 2010-09-10 09:58 ---
(In reply to comment #40)
> Please give it a look, and file bugs related to missing or broken
> customizations in the new "Bugzilla" product on the test installation, i.e.
> using this link:
&
--- Comment #20 from jv244 at cam dot ac dot uk 2010-09-10 06:36 ---
Tobias,
many thanks for working on this... I mentioned this before in the PR, but it
would be very good if some line number testcases were added to the regression
tests. Both for performance measurements and debugging
--- Comment #4 from jv244 at cam dot ac dot uk 2010-09-08 18:22 ---
(In reply to comment #3)
> just a question. why is this illegal ?
it is R528 in the section on the data statement of the F2003 standard that
suggests this has to be a scalar-structure-component. Not so obvious why,
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
--- Comment #2 from jv244 at cam dot ac dot uk 2010-09-07 19:30 ---
Actually works with 4.5 but fails with trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #1 from jv244 at cam dot ac dot uk 2010-09-07 19:28 ---
Simple testcase (gfortran -flto test.f90):
MODULE M1
INTEGER, PARAMETER :: dp=8
TYPE realspace_grid_type
REAL(KIND=dp), DIMENSION ( :, :, : ), ALLOCATABLE :: r
END TYPE realspace_grid_type
END MODULE
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
CC||tkoenig at netcologne dot de
Target Milestone
dTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45576
--- Comment #18 from jv244 at cam dot ac dot uk 2010-08-29 15:07 ---
FYI, these are the 4.5 branch timings:
Execution times (seconds)
garbage collection: 0.47 ( 1%) usr 0.00 ( 0%) sys 0.47 ( 1%) wall
0 kB ( 0%) ggc
callgraph construction: 0.05 ( 0%) usr 0.01 ( 1
--- Comment #16 from jv244 at cam dot ac dot uk 2010-08-29 06:38 ---
adjust summary according to the last timings
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #15 from jv244 at cam dot ac dot uk 2010-08-29 05:31 ---
Similar times (a bit faster) with release checking:
Execution times (seconds)
garbage collection: 1.17 ( 1%) usr 0.00 ( 0%) sys 1.18 ( 1%) wall
0 kB ( 0%) ggc
callgraph construction: 0.04 ( 0%) usr
--- Comment #13 from jv244 at cam dot ac dot uk 2010-08-29 05:20 ---
(In reply to comment #12)
> >Extra diagnostic checks enabled; compiler may run slowly.
>
> Make sure you configure the trunk with --enable-checking=release to get the
> same timing results as what a r
--- Comment #11 from jv244 at cam dot ac dot uk 2010-08-29 05:09 ---
After David's patch (thanks!), the testcase requires 240s, that's still a 5x
slowdown. I paste the new timing profile below, and reopen the bug. There is no
obvious candidate for the slowdown.
> gfort
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-27 11:45 ---
(In reply to comment #3)
>
> this connection with bounds-checking makes it sound familiar.
>
I had a similar bug open (and fixed) as PR43627
with a comment from you
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from jv244 at cam dot ac dot uk 2010-08-26 18:34 ---
Created an attachment (id=21573)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21573&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45422
eases 8x.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot u
--- Comment #10 from jv244 at cam dot ac dot uk 2010-08-20 08:57 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Error: Dummy 'x' at (1) cannot have an initializer
>
> Do you have a suggestion?
>
Error: Dummy argument 'x' at (1) c
--- Comment #5 from jv244 at cam dot ac dot uk 2010-08-19 14:24 ---
(In reply to comment #4)
> Not sure what exactly Fortran needs -fexceptions for currently, one reason
> could be pthread_cancel, but at least with OpenMP pthread_cancel isn't going
> to
> do very n
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-19 09:22 ---
(In reply to comment #1)
> module ptrmod
> contains
> subroutine lengthX(x, i)
>implicit none
>real, pointer, intent(out) :: x(:)=>null()
you can't initialize a dummy argument, since init
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|4.5.2 |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45186
--- Comment #7 from jv244 at cam dot ac dot uk 2010-08-13 18:20 ---
(In reply to comment #6)
> With or without the other patch, the gimple code has:
isn't the gimple output showing linenumbers even in the case where the
.original dump is missing them ?
--
http://gcc
--- Comment #4 from jv244 at cam dot ac dot uk 2010-08-13 10:11 ---
(In reply to comment #3)
> Might be related to pr41359 (whose patch was not committed).
I think it is unrelated, since this used to work in 4.3, while pr41359 never
worked AFAICT. Nevertheless, would be nice to com
gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45242
--- Comment #2 from jv244 at cam dot ac dot uk 2010-08-05 11:13 ---
confirmed with 4.5/4.6, works with 4.3/4.4. Compiling with
-fdump-tree-all-lineno and looking into tx_f90_pointers.f90.003t.original shows
that most of the lineno info has disappeared in 4.5.
--
jv244 at cam dot ac
code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45172
--- Comment #17 from jv244 at cam dot ac dot uk 2010-07-24 18:15 ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873#c1 still fails with current
trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #20 from jv244 at cam dot ac dot uk 2010-07-24 18:12 ---
is this now fixed, all test cases seem to be passing ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
--- Comment #10 from jv244 at cam dot ac dot uk 2010-07-24 17:58 ---
with -fwhole-file being the default this testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817#c5
gets properly inlined at -O2. Yeah!
I think this can be closed, but probably one would like to add a testcase
--- Comment #63 from jv244 at cam dot ac dot uk 2010-07-24 11:14 ---
even better testcase... no mismatching arguments:
SUBROUTINE fft_3d ( )
CALL fftsg3d ()
END SUBROUTINE fft_3d
SUBROUTINE fft_1dm ( )
END SUBROUTINE fft_1dm
SUBROUTINE fftsg3d ( )
CALL mltfftsg ( )
END
--- Comment #62 from jv244 at cam dot ac dot uk 2010-07-24 11:10 ---
a testcase...
> cat bug.f90
SUBROUTINE fft_3d ( fft_type, fft_in_place, fsign, scale, n, zin, zout )
CALL fftsg3d ( fft_in_place, fsign, scale, n, zin, zout )
END SUBROUTINE fft_3d
SUBROUTINE fft_
--- Comment #61 from jv244 at cam dot ac dot uk 2010-07-24 08:24 ---
(In reply to comment #60)
> it seems possible to retain only the first 60498 lines of all.f90 (till the
> end
> of module fft_tools), and add END to get a much smaller testcase...
I've started a delt
--- Comment #60 from jv244 at cam dot ac dot uk 2010-07-23 22:55 ---
(In reply to comment #59)
> I have no easy testcase
it seems possible to retain only the first 60498 lines of all.f90 (till the end
of module fft_tools), and add END to get a much smaller testcase...
--
h
--- Comment #59 from jv244 at cam dot ac dot uk 2010-07-23 22:15 ---
I'm trying a recent trunk (162490), and I'm still observing that -fwhole-file
causing linking errors. I have no easy testcase, the way to reproduce is:
download http://www.pci.unizh.ch/vandev
--- Comment #8 from jv244 at cam dot ac dot uk 2010-07-08 08:55 ---
(In reply to comment #7)
> Yes, it would be possible to keep other threads around, the question is how
> many and how long, at which point start to destroy them.
I can test what other implementations are doing,
--- Comment #6 from jv244 at cam dot ac dot uk 2010-07-08 06:24 ---
I have also tried to run the testcase with
export OMP_WAIT_POLICY=active
export GOMP_SPINCOUNT=infinity
which I would assume to keep the threads alive, and so there would be no need
to create these new threads (the
--- Comment #5 from jv244 at cam dot ac dot uk 2010-07-06 11:32 ---
I also checked the pgi and cray compilers, they all lead to iforts thread
binding.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
--- Comment #4 from jv244 at cam dot ac dot uk 2010-07-06 10:01 ---
(In reply to comment #3)
> That's how GOMP_CPU_AFFINITY works - it is a round-robin assignment of CPUs
> upon thread creation, and the first two threads are never recreated in this
> case.
> Curr
--- Comment #2 from jv244 at cam dot ac dot uk 2010-07-06 08:05 ---
Created an attachment (id=21100)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21100&action=view)
fortran testcase
build & run testcase as :
gfortran -fopenmp test.f90 get_affinity.c
export OMP_NU
--- Comment #1 from jv244 at cam dot ac dot uk 2010-07-06 08:03 ---
Created an attachment (id=21099)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21099&action=view)
testcase part 1
C code to report thread binding
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44833
l be attached.
--
Summary: unexpected thread binding for openmp
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv2
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-30 07:14 ---
similar error compiling CP2K with rev 161570, (rev 161517 was still OK).
/data/vondele/gcc_bench/cp2k/makefiles/../src/qs_rho0_methods.F:850:0: error:
unrecognizable insn:
(insn 6975 398 6976 13
/data/vondele/gcc_bench
--- Comment #20 from jv244 at cam dot ac dot uk 2010-06-25 09:28 ---
(In reply to comment #18)
> That part comes from the questionable testcase, which does
> a_sp => matrix%local_data_sp
> before the loop unconditionally, eventhough matrix%local_data_sp is
> uninitialize
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-24 22:04 ---
can reproduce this anymore, closing as fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2010-06-22 05:46 ---
this has disappeared for current trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
n: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44622
--- Comment #9 from jv244 at cam dot ac dot uk 2010-06-21 15:49 ---
(In reply to comment #7)
> I cannot reproduce the factor of 10 results, however.
Here this still is the case (so might depend on the precise architecture):
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unkn
t(none)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known to work||4.5.1
Summary|ICE: segfault: |[4.6 Regression
: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
--- Comment #1 from jv244 at cam dot ac dot uk 2010-06-10 19:12 ---
Created an attachment (id=20886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20886&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44496
--- Comment #56 from jv244 at cam dot ac dot uk 2010-05-26 13:13 ---
(In reply to comment #55)
> Subject: Bug 40011
>
> Author: pault
> Date: Wed May 26 05:11:04 2010
> New Revision: 159852
I'm still having linking problems with -fwhole-file on the single source
--- Comment #47 from jv244 at cam dot ac dot uk 2010-05-23 06:31 ---
all dependencies are fixed, and so is this bug.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #8 from jv244 at cam dot ac dot uk 2010-05-22 14:09 ---
(In reply to comment #7)
> 4.5.1, using '-O2 -funswitch-loops'
obviously '-O2 -funswitch-loops -fbounds-check'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
--- Comment #1 from jv244 at cam dot ac dot uk 2010-05-16 06:57 ---
reduced testcase:
module mod_tetgen
use iso_c_binding
type tetgenio
double precision, pointer :: pointlist(:,:)
integer :: numberoffacets = 0
end type tetgenio
contains
subroutine tetgenf( in, out
--- Comment #53 from jv244 at cam dot ac dot uk 2010-05-03 10:57 ---
testcase in comment #40 now works. Comment #42 still fails.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #13 from jv244 at cam dot ac dot uk 2010-05-03 07:46 ---
these might be fixed in current trunk as a result of the fixes to PR43879
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #17 from jv244 at cam dot ac dot uk 2010-04-30 15:26 ---
in this case the Fortran bits depend on PR40011
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #20 from jv244 at cam dot ac dot uk 2010-04-28 15:20 ---
(In reply to comment #18)
>
> If that's all acceptable I will work on this soon.
>
FYI, this would fix PR38318 and PR21046
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #11 from jv244 at cam dot ac dot uk 2010-04-27 18:25 ---
the original loop gets now (4.6.0) vectorized, and gets the same performance as
the 'hand optimized loop' (which does not get vectorized):
> ./a.out
default loop 0.880055003
hand o
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-27 18:07 ---
still fails with current trunk.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-26 11:06 ---
I have been trying to reduce more, but this is the smallest so far, seems like
it needs the derived types, the 2D arrays, the pointers. I've reduced this with
4.5.1, using '-O2 -funswitch-loops'
MODUL
--- Comment #16 from jv244 at cam dot ac dot uk 2010-04-24 18:12 ---
(In reply to comment #15)
>
> pos is undefined.
>
Ah, we're at that level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
--- Comment #14 from jv244 at cam dot ac dot uk 2010-04-24 17:58 ---
(In reply to comment #13)
> For even more completeness, the code in comment #12 is still
> invalid.
do you mind to clarify ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-24 12:25 ---
This was also ported back to 4.5.1, causing a regression there. This is against
the policy of 'open for regression and documentation fixes'. It was also never
approved for the branch only trunk.
2010-04-16
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-23 20:17 ---
as per comment #4, and reconfirmed for trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2010-04-23 17:29 ---
both testcases work with 4.1.2. I've also checked various versions of valgrind,
which all report consistent results. Also 4.5 only fails on the original
testcase. for reference, -v gives:
gcc-4.5/bin/gfortran-4.
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-23 13:32 ---
(In reply to comment #4)
> Hm, I can't reproduce this.
I see, the reduced testcase (comment #2) indeed doesn't fail with trunk
anymore, but the original does (but only at -O3 -fbounds-check).
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-23 10:30 ---
It looks like in the .optimized dump these:
a_sp$offset = amat->local_data_sp.offset;
a_sp$dim$1$stride = amat->local_data_sp.dim[1].stride;
a_sp$dim$1$ubound = amat->local_data_sp.dim[1].ubound;
a
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-23 09:25 ---
reduced testcase:
IMPLICIT NONE
INTEGER, PARAMETER :: sp=4, dp=8
TYPE cp_fm_type
REAL(KIND=sp), DIMENSION(:,:), POINTER :: local_data_sp
REAL(KIND=dp), DIMENSION(:,:), POINTER :: local_data
INTEGER
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-23 09:21 ---
The error also appears with:
gfortran -fbounds-check -O1 -funswitch-loops test.f90
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43866
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-21 17:53 ---
(In reply to comment #2)
> See patch at http://gcc.gnu.org/ml/fortran/2010-04/msg00222.html and follow up
> at PR 43837
beats the speed of light... thanks.
A very practical question. Is Fortran code compile
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-21 15:30 ---
4.3.1 ([gcc-4_3-branch revision 135036]) does not fail, so marking as
regression.
4.5.0 works as well
with 4.4.4 I have this backtrace:
(gdb) bt
#0 bitmap_element_allocate (head=0x10284c0) at
/data03/vondele
rror: Segmentation fault
--
Summary: ice with -fexceptions and -fopenmp
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
As
--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-20 17:53 ---
yawn valid testcase here ftp://ftp.berlios.de/pub/cp2k/cp2k.tar.gz
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-19 11:56 ---
(In reply to comment #6)
> > If you have svn write access you have full bugzilla rights if you use
> > a bugzilla account with your @gcc.gnu.org address.
>
> Indeed I don't have "svn write a
--- Comment #3 from jv244 at cam dot ac dot uk 2010-04-19 09:23 ---
Dominique, you should ask for 'bugzilla confirmation rights' which will allow
to touch the 'Confirm' fields etc...
--
jv244 at cam dot ac dot uk changed:
What|Removed
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-19 07:52 ---
small enough for pasting:
> cat bug.f90
MODULE fft_tools
INTEGER, PARAMETER :: sp=4, dp=8
INTEGER, PARAMETER :: lp = dp
CONTAINS
SUBROUTINE sparse_alltoall ( rs, scount, sreq, rq, rcount, rreq, gr
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-11 18:02 ---
looks like we have a patch...
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-10 19:04 ---
still present in 4.6. The issue seems to be missing location info for the
nested if [if (a>0) ], the missing info in the original dump appears as a
incorrect line:7 in the gimple. It is specific to the 'else
--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-02 14:17 ---
(In reply to comment #9)
> Created an attachment (id=20290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290&action=view) [edit]
> smaller testcase (needs 3s, 80% in tree canonical iv)
from va
--- Comment #9 from jv244 at cam dot ac dot uk 2010-04-02 14:07 ---
Created an attachment (id=20290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290&action=view)
smaller testcase (needs 3s, 80% in tree canonical iv)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #7 from jv244 at cam dot ac dot uk 2010-04-02 12:28 ---
(In reply to comment #6)
> What's your native arch? I can't reproduce this on a core i?86.
-v output:
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/f951
hog.f90 -march=k
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-02 09:47 ---
(In reply to comment #3)
cows with cows now (i.e. --enable-checking=release), on an idle machine.
Execution times (seconds)
garbage collection: 0.29 ( 0%) usr 0.00 ( 0%) sys 0.31 ( 0%) wall
0 kB ( 0
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-02 09:26 ---
(In reply to comment #3)
> This tells me you are comparing apples and cows: "Extra diagnostic checks
> enabled; compiler may run slowly."
>
> Could you try again with a compiler configured
--- Comment #2 from jv244 at cam dot ac dot uk 2010-04-02 08:27 ---
And a timing report as well (notice the machine is not fully idle). The major
consumer is tree canonical.
Execution times (seconds)
garbage collection: 7.71 ( 2%) usr 0.07 ( 4%) sys 14.12 ( 2%) wall
0
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-02 08:16 ---
Created an attachment (id=20287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20287&action=view)
testcase
reproduce with
gfortran -fbounds-check -g -O3 -ffast-math -funroll-loops -ftree-vectorize
-march
gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43627
--- Comment #4 from jv244 at cam dot ac dot uk 2010-04-02 05:29 ---
(In reply to comment #2)
> I think .mod files are not obvious; the standard does not say anything about
> them, though (almost?) all compilers use them. On the other hand, few people
> seem to have problems
--- Comment #6 from jv244 at cam dot ac dot uk 2010-04-01 12:42 ---
(In reply to comment #4)
> The bug reporter explicitly specified --disable-multilib, yet gcc-4.5
> apparently now tries to build libgcc with -m32.
right... you've been faster. I've added the l
--- Comment #5 from jv244 at cam dot ac dot uk 2010-04-01 12:41 ---
Created an attachment (id=20273)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20273&action=view)
log of the build
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Summary|bootstrap fails:|[4.5 Regression] bootstrap
|/usr/include/gnu/stubs.h:7
--- Comment #1 from jv244 at cam dot ac dot uk 2010-04-01 07:06 ---
svn versions:
last known good: 157842
first known bad: 157896
CCing a RM
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43615
rsion: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43592
--- Comment #2 from jv244 at cam dot ac dot uk 2010-03-30 17:58 ---
confirmed.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED
1 - 100 of 1193 matches
Mail list logo
