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
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
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
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
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.
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?
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
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
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=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=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
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=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
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=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=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.
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
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
: 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
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
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
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=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
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=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=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 #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 #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
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=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=
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=50552
--- Comment #3 from Vittorio Zecca zeccav at gmail dot com 2011-10-18
13:55:31 UTC ---
I am traveling in Korea, and I cannot look at the standard now.
If you believe this is a non-issue then please close it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514
--- Comment #4 from Vittorio Zecca zeccav at gmail dot com 2011-09-29
06:58:24 UTC ---
About run time checking: I believe the bit size of k is known at compile time,
and the overhead to check n against it is negligible as compared to computing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50546
Bug #: 50546
Summary: gfortran should not accept missing operator (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547
Bug #: 50547
Summary: dummy procedure argument of PURE shall be PURE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50548
Bug #: 50548
Summary: gfortran -fcheck=all run time would be nice to detect
different shapes
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50549
Bug #: 50549
Summary: should detect different type parameters in structure
constructors (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550
Bug #: 50550
Summary: does not recognize pointer variable at initialization
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50551
Bug #: 50551
Summary: Argumentless NULL() cannot be used with assumed-length
dummy (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552
Bug #: 50552
Summary: type name cannot be statement function dummy argument
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50553
Bug #: 50553
Summary: statement function cannot be target (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554
Bug #: 50554
Summary: INQUIRE cannot redefine DO index(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555
Bug #: 50555
Summary: synonymous namelist/statement function dummy argument
not allowed (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556
Bug #: 50556
Summary: cannot save namelist group name
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com 2011-09-28
09:20:40 UTC ---
I meant checking static expressions at compilation time, as in my example.
This has no cost at run time.
You proposed a run time check that still should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50535
Bug #: 50535
Summary: transformational intrinsic functions not allowed in
statement functions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50536
Bug #: 50536
Summary: an input item shall not appear as the do-variable of
any io-implied-do
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50537
Bug #: 50537
Summary: explicit interface required (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538
Bug #: 50538
Summary: formal argument cannot be same as procedure name
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539
Bug #: 50539
Summary: Internal error gfc_match_entry(): Bad state
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540
Bug #: 50540
Summary: Internal Error: Can't convert UNKNOWN to INTEGER(4)
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541
Bug #: 50541
Summary: gfortran should not accept a pointer as a generic-name
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542
Bug #: 50542
Summary: gfortran should detect violation of Fortran 95 R536
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50524
Bug #: 50524
Summary: *** glibc detected *** invalid free() pointer on
illegal code (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50525
Bug #: 50525
Summary: gfortran should not allow early reference to entry
dummy argument (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50514
Bug #: 50514
Summary: gfortran should check ISHFT ISHFTC aruments
(r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50515
Bug #: 50515
Summary: gfortran should not accept an external that is a
common (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50516
Bug #: 50516
Summary: gfortran must detect illegal statements in a block
data (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50517
Bug #: 50517
Summary: gfortran must detect that actual argument type is
different from dummy argument type (r178939)
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410
--- Comment #2 from Vittorio Zecca zeccav at gmail dot com 2011-09-18
17:38:10 UTC ---
The following produces a Segmentation fault in gfc_conv_structure (r178925)
type t
integer g
end type
type(t) :: u=t(1)
data u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com 2011-09-16
07:12:52 UTC ---
You asked where do I get such an enormous amount of invalid fortran code.
Probably I was too terse in my answer.
I created invalid codes to check corner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
--- Comment #11 from Vittorio Zecca zeccav at gmail dot com 2011-09-16
07:22:09 UTC ---
If you add
character(9) s
s=2.ip.8
gfortran, and g95, compile successfully.
On the contrary gfortran fails to parse
write(6,fmt=2.ip.8)
To me, it looks
401 - 500 of 564 matches
Mail list logo
