gcc/fortran/cpp.c contains: /* FIXME: Pandora's Box Using the macros below results in multiple breakages: - mingw will fail to compile this file as dependent macros assume to be used in c-cppbuiltin.c only. Further, they use flags only valid/defined in C (same as noted above). [config/i386/mingw32.h, config/i386/cygming.h] - other platforms (not as popular) break similarly [grep for 'builtin_define_with_int_value' in gcc/config/] TARGET_CPU_CPP_BUILTINS (); TARGET_OS_CPP_BUILTINS (); TARGET_OBJFMT_CPP_BUILTINS (); */ Grepping for builtin_define_with_int_value shows: gcc/config/frv/frv.h gcc/config/i386/mingw32.h gcc/config/mips/mips.h gcc/config/freebsd-spec.h Expected: The macros which make only sense for C are only used for C, e.g. many of the __attribute__(()) ones.
*** Bug 36380 has been marked as a duplicate of this bug. ***
Daniel: Wouldn't it be enough to duplicate c-cppbuiltin.c's builtin_define_with_value and builtin_define_with_int_value for fortran/cpp.c? Regarding builtin_define_std: Couldn't one simply define __<TXT> and __<TXT>__ (after stripping leading _) ignoring the unmodified version?
(In reply to comment #2) > Daniel: Wouldn't it be enough to duplicate c-cppbuiltin.c's > builtin_define_with_value and builtin_define_with_int_value for fortran/cpp.c? > Regarding builtin_define_std: Couldn't one simply define __<TXT> and __<TXT>__ > (after stripping leading _) ignoring the unmodified version? I tried this but it fails on x86-64-linux with: cpp.c:(.text+0x1d6b): undefined reference to `ix86_target_macros' which is the file gcc/config/i386/i386-c.c for #define TARGET_CPU_CPP_BUILTINS() ix86_target_macros ()
Cross reference: The missing define of "_WIN32" causes failures on MinGW/MinGW64 for gfortran.dg/dev_null.F90 and gfortran.dg/write_to_null.F90. (cf. PR 42950 which is otherwise fixed.)
Created attachment 21373 [details] Patch for fixing at least target part for preprocessor This patch re-enables at least target defines for fortran's preprocessor. The architecture part isn't enabled, as for example i386's architecture preprocessor settings are at the moment just working for C/C++ frontends.
(In reply to comment #5) > Patch for fixing at least target part for preprocessor Doesn't work, for example as config/alpha/linux.h uses c_dialect_cxx() in the macro, which is not accessible from the Fortran front-end (being a C-family function). I'm conducting of full audit of these macros in config/, and will report back here when it's done.
After some auditing: TARGET_OBJFMT_CPP_BUILTINS is safe (it's only called in config/elfos.h and config/alpha/elf.h, and contains a single, unconditionnal call to builtin_define()). Regarding TARGET_OS_CPP_BUILTINS, definitions in the following files may not be safe for the Fortran front-end: alpha/linux.h: c_dialect_cxx alpha/osf5.h: c_dialect_cxx arm/vxworks.h: arm_arch_xscale, arm_arch5, arm_arch4, thumb_code cris/linux.h: flag_leading_underscore i386/cygming.h: flag_iso i386/darwin.h: darwin_cpp_builtins i386/i386-interix.h: preprocessing_asm_p, c_dialect_cxx, c_dialect_objc i386/netware.h: flag_iso ia64/hpux.h: c_dialect_cxx, flag_iso mips/iris6.h: flag_isoc99, c_dialect_cxx, flag_iso mips/linux.h: c_dialect_cxx mips/netbsd.h: mips_abi pa/pa-hpux.h: c_dialect_cxx, flag_iso, preprocessing_trad_p pa/pa-hpux10.h: c_dialect_cxx, flag_iso, preprocessing_trad_p, flag_pa_unix pa/pa-hpux11.h: c_dialect_cxx, flag_iso, preprocessing_trad_p, flag_pa_unix, flag_isoc94, flag_isoc99, pa/pa.h: c_dialect_cxx, flag_iso rs6000/darwin.h: darwin_cpp_builtins rs6000/sysv4.h: target_flags_explicit sol2.h: c_dialect_cxx (each time, I give the list of variables/functions which may not be accessible from the Fortran front-end). One thing we could do is wrap all that with some IS_INSIDE_C_FAMILY_FRONTEND macro, so that it's just protected in Fortran and potentially other languages. Or we double the work and split TARGET_OS_CPP_BUILTINS into TARGET_OS_CPP_CFAMILY_BUILTINS and TARGET_OS_CPP_OTHERLANG_BUILTINS (you get the idea). I still have to audit TARGET_CPU_CPP_BUILTINS, but I'm running out of time for today.
This bug is listed as NEW, not ASSIGNED, but it's set to be assigned to FX. Can the status be updated to ASSIGNED?
*** Bug 42042 has been marked as a duplicate of this bug. ***
Complete patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00566.html
Last patch: http://gcc.gnu.org/ml/fortran/2010-11/msg00052.html
(In reply to comment #11) > Last patch: > http://gcc.gnu.org/ml/fortran/2010-11/msg00052.html Review comments by Ian Taylor were: * More macros now refer to magic variables which must be in scope when the macro is used, namely pfile and iso. * Code in the generic backend is now calling cpp_define, which is in libcpp. This was not the case before. It does not seem appropriate for languages like Java and Ada which do not use the C preprocessor at all.
*** Bug 47175 has been marked as a duplicate of this bug. ***
*** Bug 47965 has been marked as a duplicate of this bug. ***
GCC 4.6.0 is being released, adjusting target milestone.
GCC 4.6.1 is being released.
GCC 4.6.2 is being released.
We have a patch. What else is missing?
Moved to 4.7. It's actually rather a 4.8 item as all 14 targets need to be patched. (In reply to comment #18) > We have a patch. What else is missing? See comment 11 for the patch (follow the link) and comment 12 for things which have to be done before it can be committed. (The one of comment 5 is more a hack than a proper patch.) The best way is probably to implement it first for the common x86-64 and, when the design is OK (i.e. the patch is approved and committed), to do likewise for each of the other targets. If that's done, the front end can finally be changed.
As we're in 4.8 now, consider this a friendly ping :)
*** Bug 55007 has been marked as a duplicate of this bug. ***
GCC 4.8.0 is being released, adjusting target milestone.
GCC 4.8.1 has been released.
GCC 4.8.2 has been released.
GCC 4.8.3 is being released, adjusting target milestone.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed
GCC 6 branch is being closed
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
A lot of users have moved to the 10.X series of compilers, and the adventurous ones to 11.X. Will the fixes also appear in those compilers?
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
*** Bug 108175 has been marked as a duplicate of this bug. ***
GCC 10 branch is being closed.