http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
I could not reproduce the issue with version 4.8.2 20130920, probably
it has silently been
fixed sometime in the past.
Maybe this issue should be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58813
--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
I did not know about MALLOC_PERTURB_ I just put in my .bashrc profile
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
gfortran fails in different places if the input file is .f or .f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58813
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com ---
I found that
export MALLOC_PERTURB_=256
produces a quiet NaN. I'll use this one in my .bashrc
It seems to me that the earlier symptom of malfunctioning
is in symbol.c:5001 dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58813
--- Comment #8 from Vittorio Zecca zeccav at gmail dot com ---
If I use the option -fmax-errors=1 the ICE disappears, but using this
option as a default
would potentially increase the time needed to get an error free code.
A code containing many
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
! gfortran produces SIGSEV at run time for access to unassociated
allocatable/pointer arrays
! questionable bounds for unassociated allocatable/pointer arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
g95: complains about deallocated array passed to LBOUND
Intel ifort:
1 0 0
1 0 0
1 0 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
I do not think SIZE should be used to detect an undefined array
pointer, but a size of zero
warns the code that the array is mostly unusable and that perhaps
something is wrong,
while
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
I believe most times a code knows if and when the size of an array
must be nonzero,
so a zerosize array would raise suspicions in those cases.
Anyway in my opinion gfortran run time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #9 from Vittorio Zecca zeccav at gmail dot com ---
Unfortunately associated() does not allow unassociated array pointers as input
so your code works for allocatable arrays but not for array pointers.
Yes, a negative value for size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.7.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.7.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.5.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44350
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.5.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.6.1 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.7.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.7.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.7.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
Version|4.7.0 |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
It looks like it was fixed in 4.7.0 with the following error message
Error: NULL intrinsic at (1) in data transfer statement requires MOLD=
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
c gfortran 4.8.1 -ffpe-trap=zero or invalid produces SIGFPE
c Program received signal SIGFPE: Floating-point exception - erroneous
arithmetic operation.
c I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
I believe -O0 is the default optimization level, so it is important.
Of course the code I sent you is a fragment from a much larger program,
kind of c**x with c complex and x real
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
I am happy to refresh my complex analysis study of long ago.
The singularity of log(x) in zero is not essential.
Essential singularity means the Laurent seriesis infinite in both
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
Looking at the source code for cpowf, it computes x**y straightly as
exp(y*log(x)),
no check on y or x.
I am not happy with that, because I expect that complex zero raised to any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #9 from Vittorio Zecca zeccav at gmail dot com ---
Yes, I agree that there is a bug, and IMO it is in cpow/cpowf/cpowl.
With -ffpe-trap=invalid,zero,
as I wrote earlier, complex zero**I where I is integer equal to one,
does not raise
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #12 from Vittorio Zecca zeccav at gmail dot com ---
--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Yes, I agree that there is a bug, ...
Then you should report to the library maintainers, not to gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #16 from Vittorio Zecca zeccav at gmail dot com ---
You are being a little too hard on me, but so be it.
I believe there is only one special case, base==0,
and that there are only two ifs to put in cpow to avoid the floating exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #20 from Vittorio Zecca zeccav at gmail dot com ---
I did try Intel ifort and NAG nagfor, as I already wrote, and also
Solaris sunf90,
and all of them accept complex zero raised to an integer or real power
greater than zero, without
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #21 from Vittorio Zecca zeccav at gmail dot com ---
If the cost is the same, this is a good reason to let the library handle this
special case and let the programmer think about his/her business.
Shouldn't system software ease the life
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554
--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
No problem, it was low priority and with easy workaround.
gfortran has much much improved from first time I looked at it around 2005.
Keep up the good work!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
I believe this has been fixed with gfortran 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50376
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
I believe this has been fixed in gfortran 4.8.1
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
! required MIN/MAX actual argument associated with A2 is missing
! Exactly one actual argument shall be associated with each nonoptional dummy
argument
! gfortran should reject this code
i=min(a1=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
CC||zeccav at gmail
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Created attachment 30503
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30503action=edit
Old dusty Fortran file
The attached old dusty Fortran produces
a Segmentation fault
: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Created attachment 30504
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30504action=edit
C code causing an ICE in expand_expr_real_2
The attached code causes an ICE in in expand_expr_real_2,
This is from testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
Trying your vastly reduced test case, 152 lines vs 3057 of my original
test case, I am getting
an ICE in convert_move, at expr.c:452.
The following is my backtrace:
command-line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com ---
The following is a shorter version of Marc's test case:
__get_cpuid_max (unsigned int __ext, unsigned int *__sig) {
unsigned __edx;
__cpuid (0, 0, 0, 0, __edx);
}
int __get_cpuid
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compiling the following code with -m32 option
the gcc front end array extern int const
dbx_register_map[FIRST_PSEUDO_REGISTER]
declared in i386.h is accessed beyond
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
From a testsuite code, fpsub32s.c,
compiling it with -O1 -foptimize-sibling-calls
I get an ICE in build_int_cst_wide, at tree.c:1210
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
The following statement causes an assembler warning from gcc when compiled with
-mcmodel=medium
Any other -mcmodel suboptions work fine
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
! gfortran -fcheck=pointer should detect at run time that
! an unallocated allocatable data-target is forbidden
! in a data pointer
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
In show_locus at fortran/error.c:391 statement
spaces = gfc_widechar_display_length (*p++);
*p points beyond the end of input line, cmax too big
Maybe connected
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
gfortran 4.8.2 negative subscript pos at fortran/options.c:1205 statement
result[--pos] = '\0';
compiling the following
use iso_fortran_env
print *,compiler_options()
end
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
! null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132
! if (!c-expr || (gcc_assert(cm),(cm-attr.allocatable ! cm-attr.flavor !=
FL_PROCEDURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
Still in gfortran 4.8.1.
In trans-stmt.c:105
len = GFC_DECL_STRING_LEN (se.expr);
the pointer se.expr-decl_common.lang_specific is NULL.
Thus causing the segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
I just applied your fix and now gcc compiles succesfully with -Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #7 from Vittorio Zecca zeccav at gmail dot com ---
I forgot to mention that my code fragment comes from
#include sys/sdt.h
void
f(void)
{
for (;;)
_SDT_PROBE(0, 0, 1,(0));
}
Maybe you can find intelligent ways to exercise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #10 from Vittorio Zecca zeccav at gmail dot com ---
I just installed gcc-4.9.1 and it still has this bug.
It does not even compile itself (divtf3.c) with -Og.
: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
While building gcc/libgcc_s and using -fsanitize=undefined a runtime error is
detected in dwarf2out.c:1488:53
loc-dw_loc_next = int_loc_descriptor (-offset
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
After building gcc with -fsanitize=undefined, analyzing the gcc testsuite with
the sanitized cc1 I got runtime error messages
../../gcc-4.9.1/gcc/config/i386/i386.c:6556:60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61901
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
I am sorry about opening a duplicate.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Running sanitized cc1 on testsuite files fp-int-convert-float80-timode.c
and fp-int-convert-timode.c and fp-int-convert-float128-timode.c
I get the following
../../gcc-4.9.1/gcc/real.c:2136:15
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compiling testsuite code pr28045.c the sanitizer claims that a signed integer
overflow occurs at expmed.c:1071
../../gcc-4.9.1/gcc/expmed.c:1071:41: runtime error: signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61903
--- Comment #1 from Vittorio Zecca zeccav at gmail dot com ---
Same runtime error at line 1076 of expmed.c
v == ((HOST_WIDE_INT) 1 bitsize) - 1)
compiling pr28045.c
: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
The sanitizer claims that compiling the testsuite files pr21255-2-mb.c and
pr21255-4.c and pr21255-3.c and pr21255-2-ml.c
a zero variable length array
: minor
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compiling many testsuite files with a sanitized gfortran,
as in typebound_assignment_6.f03, elemental_subroutine_2.f90,
move_alloc_13.f90
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compiling the testsuite file unlimited_polymorphic_16 with sanitized gfortran
I get the following
../../gcc-4.9.1/gcc/fortran/interface.c:2667:43: runtime
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Analyzing with sanitized gfortran the following line
j=i**(-huge(0_8)-1)
I get the following message:
../../gcc-4.9.1/gcc/fortran/trans-expr.c:2107:48: runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #12 from Vittorio Zecca zeccav at gmail dot com ---
Yes, you did say it will be fixed in 4.9.2. Sorry.
I did:
export CFLAGS=-ggdb -Og
export CXXFLAGS=$CFLAGS
../gcc-4.9.1/configure --prefix=/home/vitti/local/gcc-4.9.1
--disable-lto
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
/* from pr32349.c */
// gcc -funroll-loops -O3
// ../../gcc-4.9.1/gcc/loop-iv.c:2272:24: runtime error:
// signed integer overflow: 9223372036854775807 - -9223372036854775808 cannot
be represented in type 'long
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
// from pr55569.c
// gcc -O
// ../../gcc-4.9.1/gcc/tree-ssa-loop-ivopts.c:4148:24: runtime error: signed
integer overflow: 4 * 4611686018427387903 cannot be represented in type 'long
int'
// offset
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
// from pr42049.c
// gcc -funroll-loops -O
// ../../gcc-4.9.1/gcc/loop-iv.c:2610:14: runtime error:
// signed integer overflow: 7 - -9223372036854775808 cannot be represented in
type 'long int'
// max = (up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
It appears not depending on i value, for i=1 or 2.
No explicit options used.
Of course I used options -fsanizitized=address -fsanitized=undefined
to generate gfortran.
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910
--- Comment #3 from Vittorio Zecca zeccav at gmail dot com ---
A fix for the offending instruction at trans-expr.c:2107
n = (unsigned HOST_WIDE_INT) (m 0 ? -m : m);
might be
n = (unsigned HOST_WIDE_INT) (m 0 ? - (unsigned HOST_WIDE_INT) m : m
: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
/* from testsuite p60183.c */
/* gcc 4.9.1 -S -O1 -ftree-loop-vectorize */
/* ../../gcc-4.9.1/gcc/tree-data-ref.c:2423:16: runtime error: signed integer
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Created attachment 33272
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33272action=edit
Used by test case
// gcc 4.9.1
// ../../gcc-4.9.1/gcc/diagnostic.c:274:42: runtime error: signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61943
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
gcc was compiled with -fsanitize=undefined option.
Call it gcc-sanitized.
Then I did
gcc-sanitized -S gccerr13.c -O
where gccerr13.c is the sample C code I sent bugzilla
The option -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61900
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
This happens when I build gcc itself with option -fsanitize=undefined,
at build time, in directory x86_64-unknown-linux-gnu/32/libgcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61942
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
This is what I get on x86-64 with a sanitized version of gcc:
~/local/gcc-4.9.1-sanitized/bin/gcc -S gccerr12.c -funroll-loops -O3
../../gcc-4.9.1/gcc/loop-iv.c:2272:24: runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61942
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com ---
If you cannot reproduce the issue, not even with options -funroll-loops -O3,
I believe this bug should be closed.
I'll look again at it with the new release.
I prefer not to work
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
/* gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 */
/* gcc 4.8.2-7 20131212 */
typedef struct {
float re,im;
} Complex;
void sub_(Complex *var_Dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776
--- Comment #3 from Vittorio Zecca zeccav at gmail dot com ---
Missing right brace at end of code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59776
--- Comment #5 from Vittorio Zecca zeccav at gmail dot com ---
I am sorry I was not clear enough, in your shorter test case, after s2 = s1;
there is a right brace } missing.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630
Vittorio Zecca zeccav at gmail dot com changed:
What|Removed |Added
CC||zeccav at gmail
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compilation of the following forces a negative shift, result undefined in my
opinion
/* gcc -S negative shift at fold-const.c:12095
* x86_64
* zerobits = prec - shiftc;
* because prec - shiftc = -8
* result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com ---
I found this one with -fsanitize=shift. The runtime error message says
shift exponent -8 is negative. Maybe this is also a sanitizer bug?
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Created attachment 33108
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33108action=edit
Same code as in the bug Description
The following code compiles fine without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61779
--- Comment #1 from Vittorio Zecca zeccav at gmail dot com ---
I forgot to say that gcc 4.9.0 fails but compiles correctly on gcc 4.8.3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069
Bug #: 50069
Summary: FORALL fails on a character array
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50070
Bug #: 50070
Summary: Segmentation fault at size_binop_loc in fold-const.c
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50071
Bug #: 50071
Summary: gfortran does not distinguish labels in different type
scoping units
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50072
Bug #: 50072
Summary: gfortran must not accept same name for external and
common
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50073
Bug #: 50073
Summary: gfortran must not accept function name when result
name is present
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375
Bug #: 50375
Summary: gfortran must complain on NULL() ambiguity without
MOLD
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375
--- Comment #1 from Vittorio Zecca zeccav at gmail dot com 2011-09-13
08:54:47 UTC ---
Created attachment 25254
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25254
Just compile it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50376
Bug #: 50376
Summary: pure procedure allows assignment to iterator variable
in array constructor
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
Bug #: 50377
Summary: gfortran must not accept an external formal argument
not declared external
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377
--- Comment #1 from Vittorio Zecca zeccav at gmail dot com 2011-09-13
09:01:03 UTC ---
Created attachment 25256
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25256
just compile it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378
Bug #: 50378
Summary: MALLOC_CHECK_ glibc detects free() invalid pointer in
compiler
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50379
Bug #: 50379
Summary: ICE in gfc_typenode_for_spec at fortran/trans-types.c
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-13
20:08:33 UTC ---
I thought I had the latest version of gfortran...
Where can I find the latest one, with sources?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com 2011-09-13
20:19:56 UTC ---
I have gfortran 4.6.1
I am downloading gcc-4.7.tar.xz from gfortran.org right now.
Tomorrow I'll check it, it is night here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378
--- Comment #8 from Vittorio Zecca zeccav at gmail dot com 2011-09-14
08:23:39 UTC ---
gfortran 4.7.0 fixes this one.
However, sometimes I get the following:
/home/vitti/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951:
symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
Bug #: 50392
Summary: SIGSEGV in gfc_trans_label_assign
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393
Bug #: 50393
Summary: free() invalid pointer in mio_expr
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378
--- Comment #10 from Vittorio Zecca zeccav at gmail dot com 2011-09-14
20:01:17 UTC ---
gfortran 4.7.0 has been compiled with the old mpfr 2.4.2, I just downloaded it,
this one will probably work.
Anyway gfortran 4.7.0 does not give free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393
--- Comment #3 from Vittorio Zecca zeccav at gmail dot com 2011-09-14
20:03:44 UTC ---
It seems to work now, no free() error messages. Maybe you can close the issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50401
Bug #: 50401
Summary: SIGSEGV in resolve_transfer
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402
Bug #: 50402
Summary: ICE in gfc_conv_expr_descriptor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403
Bug #: 50403
Summary: SIGSEGV in gfc_use_derived
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
1 - 100 of 564 matches
Mail list logo
