[Bug target/81319] ICE in output_operand_lossage at final.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81319 --- Comment #3 from Vittorio Zecca --- This issue has been fixed in gcc 10.1.1-1.

[Bug target/79636] [8/9/10/11 Regression] ICE in assign_by_spills, at lra-assigns.c:1457

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79636 --- Comment #9 from Vittorio Zecca --- This issue has been fixed long ago. It should be closed.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #37 from Vittorio Zecca --- Fixed in 10.1.1.

[Bug fortran/50410] [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Vittorio Zecca changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug fortran/33056] [Meta-bug] Data - statement related bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 50410, which changed state. Bug 50410 Summary: [8/9/10/11 Regression] ICE in record_reference, pointer variable in data statement https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 What|Removed

[Bug fortran/50551] Argumentless NULL() cannot be used with assumed-length dummy (r178939)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50551 --- Comment #2 from Vittorio Zecca --- Still present at 10.1.1-1

[Bug testsuite/44791] data_3.f90 accesses uninitialized variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44791 Vittorio Zecca changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug debug/57933] function dwf_regno accesses dbx_register_map beyond its upper limit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57933 Vittorio Zecca changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug debug/61900] loc_descr_plus_const sanitizer runtime error in xgcc while building libgcc_s

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61900 Vittorio Zecca changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED

[Bug target/77273] 1 << 31 is undefined in gcc/config/i386/cpuid.h:93

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77273 Vittorio Zecca changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 --- Comment #23 from Vittorio Zecca --- The update proposed in comment #18 fixed the issue. Thank you!

[Bug fortran/50410] [4.7/4.8/4.9 Regression] ICE in record_reference

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Vittorio Zecca changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #14 from Vit

[Bug fortran/50406] ld undefined reference to __MOD_str

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Vittorio Zecca changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #1 from Vitt

[Bug fortran/44348] ICE in build_function_decl

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348 Vittorio Zecca changed: What|Removed |Added Version|4.5.0 |4.8.0 --- Comment #5 from Vitt

[Bug fortran/44350] accepts illegal fortran in BLOCK DATA

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44350 Vittorio Zecca changed: What|Removed |Added Version|4.5.0 |4.8.0 --- Comment #2 from Vitt

[Bug fortran/50069] FORALL fails on a character array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 Vittorio Zecca changed: What|Removed |Added Version|4.6.1 |4.8.0 --- Comment #4 from Vitt

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Vittorio Zecca changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #6 from Vitt

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50402 Vittorio Zecca changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #1 from Vitt

[Bug fortran/50539] Internal error gfc_match_entry(): Bad state (r178939)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50539 Vittorio Zecca changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #1 from Vitt

[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50541 Vittorio Zecca changed: What|Removed |Added Version|4.7.0 |4.8.0 --- Comment #4 from Vitt

[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #7 from Vittorio Zecca --- 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=

[Bug fortran/57749] New: -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

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

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #2 from Vittorio Zecca --- 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. It is not possible to make

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #4 from Vittorio Zecca --- 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 directions? z**-k and z**+k

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #7 from Vittorio Zecca --- 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 (real or integer) positive p

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #9 from Vittorio Zecca --- 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 any exception and deliver

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #12 from Vittorio Zecca --- > --- Comment #10 from Dominique d'Humieres --- >> Yes, I agree that there is a bug, ... > > Then you should report to the library maintainers, not to gfortran. The notion that this may be a library bug wa

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #16 from Vittorio Zecca --- 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 and give the expected r

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #20 from Vittorio Zecca --- 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 raising any exception end

[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #21 from Vittorio Zecca --- 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 of programmers? Should

[Bug fortran/50554] INQUIRE cannot redefine DO index (r178939)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554 --- Comment #5 from Vittorio Zecca --- 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!

[Bug fortran/44353] rejects legal fortran

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353 --- Comment #7 from Vittorio Zecca --- I believe this has been fixed with gfortran 4.8.1

[Bug fortran/50376] pure procedure allows assignment to iterator variable in array constructor

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50376 --- Comment #2 from Vittorio Zecca --- I believe this has been fixed in gfortran 4.8.1

[Bug fortran/57894] New: min/max required actual argument missing

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

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #4

[Bug fortran/57895] New: Segmentation fault in gfc_restore_last_undo_checkpoint

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=30503&action=edit Old dusty Fortran file The attached old dusty Fortran produces a Segmentation f

[Bug c/57896] New: ICE in in expand_expr_real_2

: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Created attachment 30504 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30504&action=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 te

[Bug c/57896] ICE in in expand_expr_real_2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #5 from Vittorio Zecca --- 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: : In function ‘__get_cpuid_max’: :1:1: inte

[Bug c/57896] ICE in in expand_expr_real_2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #6 from Vittorio Zecca --- 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 (unsigned int __level, u

[Bug c/57933] New: function dwf_regno accesses dbx_register_map beyond its upper limit

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

[Bug c/57980] New: gcc 4.8.1 -foptimize-sibling-calls -O1 ICE in build_int_cst_wide, at tree.c:1210

: 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. As in the

[Bug c/58218] New: -mcmodel=medium cause assembler warning "ignoring incorrect section type for .lbss"

NCONFIRMED 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. T

[Bug fortran/58224] New: -fcheck=pointer should detect that an unallocated allocatable data-target is forbidden

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

[Bug fortran/58225] New: In show_locus at fortran/error.c:391 pointer beyond end of line

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

[Bug fortran/58226] New: negative subscript pos at fortran/options.c:1205

: 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

[Bug fortran/58233] New: null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132

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 && ! c

[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 --- Comment #7 from Vittorio Zecca --- 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.

[Bug fortran/50375] New: gfortran must complain on NULL() ambiguity without MOLD

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 S

[Bug fortran/50375] gfortran must complain on NULL() ambiguity without MOLD

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375 --- Comment #1 from Vittorio Zecca 2011-09-13 08:54:47 UTC --- Created attachment 25254 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25254 Just compile it

[Bug fortran/50376] New: pure procedure allows assignment to iterator variable in array constructor

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: UNCO

[Bug fortran/50377] New: gfortran must not accept an external formal argument not declared external

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: UNCO

[Bug fortran/50377] gfortran must not accept an external formal argument not declared external

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377 --- Comment #1 from Vittorio Zecca 2011-09-13 09:01:03 UTC --- Created attachment 25256 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25256 just compile it

[Bug fortran/50378] New: MALLOC_CHECK_ glibc detects free() invalid pointer in compiler

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

[Bug fortran/50379] New: ICE in gfc_typenode_for_spec at fortran/trans-types.c

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

[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #4 from Vittorio Zecca 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?

[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #6 from Vittorio Zecca 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.

[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #8 from Vittorio Zecca 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 lookup error: /home/vitti/gc

[Bug fortran/50392] New: SIGSEGV in gfc_trans_label_assign

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

[Bug fortran/50393] New: free() invalid pointer in mio_expr

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

[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #10 from Vittorio Zecca 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() errors.

[Bug fortran/50393] free() invalid pointer in mio_expr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 --- Comment #3 from Vittorio Zecca 2011-09-14 20:03:44 UTC --- It seems to work now, no free() error messages. Maybe you can close the issue.

[Bug fortran/50401] New: SIGSEGV in resolve_transfer

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

[Bug fortran/50402] New: ICE in gfc_conv_expr_descriptor

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

[Bug fortran/50403] New: SIGSEGV in gfc_use_derived

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 C

[Bug fortran/50404] New: SIGSEGV in gfc_resolve_close

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50404 Bug #: 50404 Summary: SIGSEGV in gfc_resolve_close Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug fortran/50405] New: allocation LOOP or SIGSEGV

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405 Bug #: 50405 Summary: allocation LOOP or SIGSEGV Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 C

[Bug fortran/50406] New: ld undefined reference to __MOD_str

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406 Bug #: 50406 Summary: ld undefined reference to __MOD_str Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug fortran/50407] New: compiler confused by .operator.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 Bug #: 50407 Summary: compiler confused by .operator. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug fortran/50408] New: ICE in transfer_expr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50408 Bug #: 50408 Summary: ICE in transfer_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Compone

[Bug fortran/50409] New: SIGSEGV in gfc_simplify_expr

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50409 Bug #: 50409 Summary: SIGSEGV in gfc_simplify_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug fortran/50410] New: ICE in record_reference

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 Bug #: 50410 Summary: ICE in record_reference Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Comp

[Bug fortran/50411] New: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50411 Bug #: 50411 Summary: gfortran -Ofast SIGSEGV in vect_recog_dot_prod_pattern Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/50412] New: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50412 Bug #: 50412 Summary: gfortran -Ofast ICE in vect_do_peeling_for_loop_bound Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/50415] New: gfortran -Ofast SIGSEGV in find_uses_to_rename_use

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50415 Bug #: 50415 Summary: gfortran -Ofast SIGSEGV in find_uses_to_rename_use Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/50414] New: gfortran -Ofast SIGSEGV in store_constructor

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50414 Bug #: 50414 Summary: gfortran -Ofast SIGSEGV in store_constructor Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Prior

[Bug fortran/50416] New: gfortran -O1 ICE MPFR assertion failed: 0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50416 Bug #: 50416 Summary: gfortran -O1 ICE MPFR assertion failed: 0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority

[Bug fortran/50407] compiler confused by .operator.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #2 from Vittorio Zecca 2011-09-15 20:21:04 UTC --- I believe the code is valid, and it has nothing to do with recursive I/O. If you comment out the write in the mul function gfortran still fails, so it does not depend on recursive I/O

[Bug fortran/50403] SIGSEGV in gfc_use_derived

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #4 from Vittorio Zecca 2011-09-15 20:26:18 UTC --- I created it.

[Bug fortran/50426] New: gfortran -O1 ICE in estimate_function_body_sizes

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50426 Bug #: 50426 Summary: gfortran -O1 ICE in estimate_function_body_sizes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal P

[Bug fortran/50407] compiler confused by .operator.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #4 from Vittorio Zecca 2011-09-15 20:36:54 UTC --- I disagree, the Fortran 95 standard at R911 allows PRINT format and R913 says that format may be a default-char-expr Now, 2.ip.8 is a default character expression, or not? Again, the

[Bug fortran/50403] SIGSEGV in gfc_use_derived

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50403 --- Comment #6 from Vittorio Zecca 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 or extreme cases. I do believe

[Bug fortran/50407] compiler confused by .operator.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #11 from Vittorio Zecca 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 like the parser does not

[Bug fortran/50410] [4.6/4.7 Regression] ICE in record_reference

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50410 --- Comment #2 from Vittorio Zecca 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%g /2/ end

[Bug fortran/50514] New: gfortran should check ISHFT & ISHFTC aruments (r178939)

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 S

[Bug fortran/50515] New: gfortran should not accept an external that is a common (r178939)

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

[Bug fortran/50516] New: gfortran must detect illegal statements in a block data (r178939)

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

[Bug fortran/50517] New: gfortran must detect that actual argument type is different from dummy argument type (r178939)

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

[Bug fortran/50524] New: *** glibc detected *** invalid free() pointer on illegal code (r178939)

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: UNCONF

[Bug fortran/50525] New: gfortran should not allow early reference to entry dummy argument (r178939)

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: UN

[Bug fortran/50535] New: transformational intrinsic functions not allowed in statement functions

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: UNCONFI

[Bug fortran/50536] New: an input item shall not appear as the do-variable of any io-implied-do

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: UNCONFIR

[Bug fortran/50537] New: explicit interface required (r178939)

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:

[Bug fortran/50538] New: formal argument cannot be same as procedure name (r178939)

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

[Bug fortran/50539] New: Internal error gfc_match_entry(): Bad state (r178939)

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 Sev

[Bug fortran/50540] New: Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)

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

[Bug fortran/50541] New: gfortran should not accept a pointer as a generic-name (r178939)

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

[Bug fortran/50542] New: gfortran should detect violation of Fortran 95 R536 (r178939)

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

[Bug fortran/50546] New: gfortran should not accept missing operator (r178939)

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

[Bug fortran/50547] New: dummy procedure argument of PURE shall be PURE

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 Pri

[Bug fortran/50548] New: gfortran -fcheck=all run time would be nice to detect different shapes

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: UNCONFI

  1   2   3   4   5   6   >