[Bug tree-optimization/97020] [11 regression] new SVE failures after g:47ddf4c7b1d4471cb9534f27844ab5e4279c2168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97020 --- Comment #7 from Tamar Christina --- I can confirm this fixes the regressions too. Thanks!
[Bug target/97030] [nvptx] Need strategy for nvidia JIT bug workarounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97030 --- Comment #2 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > ATM, we have the following in the nvptx.c source code: > ... > #define WORKAROUND_PTXJIT_BUG 1 > #define WORKAROUND_PTXJIT_BUG_2 1 > #define WORKAROUND_PTXJIT_BUG_3 1 > ... I've tested disabling individual workarounds on a quadro m1200 with latest llb driver, version 450.66 and libgomp testsuite: > #define WORKAROUND_PTXJIT_BUG 1 Disabling this gives me these extra failures: ... FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop-nest.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-loop-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-6.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vprop-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/kernels-loop-nest.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/parallel-loop-1.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/reduction-6.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/vprop-2.c -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-fortran/pr96628-part1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O1 execution test FAIL: libgomp.oacc-fortran/pr96628-part1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-fortran/pr96628-part1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.oacc-fortran/pr96628-part1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O3 -g execution test FAIL: libgomp.oacc-fortran/pr96628-part1.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -Os execution test FAIL: libgomp.oacc-fortran/reduction-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O1 execution test FAIL: libgomp.oacc-fortran/reduction-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-fortran/reduction-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.oacc-fortran/reduction-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O3 -g execution test FAIL: libgomp.oacc-fortran/reduction-5.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -Os execution test FAIL: libgomp.oacc-fortran/reduction-6.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O1 execution test FAIL: libgomp.oacc-fortran/reference-reductions.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O1 execution test FAIL: libgomp.oacc-fortran/reference-reductions.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 execution test FAIL: libgomp.oacc-fortran/reference-reductions.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: libgomp.oacc-fortran/reference-reductions.f90 -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O3 -g execution test ... > #define WORKAROUND_PTXJIT_BUG_2 1 Disabling this gives me the usual errors. > #define WORKAROUND_PTXJIT_BUG_3 1 Disabling this gives me the usual errors.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #1 from Alan Modra --- Yes, reverting 5d3ae76af13 cures this PR.
[Bug target/97042] New: powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Bug ID: 97042
Summary: powerpc64 UINT_MAX constant
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
/* -O2 -S */
long foo (long x) { return ~0u - x; }
for gcc-8 to current master
lis 9,0x
ori 9,9,0x
rldicl 9,9,0,32
subf 3,3,9
blr
a regression from gcc-7
li 9,-1
rldicl 9,9,0,32
subf 3,3,9
blr
Both sequences give the same result, this is just a code quality regression.
I haven't properly debugged this but I suspect commit 5d3ae76af13
[Bug fortran/89219] ICE with derived type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #5 from Jerry DeLisle --- See also PR97037.
[Bug c++/97022] -Werror flag aborts compilation of "current" git pull on main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97022 --- Comment #1 from George R. Goffe --- Thanks for the info. This bug report can be closed now. Again, THANKS, George...
[Bug rtl-optimization/97041] New: ICE during RTL pass: sched_fusion: in operator[], at vec.h:880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97041 Bug ID: 97041 Summary: ICE during RTL pass: sched_fusion: in operator[], at vec.h:880 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vvinayag at arm dot com Target Milestone: --- Internal Compiler Error when compiling glibc/stdio-common/vfprintf-internal.c. The build configuration is: BUILD: x86_64/linux HOST: x86_64/linux TARGET: aarch64-none-linux-gnu OR BUILD: aarch64-none-linux-gnu HOST: aarch64-none-linux-gnu TARGET: aarch64-none-linux-gnu during RTL pass: sched_fusion vfprintf-internal.c: In function ‘__vfprintf_internal’: vfprintf-internal.c:1693:1: internal compiler error: in operator[], at vec.h:880 1693 | } | ^ 0x8136a9 vec::operator[](unsigned int) /src/gcc/gcc/vec.h:880 0x8136a9 pre_and_rev_post_order_compute_fn(function*, int*, int*, bool) /src/gcc/gcc/cfganal.c:1036 0x813790 pre_and_rev_post_order_compute(int*, int*, bool) /src/gcc/gcc/cfganal.c:1050 0x7c27fe init_alias_analysis() /src/gcc/gcc/alias.c:3392 0x18a7416 sched_init() /src/gcc/gcc/haifa-sched.c:7326 0x18a8b50 haifa_sched_init() /src/gcc/gcc/haifa-sched.c:7363 0xcd56bd schedule_insns() /src/gcc/gcc/sched-rgn.c:3514 0xcd5f21 rest_of_handle_sched_fusion /src/gcc/gcc/sched-rgn.c:3757 0xcd5f21 execute /src/gcc/gcc/sched-rgn.c:3932 GCC SHA d9b054d56b052fb01c9a667c95f80c783f0cf0c7 from master
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Keywords||ice-on-valid-code Summary|ICE on C++20 code: |[11 Regression] ICE on |gcc_assert failure in |C++20 code: gcc_assert |return type deduction |failure in return type |(gcc/cp/pt.c:26984 in |deduction |type_dependent_expression_p |(gcc/cp/pt.c:26984 in |(tree_node*)) |type_dependent_expression_p ||(tree_node*)) Last reconfirmed||2020-09-13 Target Milestone|--- |11.0 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r11-1713.
[Bug target/97025] In -m32 mode the alignment of pointers returned by malloc or operator new is less than alignof(std::max_align_t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97025 --- Comment #5 from Mikhail Kremniov --- I see. So this is not considered a bug then? P.S. it seems that -faligned-new=8 can be used as a workaround in this case, even in pre-c++17 modes, so the issue doesn't look that bad in the end.
[Bug fortran/97036] [F2018] ELEMENTAL RECURSIVE subprogram prefix combination rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97036 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Untested patch: diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index abd3b5ccfd0..3e2ff0954d6 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -569,7 +569,7 @@ gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where) conf_std (allocatable, dummy, GFC_STD_F2003); conf_std (allocatable, function, GFC_STD_F2003); conf_std (allocatable, result, GFC_STD_F2003); - conf (elemental, recursive); + conf_std (elemental, recursive, GFC_STD_F2018); conf (in_common, dummy); conf (in_common, allocatable);
[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983 --- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #19 from anlauf at gcc dot gnu.org --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #14) >> > --- Comment #13 from anlauf at gcc dot gnu.org --- >> > This may lead to a total mess, and I am unable to test it, but can you try: >> >> I just ran bootstraps on both sparc-sun-solaris2.11 and >> i386-pc-solaris2.11. x86 results are unchanged, but sparc is completely >> miserable: > > OK, thanks. Scrap the patch from comment#13. Let's try using long double > when TYPE_PRECISION (long_double_type_node) is big enough for the conversion: [...] > This should have no effect on x86. > > I may work on SPARC; could you please test for me? It did indeed: both sparc-sun-solaris2.11 and i386-pc-solaris2.11 bootstraps completed; the failures are gone and no regressions occured. Thanks. Btw., there's a Solaris/SPARC system in the GCC compile farm (gcc211), so you can test patches yourself if you like. It took me quite some time to do the testing myself this time because the regular weekly tests were still running on my system.
[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903 --- Comment #4 from anlauf at gcc dot gnu.org --- Patch for MVBITS: https://gcc.gnu.org/pipermail/fortran/2020-September/055071.html
[Bug fortran/97037] ICE on user-defined derived-type output of an intermediate ancestor type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97037 --- Comment #2 from Jerry DeLisle --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219
[Bug fortran/97037] ICE on user-defined derived-type output of an intermediate ancestor type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97037 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #1 from Jerry DeLisle --- This may be related to or the same as 89219
[Bug preprocessor/91412] Unexpectedly correct raw string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91412 Tom Honermann changed: What|Removed |Added CC||tom at honermann dot net --- Comment #1 from Tom Honermann --- My understanding is that the usual rationale for removal of trailing whitespace is to consider it part of a newline sequence; similar to considering as a single newline. Using that rationale, it seems appropriate that the spaces be retained as part of translation phase 2 reversion; just as it would presumably be desirable to preserve a sequence through such reversion.
[Bug target/97040] New: incorrect fused multiply add/subtract instruction generated from C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97040
Bug ID: 97040
Summary: incorrect fused multiply add/subtract instruction
generated from C code
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ddiculoiu at dspace dot de
Target Milestone: ---
Target: v850-elf
Consider the following simple code:
__attribute__ ((noinline)) float func_a(float x, float y, float z)
{
return (x-y*z);
}
__attribute__ ((noinline)) float func_b(float x, float y, float z)
{
return (-x-y*z);
}
volatile float x = 5.0,y = 2.0,z = 1.0;
int main()
{
volatile float c = func_a(x,y,z);
volatile float d = func_b(x,y,z);
return 0;
}
compiled with:
v850-elf-gcc test.c -mrh850-abi -mv850e3v5 -nostdlib --entry=0 -O2
The gcc generates the following assembly code for the 'func_a' and 'func_b':
0010 <_func_a>:
10: 06 50 mov r6, r10
12: e7 47 e4 54 fnmaf.s r7, r8, r10
16: 7f 00 jmp [lp]
0018 <_func_b>:
18: 06 50 mov r6, r10
1a: e7 47 e6 54 fnmsf.s r7, r8, r10
1e: 7f 00 jmp [lp]
In my opinion the 2 instructions 'fnmaf.s' and 'fnmsf.s' are exchanged in the 2
functions. The funtion 'func_a' must contain the 'fnmsf.s' and the 'func_b' the
'fnmaf.s' instruction.
Can someone confirm my observations?
Thanks.
P.S. I did a test with older (gcc 4.9.0) and latest (gcc 10.2.0) gcc.
Both have the same problem. I think the bug is from the first release where the
fused multiply and add/subtraction were added and nobody detected it yet.
When I compile the same code with Green Hills Compiler I got the correct
assembly instruction for 'func_a' and the 'func_b' uses negated value for x and
the 'fnmsf.s' instruction instead of the 'fnmaf.s' one, but the result is
correct:
1000 <_func_a>:
1000: 06 50 mov r6, r10
1002: e7 47 e6 54 fnmsf.s r7, r8, r10
1006: 7f 00 jmp [lp]
1010 <_func_b>:
1010: e1 37 48 54 negf.s r6, r10
1014: e7 47 e6 54 fnmsf.s r7, r8, r10
1018: 7f 00 jmp [lp]
[Bug fortran/97039] -fbounds-check misses violation with slice of array but not an element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97039 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Anthony M de Beus from comment #0) > > the correct result from the PGI/NVIDIA (v 20.7) compiler follows > As the Fortran code is invalid, there are no correct results.
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #3 from Steve Kargl --- On Sun, Sep 13, 2020 at 08:02:01AM +, jean-pierre.flam...@univ-lille.fr wrote: > > I just noticed that cpp recognizes the extensions .fpp .F and other uppercase > extensions. > This is why I added -cpp in the gfortran command (otherwise I have a > diagnostic > because of #ifdef's > > I have renamed my file with the .fpp extension; with "-cpp" in the gfortran > submission I get the same errors. > > If I compile the file with extension *.f or .fpp without -cpp > > 1) the compilation has no error > 2) a #ifdef...#endif is recognized even with a .f extension, without -cpp, in > my simple example, (I should check that the directive really is taken into > account !) > 3) IF I compile my full project in a makefile, the absence of "-cpp" in the > gfortran command induces > a "Illegal preprocessor directive" error in all the routines having that > #ifdef...#endif > I don't quite follow you. But, it come down to gfortran uses the C pre-processor when asked to pre-process a file. If you have a C language construct such as '/*' in your Fortran code it will cause problems.
[Bug fortran/97039] New: -fbounds-check misses violation with slice of array but not an element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97039 Bug ID: 97039 Summary: -fbounds-check misses violation with slice of array but not an element Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anthony.debeus at gmail dot com Target Milestone: --- Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.0 (GCC) gfortran -Wall -Wextra -fbounds-check -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined arrays.f90 test.f90 or just gfortran -fbounds-check arrays.f90 test.f90 test.f90 PROGRAM test USE arrays call init_mat(MM,N,RM) write(*,*) RM%r(257,:) ! this prints out the out-of-bounds slice INCORRECTLY write(*,*) RM%r(257,1) ! this is caught correctly (line 7 below) write(*,*) size(RM%r) END arrays.f90 MODULE arrays INTEGER, PARAMETER :: MM=180, N=22 TYPE RMatrix REAL, ALLOCATABLE :: r(:,:) END TYPE RMatrix TYPE(RMatrix) :: RM CONTAINS subroutine init_mat(MM,N,RM) ! allocate arrays INTEGER, INTENT(IN) :: MM,N TYPE(RMatrix) :: RM allocate (RM%r(MM,N)) end subroutine init_mat end module produces ./a.out 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. At line 7 of file test.f90 Fortran runtime error: Index '257' of dimension 1 of array 'rm%r' above upper bound of 180 Error termination. Backtrace: #0 0x55edbad311c8 in ??? #1 0x55edbad31394 in ??? #2 0x7fc2b3ff7151 in ??? #3 0x55edbad2f16d in ??? #4 0x in ??? the correct result from the PGI/NVIDIA (v 20.7) compiler follows pgf90 -C arrays.f90 test.f90 ./a.out 0: Subscript out of range for array rm%r (test.f90: 6) subscript=257, lower bound=1, upper bound=180, dimension=1
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 paul.luck...@rwth-aachen.de changed: What|Removed |Added CC||paul.luck...@rwth-aachen.de --- Comment #7 from paul.luck...@rwth-aachen.de --- Still arises in gfortran V10.1
[Bug c++/97038] New: [[no_unique_address]] support anonymous unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97038
Bug ID: 97038
Summary: [[no_unique_address]] support anonymous unions
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: no_unique_address at mail dot de
Target Milestone: ---
Compiling the following source file with g++ -std=c++20 -Wall -pedantic
--
struct A {};
struct B {};
struct C
{
[[no_unique_address]] union
{
[[no_unique_address]] A a;
[[no_unique_address]] B b;
} /*u*/;
char c;
};
static_assert(sizeof(C) == sizeof(char));
--
leads to the following output:
:6:5: warning: attribute ignored in declaration of 'union C::'
[-Wattributes]
6 | {
| ^
:6:5: note: attribute for 'union C::' must follow the 'union'
keyword
:13:25: error: static assertion failed
13 | static_assert(sizeof(C) == sizeof(char));
| ~~^~~
Compiler returned: 1
See also: https://godbolt.org/z/GcW9cr
This works fine if the union is not anonymous.
This also works on clang 10.
It would be nice if it could be supported on gcc.
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 --- Comment #2 from jean-pierre.flam...@univ-lille.fr --- Thanks, However, if I launch "man cpp" or "man gfortran" I can't see anything in relation with my problem and traditional. I just noticed that cpp recognizes the extensions .fpp .F and other uppercase extensions. This is why I added -cpp in the gfortran command (otherwise I have a diagnostic because of #ifdef's I have renamed my file with the .fpp extension; with "-cpp" in the gfortran submission I get the same errors. If I compile the file with extension *.f or .fpp without -cpp 1) the compilation has no error 2) a #ifdef...#endif is recognized even with a .f extension, without -cpp, in my simple example, (I should check that the directive really is taken into account !) 3) IF I compile my full project in a makefile, the absence of "-cpp" in the gfortran command induces a "Illegal preprocessor directive" error in all the routines having that #ifdef...#endif - Mail original - De: "kargl at gcc dot gnu.org" À: "jean-pierre flament" Envoyé: Samedi 12 Septembre 2020 12:14:06 Objet: [Bug fortran/97031] the content of a comment line breaks compilation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to jean-pierre.flament from comment #0) > Created attachment 49211 [details] > contains fortran pgm, system and compile info and output > > I would like to signal to you a compilation problem that I have solved. > > the following comment line > > ! some text... DIR/*/) > > seems to put the compiler into trouble. (see attachment) > > changing the line to > > ! some text... DIR/d2) > > solves the problem > > The attached file contains > > 1) the fortran (self contained) > The faulty line is marked ==> FAULTY LINE, > it is followed by the line ===> LINE OK > 2) the system name (centos 6.10) and kernel > 3) the command to compile > 4) the output > > all these parts are sepaated by == lines > > I have also tested gfortran 6.3 (from devtoolset of centos) on the same > computer (As far as I remember the errors are different but the compilation > fails), and gfortran 4.9.3 also on a centos machine: same as 4.4.7). > Sorry I have not access to newer versions of gfortran This should be closed as INVALID. You are preprocessing your code with cpp in traditional mode, and therefore the '/*' in your code is the start of a C comment. This is an user error. Not a problem with gfortran.
