/* 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).
- other platforms (not as popular) break similarly
[grep for 'builtin_define_with_int_value' in gcc/config/]
TARGET_OBJFMT_CPP_BUILTINS (); */
Grepping for builtin_define_with_int_value shows:
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:
arm/vxworks.h: arm_arch_xscale, arm_arch5, arm_arch4, thumb_code
i386/i386-interix.h: preprocessing_asm_p, c_dialect_cxx, c_dialect_objc
ia64/hpux.h: c_dialect_cxx, flag_iso
mips/iris6.h: flag_isoc99, c_dialect_cxx, flag_iso
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
(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
(In reply to comment #11)
> Last patch:
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
*** 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.