> This is a followup mail to http://gcc.gnu.org/ml/gcc/2012-05/msg00400.html > now that I understand my problem better and can change the subject line to > reflect that.
I'm not sure whether digging into the behavior of the driver is the best way to solve this kind of testsuite problems. I think you should consider adding a new dg-require-effective-target marker instead. > When I configure GCC with '--with-synci' the configure script puts > 'synci' into the configure_default_options array and then the GCC > driver uses this array to add the '-msynci' flag to the cc1 call. > So now when cc1 checks target_flags_explicit for the MASK_SYNCI bit > it finds that it is set because the driver added it, even though it is > not on the users gcc command line and I cannot tell if the user had > -msynci on his or her GCC command line or if the driver added it > automatically. > > Does anyone have any ideas on telling the two cases apart? I think that there is no simple solution. We needed something like that a while ago to implement the -s switch of the gnatmake command of the GNAT compiler and we ended up with a scheme where gnatmake prepends and appends special switches to the command line it is passed, sends the result to the driver which also prepends and appends its own stuff before calling the real compiler (gnat1 here), and we have parameterized the specs (lang-specs.h) so that the driver doesn't modify the order of the special switches wrt the -m switches. As a result, gnat1 knows that any -m switch before the prepended special switch or after the appended special switch comes from the driver. -- Eric Botcazou
