[Bug fortran/40678] New: ICE on invalid code, gfc_conv_variable

2009-07-07 Thread thomas dot orgis at awi dot de
org ReportedBy: thomas dot orgis at awi dot de GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40678

[Bug fortran/40583] automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

2009-06-30 Thread thomas dot orgis at awi dot de
--- Comment #4 from thomas dot orgis at awi dot de 2009-06-30 08:18 --- Hm, the gfortran program _is_ installed with that script. I have the evidence on my disk;-) It was created the same day the other current gcc/fortran files have been installed. Could it be a side-effect of building

[Bug fortran/40583] New: automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

2009-06-29 Thread thomas dot orgis at awi dot de
orgis at awi dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40583

[Bug fortran/40584] New: gfortran does not recognize .f95 files

2009-06-29 Thread thomas dot orgis at awi dot de
not recognize .f95 files Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de GCC build

[Bug fortran/40583] automatic preprocessing for .F90 or .F95 files fails with cc1 error (output filename specified twice)

2009-06-29 Thread thomas dot orgis at awi dot de
--- Comment #2 from thomas dot orgis at awi dot de 2009-06-29 12:51 --- Thanks for confirming that it _should_ work. Now the question is: What is wrong with the installation on my system so that it does not work? I see that gfortran is apparently trying to preprocess the .F95 files

[Bug fortran/40584] gfortran does not recognize .f95 files

2009-06-29 Thread thomas dot orgis at awi dot de
--- Comment #2 from thomas dot orgis at awi dot de 2009-06-29 12:54 --- Well, then, I have to assume that the Source Mage gcc install screws up. As to contact the vendor: I change that to fix that install process, as I am sort of part of said GNU/Linux vendor, the Source Mage

[Bug fortran/39931] New: ICE on invalid Fortran 95 code (bad pointer assignment), gimplify_expr at gimplify.c:6315

2009-04-27 Thread thomas dot orgis at awi dot de
at gimplify.c:6315 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de GCC build triplet

[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)

2008-11-04 Thread thomas dot orgis at awi dot de
--- Comment #8 from thomas dot orgis at awi dot de 2008-11-04 08:52 --- Ok, first, let me apologize for the 15 check is miscompiled statement... operator precedence got me there. The feature for stack-realignment I meant is __attribute__((force_align_arg_pointer)) I use this already

[Bug c/38001] New: regression in 4.3: alignment checks wrongly optimized away (runtime failure)

2008-11-03 Thread thomas dot orgis at awi dot de
Version: 4.3.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux

[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)

2008-11-03 Thread thomas dot orgis at awi dot de
--- Comment #1 from thomas dot orgis at awi dot de 2008-11-03 13:26 --- Created an attachment (id=16617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16617action=view) tar with the test source file, script to test the bug, example disassembly -- http://gcc.gnu.org/bugzilla

[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)

2008-11-03 Thread thomas dot orgis at awi dot de
--- Comment #3 from thomas dot orgis at awi dot de 2008-11-03 13:35 --- Are you saying that there is no way to protect my library from user programs that have misaligned stacks? The whole checking business is in vain, then? To sad that it working fine with older gccs made be believe

[Bug c/38001] regression in 4.3: alignment checks wrongly optimized away (runtime failure)

2008-11-03 Thread thomas dot orgis at awi dot de
--- Comment #5 from thomas dot orgis at awi dot de 2008-11-03 16:08 --- Aren't we talking about data on the stack? And, actually gcc-4.2 can realign the stack, if you ask it to. But, well ... in any case it would be very helpful if a programmer had a way to deal devensively with stack

[Bug fortran/36454] New: too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)

2008-06-06 Thread thomas dot orgis at awi dot de
Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454

[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)

2008-06-06 Thread thomas dot orgis at awi dot de
--- Comment #1 from thomas dot orgis at awi dot de 2008-06-06 21:45 --- Oh, btw: I reckon that this is independent of host system, but for reference: I tested this on x86-64-linux (gfortran 4.1.2 or such) and x86-linux (4.2.3 and 4.3.0). -- thomas dot orgis at awi dot de changed

[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression

2008-02-28 Thread thomas dot orgis at awi dot de
--- Comment #6 from thomas dot orgis at awi dot de 2008-02-28 10:40 --- Eh... one question: Does the fix in 4.3 just make the initialization with REAL exponent work (Fortran 2003, AFAIK) or does it also fix the error message when working in strict Fortran 95 mode (hm, I suppose

[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression

2008-02-27 Thread thomas dot orgis at awi dot de
--- Comment #3 from thomas dot orgis at awi dot de 2008-02-27 10:12 --- Well, that's good to hear that this is already fixed. Though it may be nit-picky to note that there isn't a 4.3 gfortran binary package on the page you pointed out but only 4.2 and trunk (4.4) ;-) I'll see when

[Bug fortran/35381] New: Real initialization problem (invalid error): Exponent at (1) must be INTEGER for an initialization expression

2008-02-26 Thread thomas dot orgis at awi dot de
Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thomas dot orgis at awi dot de GCC build triplet: x86_64-suse-linux GCC host triplet: x86_64-suse-linux GCC target triplet

[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression

2008-02-26 Thread thomas dot orgis at awi dot de
--- Comment #1 from thomas dot orgis at awi dot de 2008-02-26 17:37 --- I stripped a bit more and I think I got the root of the problem, illustrated by this more minimal example: MODULE data IMPLICIT NONE PRIVATE INTEGER, PARAMETER :: dat_dimension = 2 TYPE dat_sigtype