* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
@ 2011-12-12 23:25 ` dominiq at lps dot ens.fr
2012-01-09 13:30 ` burnus at gcc dot gnu.org
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-12-12 23:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-12-12
Ever Confirmed|0 |1
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-12-12 23:21:37 UTC ---
I get the segmentation fault from 4.5.3 up to today trunk on both the multiple
files and with all of them concatenate in a single one.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
2011-12-12 23:25 ` [Bug fortran/51522] " dominiq at lps dot ens.fr
@ 2012-01-09 13:30 ` burnus at gcc dot gnu.org
2012-01-09 13:40 ` dominiq at lps dot ens.fr
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-01-09 13:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-01-09 13:28:47 UTC ---
With the patch for PR 51578 (for GCC 4.7), the ICE is fixed. For the lines
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception) &
use, intrinsic :: iso_c_binding
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
end function vect_Utils_vuNorm_c
one get the errors
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)&
1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind
1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression
I think the second one is perfect - there is no "USE ISO_C_Binding" statement
in "function vect_Utils_vuNorm_c".
The first error is not that good as the problem is the "&" in
function foo() &
use m
A better error message would be a syntax error, pointing at the "&" - but I
think it is not really needed and also not easy to give a helpful message.
Hence, I close this PR as FIXED. If you think something else should be
improved, feel free to reopen this bug.
Thanks Adrian for reporting the internal compiler error.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
2011-12-12 23:25 ` [Bug fortran/51522] " dominiq at lps dot ens.fr
2012-01-09 13:30 ` burnus at gcc dot gnu.org
@ 2012-01-09 13:40 ` dominiq at lps dot ens.fr
2012-01-31 16:11 ` dominiq at lps dot ens.fr
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-01-09 13:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-09 13:38:38 UTC ---
With the following change
--- pr51522.f90 2011-12-13 00:17:20.000000000 +0100
+++ pr51522_db.f90 2012-01-09 12:15:44.000000000 +0100
@@ -265,9 +266,11 @@ interface
integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
use, intrinsic :: iso_c_binding
end function vect_Utils_vuIsUnit_c
- integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
&
+ integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
use, intrinsic :: iso_c_binding
+ end function vect_Utils_vuTriIneqHolds_c
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
+ use, intrinsic :: iso_c_binding
end function vect_Utils_vuNorm_c
end interface
end module vect_Utils_F03
the code compiles (with a lot of warnings), but complains at link time:
Undefined symbols:
"_main", referenced from:
start in crt1.10.6.o
"_vect_Utils_getEPV", referenced from:
___vect_utils_type_f03_MOD_cache_epv_s in ccxe8Zdc.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (2 preceding siblings ...)
2012-01-09 13:40 ` dominiq at lps dot ens.fr
@ 2012-01-31 16:11 ` dominiq at lps dot ens.fr
2012-02-02 19:08 ` jb at gcc dot gnu.org
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-01-31 16:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
CC| |jb at gcc dot gnu.org
Resolution|FIXED |
--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-31 15:52:19 UTC ---
Revision 183681
Author: jb
Date: Sun Jan 29 20:29:50 2012 UTC (43 hours, 17 minutes ago)
Changed paths: 2
Log Message:
Reduce size of pointer_info tree, minor cleanups.
2012-01-29 Janne Blomqvist <jb@gcc.gnu.org>
* module.c (pointer_info): Make true_name and module pointers
rather than arrays, order pointers before other fields.
(free_pi_tree): free true_name and module as well.
(mio_read_string): Rename to read_string.
(mio_write_string): Remove.
(load_commons): Use read_string.
(read_module): Use read_string rather than mio_internal_string.
(write_blank_common): Call write_atom directly.
(write_symbol): Likewise.
gives again an ICE for the test case and the reduced one below. Since I see in
comment #2:
> With the patch for PR 51578 (for GCC 4.7), the ICE is fixed. For the lines ...
I cannot decide if the bug has been really fixed or only hidden, so I reopen
the PR.
Revision 183680 does not give any ICE
[macbook] f90/bug% /opt/gcc/gcc4.7p-183680/bin/gfortran -w pr51522_red.f90
pr51522_red.f90:94.10:
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
&
1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
pr51522_red.f90:96.7:
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression
while r183681 does
[macbook] f90/bug% /opt/gcc/gcc4.7p-183681/bin/gfortran -w pr51522_red.f90
pr51522_red.f90:94.10:
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
&
1
Error: Parameter 'c_int' at (1) has not been declared or is a variable, which
does not reduce to a constant expression
pr51522_red.f90:96.7:
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) bind
1
Error: Parameter 'c_double' at (1) has not been declared or is a variable,
which does not reduce to a constant expression
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
This is how much I can reduce the original test. Commenting any line in the
first two derived types make the ICE to go away (I lost patience after that;-).
Also trying to avoid the ton of warnings by defining the arguments in the last
interface block makes the ICE to go away.
module vect_Utils_type_F03
use, intrinsic :: iso_c_binding
type, bind(c) :: vect_Utils_sepv_t
type(c_funptr) :: f__set_hooks_static
type(c_funptr) :: f__set_contracts_static
type(c_funptr) :: f__dump_stats_static
type(c_funptr) :: f_vuIsZero
type(c_funptr) :: f_vuIsUnit
type(c_funptr) :: f_vuAreEqual
type(c_funptr) :: f_vuAreOrth
type(c_funptr) :: f_vuSchwarzHolds
type(c_funptr) :: f_vuTriIneqHolds
type(c_funptr) :: f_vuDot
type(c_funptr) :: f_vuProduct
type(c_funptr) :: f_vuNegate
type(c_funptr) :: f_vuNormalize
type(c_funptr) :: f_vuSum
type(c_funptr) :: f_vuDiff
end type
type, bind(c) :: vect_Utils_epv_t
type(c_funptr) :: f__cast
type(c_funptr) :: f__delete
type(c_funptr) :: f__exec
type(c_funptr) :: f__getURL
type(c_funptr) :: f__raddRef
type(c_funptr) :: f__isRemote
type(c_funptr) :: f__set_hooks
type(c_funptr) :: f__set_contracts
type(c_funptr) :: f__dump_stats
type(c_funptr) :: f__ctor
type(c_funptr) :: f__ctor2
type(c_funptr) :: f__dtor
type(c_funptr) :: f__load
type(c_funptr) :: f_addRef
type(c_funptr) :: f_deleteRef
type(c_funptr) :: f_isSame
type(c_funptr) :: f_isType
type(c_funptr) :: f_getClassInfo
end type
type, bind(c) :: vect_Utils_pre_epv_t
integer(c_int) :: avoid_empty_type
end type
type, bind(c) :: vect_Utils_post_sepv_t
type(c_funptr) :: f_vuIsUnit_post
type(c_funptr) :: f_vuAreEqual_post
type(c_funptr) :: f_vuAreOrth_post
type(c_funptr) :: f_vuSchwarzHolds_post
type(c_funptr) :: f_vuTriIneqHolds_post
type(c_funptr) :: f_vuNorm_post
type(c_funptr) :: f_vuDot_post
type(c_funptr) :: f_vuProduct_post
type(c_funptr) :: f_vuNegate_post
type(c_funptr) :: f_vuNormalize_post
type(c_funptr) :: f_vuSum_post
type(c_funptr) :: f_vuDiff_post
end type
type, bind(c) :: vect_Utils_pre_sepv_t
type(c_funptr) :: f_vuIsZero_pre
type(c_funptr) :: f_vuIsUnit_pre
type(c_funptr) :: f_vuAreEqual_pre
type(c_funptr) :: f_vuAreOrth_pre
type(c_funptr) :: f_vuSchwarzHolds_pre
type(c_funptr) :: f_vuTriIneqHolds_pre
type(c_funptr) :: f_vuNorm_pre
type(c_funptr) :: f_vuDot_pre
type(c_funptr) :: f_vuProduct_pre
type(c_funptr) :: f_vuNegate_pre
type(c_funptr) :: f_vuNormalize_pre
type(c_funptr) :: f_vuSum_pre
type(c_funptr) :: f_vuDiff_pre
end type
type vect_Utils_t
type(c_ptr) :: d_ior = c_null_ptr
type(vect_Utils_epv_t), pointer :: d_epv => null()
end type vect_Utils_t
interface cache_epv
module procedure cache_epv_s
end interface cache_epv
contains
subroutine cache_epv_s(self)
implicit none
class(vect_Utils_t) :: self
end subroutine cache_epv_s
end module vect_Utils_type_F03
module vect_Utils_F03
use vect_Utils_type_F03
interface
type(c_ptr) function get_sepv_c() bind(c, name="vect_Utils_getSEPV")
use, intrinsic :: iso_c_binding
end function get_sepv_c
integer(c_int) function vect_Utils_vuIsUnit_c(u, tol, exception) bind(c)
use, intrinsic :: iso_c_binding
end function vect_Utils_vuIsUnit_c
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
&
use, intrinsic :: iso_c_binding
real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception)
bind(c)
end function vect_Utils_vuNorm_c
end interface
end module vect_Utils_F03
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (3 preceding siblings ...)
2012-01-31 16:11 ` dominiq at lps dot ens.fr
@ 2012-02-02 19:08 ` jb at gcc dot gnu.org
2012-02-03 10:50 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-02-02 19:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #5 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-02 19:08:19 UTC ---
Sorry, I'm unable to reproduce the ICE with today's trunk. I tried to testcase
in comment #4 with and without the fixes from #3 as well as the original
testcase.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (4 preceding siblings ...)
2012-02-02 19:08 ` jb at gcc dot gnu.org
@ 2012-02-03 10:50 ` burnus at gcc dot gnu.org
2012-02-03 22:36 ` jb at gcc dot gnu.org
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-02-03 10:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-03 10:50:02 UTC ---
If I try the example of comment 4 with the line break before "&" undone and
using the newest 4.7 trunk (clean build), I see in valgrind:
==14154== Invalid read of size 4
==14154== at 0x52D345: resolve_symbol (resolve.c:10559)
==14154== by 0x54131F: do_traverse_symtree (symbol.c:3385)
==14154== by 0x530093: resolve_types (resolve.c:13859)
==14154== by 0x5243DB: gfc_resolve (resolve.c:13959)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (5 preceding siblings ...)
2012-02-03 10:50 ` burnus at gcc dot gnu.org
@ 2012-02-03 22:36 ` jb at gcc dot gnu.org
2012-02-04 0:20 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-02-03 22:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-03 22:36:13 UTC ---
(In reply to comment #6)
> If I try the example of comment 4 with the line break before "&" undone and
> using the newest 4.7 trunk (clean build), I see in valgrind:
>
> ==14154== Invalid read of size 4
> ==14154== at 0x52D345: resolve_symbol (resolve.c:10559)
> ==14154== by 0x54131F: do_traverse_symtree (symbol.c:3385)
> ==14154== by 0x530093: resolve_types (resolve.c:13859)
> ==14154== by 0x5243DB: gfc_resolve (resolve.c:13959)
Yes, I saw the same thing. But, as I didn't see any relation between
resolve.c:10559 and the r183681 patch, I assumed this was something which was
present before and didn't investigate further.
Also, looking at the r183681 patch itself at
http://gcc.gnu.org/ml/fortran/2012-01/msg00255.html, I find it difficult to see
how it can cause any problems (*knocking on wood*).
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (6 preceding siblings ...)
2012-02-03 22:36 ` jb at gcc dot gnu.org
@ 2012-02-04 0:20 ` dominiq at lps dot ens.fr
2012-02-05 21:04 ` jb at gcc dot gnu.org
2015-10-10 12:57 ` dominiq at lps dot ens.fr
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-02-04 0:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-02-04 00:19:16 UTC ---
> Yes, I saw the same thing. But, as I didn't see any relation between
> resolve.c:10559 and the r183681 patch, I assumed this was something which was
> present before and didn't investigate further.
Note that I did not say that the segmentation fault was caused by r183681. I
only said that it reappeared at this revision, in the same way I do not think
the problem has been fixed by r183010, but only hidden.
I have tried some versions I have and found that with r183001 there is no
segmentation fault for the reduced test in comment #4, only the original test
gives it, while for r179630 both give the segmentation fault. Note that I do
not get any segmentation fault for both tests on powerpc-apple-darwin9.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (7 preceding siblings ...)
2012-02-04 0:20 ` dominiq at lps dot ens.fr
@ 2012-02-05 21:04 ` jb at gcc dot gnu.org
2015-10-10 12:57 ` dominiq at lps dot ens.fr
9 siblings, 0 replies; 11+ messages in thread
From: jb at gcc dot gnu.org @ 2012-02-05 21:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
--- Comment #9 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-02-05 21:04:18 UTC ---
So the complete valgrind error message I get (with the comment #4 testcase
fixed per Tobias instructions in comment #6) is:
==14281== Invalid read of size 4
==14281== at 0x528B66: resolve_symbol (resolve.c:10559)
==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281== by 0x532503: resolve_types (resolve.c:13859)
==14281== by 0x527473: gfc_resolve (resolve.c:13959)
==14281== by 0x528C18: resolve_symbol (resolve.c:12715)
==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281== by 0x532503: resolve_types (resolve.c:13859)
==14281== by 0x527473: gfc_resolve (resolve.c:13959)
==14281== by 0x51ABBC: gfc_parse_file (parse.c:4594)
==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281== by 0x909CDC: do_compile (toplev.c:557)
==14281== by 0x90A853: toplev_main (toplev.c:2014)
==14281== Address 0x5ca8700 is 32 bytes inside a block of size 304 free'd
==14281== at 0x4C270BD: free (vg_replace_malloc.c:366)
==14281== by 0x546E91: gfc_undo_symbols (symbol.c:2898)
==14281== by 0x514F5A: reject_statement (parse.c:1743)
==14281== by 0x515A54: decode_statement (parse.c:316)
==14281== by 0x516D8C: next_statement (parse.c:778)
==14281== by 0x51801D: parse_spec (parse.c:2379)
==14281== by 0x51A9BD: gfc_parse_file (parse.c:4297)
==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281== by 0x909CDC: do_compile (toplev.c:557)
==14281== by 0x90A853: toplev_main (toplev.c:2014)
==14281== by 0x5712C4C: (below main) (libc-start.c:226)
==14281==
==14281== Invalid read of size 8
==14281== at 0x52869D: resolve_symbol (resolve.c:12726)
==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281== by 0x532503: resolve_types (resolve.c:13859)
==14281== by 0x527473: gfc_resolve (resolve.c:13959)
==14281== by 0x528C18: resolve_symbol (resolve.c:12715)
==14281== by 0x545EF0: do_traverse_symtree (symbol.c:3386)
==14281== by 0x532503: resolve_types (resolve.c:13859)
==14281== by 0x527473: gfc_resolve (resolve.c:13959)
==14281== by 0x51ABBC: gfc_parse_file (parse.c:4594)
==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281== by 0x909CDC: do_compile (toplev.c:557)
==14281== by 0x90A853: toplev_main (toplev.c:2014)
==14281== Address 0x5ca87e0 is 256 bytes inside a block of size 304 free'd
==14281== at 0x4C270BD: free (vg_replace_malloc.c:366)
==14281== by 0x546E91: gfc_undo_symbols (symbol.c:2898)
==14281== by 0x514F5A: reject_statement (parse.c:1743)
==14281== by 0x515A54: decode_statement (parse.c:316)
==14281== by 0x516D8C: next_statement (parse.c:778)
==14281== by 0x51801D: parse_spec (parse.c:2379)
==14281== by 0x51A9BD: gfc_parse_file (parse.c:4297)
==14281== by 0x557315: gfc_be_parse_file (f95-lang.c:250)
==14281== by 0x909CDC: do_compile (toplev.c:557)
==14281== by 0x90A853: toplev_main (toplev.c:2014)
==14281== by 0x5712C4C: (below main) (libc-start.c:226)
So the problem seems to be that when we hit the error in the interface
declaration, we call gfc_undo_symbols() -> gfc_release_symbol() ->
gfc_free_symbol() -> free(), but then we go and dereference pointers to this
freed memory.
Unfortunately I'm not really familiar enough with this part of the codebase to
know how to fix it properly.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Bug fortran/51522] ICE in gfortran 4.6.2, x86_64
2011-12-12 23:09 [Bug fortran/51522] New: ICE in gfortran 4.6.2, x86_64 adrian at llnl dot gov
` (8 preceding siblings ...)
2012-02-05 21:04 ` jb at gcc dot gnu.org
@ 2015-10-10 12:57 ` dominiq at lps dot ens.fr
9 siblings, 0 replies; 11+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-10-10 12:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51522
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |WAITING
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling various variants of the test with 4.8 up to trunk (6.0) under
valgrind does not give valgrind error (while I get some with 4.5 and 4.6).
Am I missing something?
^ permalink raw reply [flat|nested] 11+ messages in thread