Bug 42954 - [4.8/4.9/5/6 regression] TARGET_*_CPP_BUILTINS issues with gfortran
Summary: [4.8/4.9/5/6 regression] TARGET_*_CPP_BUILTINS issues with gfortran
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P5 normal
Target Milestone: 4.8.5
Assignee: Not yet assigned to anyone
URL:
Keywords: patch
: 36380 42042 47175 47965 55007 (view as bug list)
Depends on:
Blocks: 42950
  Show dependency treegraph
 
Reported: 2010-02-04 12:30 UTC by Tobias Burnus
Modified: 2014-12-19 13:35 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-09-26 13:19:37


Attachments
Patch for fixing at least target part for preprocessor (721 bytes, patch)
2010-08-03 10:09 UTC, Kai Tietz
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2010-02-04 12:30:50 UTC
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.
Comment 1 Daniel Franke 2010-02-04 13:03:07 UTC
*** Bug 36380 has been marked as a duplicate of this bug. ***
Comment 2 Tobias Burnus 2010-02-04 14:06:46 UTC
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?
Comment 3 Tobias Burnus 2010-02-10 23:40:33 UTC
(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 ()
Comment 4 Tobias Burnus 2010-03-17 09:31:56 UTC
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.)
Comment 5 Kai Tietz 2010-08-03 10:09:11 UTC
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.
Comment 6 Francois-Xavier Coudert 2010-09-26 13:19:37 UTC
(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.
Comment 7 Francois-Xavier Coudert 2010-09-26 13:44:10 UTC
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.
Comment 8 nightstrike 2010-09-30 18:47:04 UTC
This bug is listed as NEW, not ASSIGNED, but it's set to be assigned to FX.  Can the status be updated to ASSIGNED?
Comment 9 Francois-Xavier Coudert 2010-10-03 12:01:50 UTC
*** Bug 42042 has been marked as a duplicate of this bug. ***
Comment 10 Francois-Xavier Coudert 2010-10-07 10:50:48 UTC
Complete patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00566.html
Comment 11 Tobias Burnus 2010-11-07 17:07:00 UTC
Last patch:
  http://gcc.gnu.org/ml/fortran/2010-11/msg00052.html
Comment 12 Tobias Burnus 2010-11-08 09:30:11 UTC
(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.
Comment 13 Andrew Pinski 2011-01-05 16:49:54 UTC
*** Bug 47175 has been marked as a duplicate of this bug. ***
Comment 14 Janne Blomqvist 2011-03-18 15:45:59 UTC
*** Bug 47965 has been marked as a duplicate of this bug. ***
Comment 15 Jakub Jelinek 2011-03-25 19:52:23 UTC
GCC 4.6.0 is being released, adjusting target milestone.
Comment 16 Jakub Jelinek 2011-06-27 12:32:46 UTC
GCC 4.6.1 is being released.
Comment 17 Jakub Jelinek 2011-10-26 17:13:33 UTC
GCC 4.6.2 is being released.
Comment 18 nightstrike 2011-10-27 02:00:37 UTC
We have a patch.  What else is missing?
Comment 19 Tobias Burnus 2011-10-27 09:32:22 UTC
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.
Comment 20 nightstrike 2012-06-22 02:05:45 UTC
As we're in 4.8 now, consider this a friendly ping :)
Comment 21 janus 2012-10-21 20:46:07 UTC
*** Bug 55007 has been marked as a duplicate of this bug. ***
Comment 22 Jakub Jelinek 2013-03-22 14:43:14 UTC
GCC 4.8.0 is being released, adjusting target milestone.
Comment 23 Jakub Jelinek 2013-05-31 10:58:05 UTC
GCC 4.8.1 has been released.
Comment 24 Jakub Jelinek 2013-10-16 09:50:10 UTC
GCC 4.8.2 has been released.
Comment 25 Richard Biener 2014-05-22 09:02:24 UTC
GCC 4.8.3 is being released, adjusting target milestone.
Comment 26 Jakub Jelinek 2014-12-19 13:35:23 UTC
GCC 4.8.4 has been released.