Re: [PATCH 2/4] The main m68k cc0 conversion
Bernd Schmidt : > On 11/23/19 9:53 PM, Bernd Schmidt wrote: > > I'll spend a few more days trying to see if I can do something > > about the bootstrap failure Mikael saw (currently trying to do a > > two-stage cross build rather than a really slow bootstrap). > > Whew, I think I have it. One tst instruction eliminated when it > shouldn't have been: > > move.w %a4,%d0 > - tst.b %d0 > - jeq .L352 > + jeq .L353 > > And the reason - that's a movqi using move.w. Can this problem also happen on older (pre-ccmode) GCC versions? Or was this only an issue of the ccmode conversion? What about the compare constraint errors? Are those also present on older GCC versions but never surfaced? Thanks, Gunther
Re: Deprecating cc0 (and consequently cc0 targets)
Richard Sandiford wrote: > FWIW it's already possible to do the transform you mention with: > > s/(cc0)/(reg:CC CC_REGNUM_RC)/g > > (define_int_iterator CC_REGNUM_RC [(CC_REGNUM "reload_completed")]) Since "reload_completed" is referenced, this is only about the CC0 conversion, right? Switching to LRA is not required for this step. Regards, Gunther
Re: [PATCH] i386: Don't pass -msse2avx to assembler for -mavx
Uros Bizjak wrote:
> On Fri, Oct 5, 2018@1:01 AM H.J. Lu wrote:
> > diff --git a/gcc/config/i386/gnu-user.h b/gcc/config/i386/gnu-user.h
> > index a922c9b93fa..baed87aa54f 100644
> > --- a/gcc/config/i386/gnu-user.h
> > +++ b/gcc/config/i386/gnu-user.h
> > @@ -67,7 +67,7 @@ along with GCC; see the file COPYING3. If not see
> >
> > #undef ASM_SPEC
> > #define ASM_SPEC \
> > - "--32 %{!mno-sse2avx:%{mavx:-msse2avx}}
> > %{msse2avx:%{!mavx:-msse2avx}}"
> > + "--32 %{msse2avx:%{!mavx:-msse2avx}}"
AFAICT, this could be written as "%{!mavx:{msse2avx}}".
Regards,
Gunther Nikl
> > #undef SUBTARGET_EXTRA_SPECS
> > #define SUBTARGET_EXTRA_SPECS \
> > diff --git a/gcc/config/i386/gnu-user64.h
> > b/gcc/config/i386/gnu-user64.h index f7a68fdecf0..09141ce3508 100644
> > --- a/gcc/config/i386/gnu-user64.h
> > +++ b/gcc/config/i386/gnu-user64.h
> > @@ -50,7 +50,7 @@ see the files COPYING3 and COPYING.RUNTIME
> > respectively. If not, see #define ASM_SPEC "%{" SPEC_32 ":--32} \
> > %{" SPEC_64 ":--64} \
> > %{" SPEC_X32 ":--x32} \
> > - %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}"
> > + %{msse2avx:%{!mavx:-msse2avx}}"
> >
> > #define GNU_USER_TARGET_LINK_SPEC \
> >"%{" SPEC_64 ":-m " GNU_USER_LINK_EMULATION64 "}
> > \ --
> > 2.17.1
Re: m68k: handle more cases of TLS symbols with offset
Andreas Schwab wrote: > -void > -m68k_final_prescan_insn (rtx_insn *insn ATTRIBUTE_UNUSED, > - rtx *operands, int n_operands) > +static void > +m68k_adjust_decorated_operand (rtx op) FWIW, the prototype for m68k_final_prescan_insn in m68k-protos.h was not removed. Gunther
Re: [PATCH] Fix r242743 change of gcc/system.h
Paolo Bonzini <bonz...@gnu.org>: > > On 19/03/2017 22:17, Gunther Nikl wrote: > > Hello Paolo! > > > > Building older GCC releases with clang tends to issue warnings. This > > can be annoying especially when they originate from a header. While > > backporting r242743 I noticed that the non-C++ cases of the changed > > macro definitions in gcc/system.h are broken. Since GCC trunk is > > build in C++ mode this is not an issue, but should be fixed > > nevertheless I think. > > > > Regards, > > Gunther > > Of course! If you have commit access, you can commit this as obvious > I think. No, I don't have commit access. Please commit the patch for me. Thanks. > What is the warning like? Sorry, I don't have the warning available :-/ I noticed that there appears to be a problem because of a patch to the FreeBSD sources back in September of the last year. Regards, Gunther > > gcc: > > 2017-03-XX Gunther Nikl <gn...@users.sourceforge.net> > > > > * system.h (HAVE_DESIGNATED_INITIALIZERS, > > HAVE_DESIGNATED_UNION_INITIALIZERS): Fix non C++ case. > > > > > > Index: gcc/system.h > > === > > --- gcc/system.h(revision 246106) > > +++ gcc/system.h(working copy) > > @@ -581,7 +581,7 @@ extern int vsnprintf (char *, size_t, const > > char * #define HAVE_DESIGNATED_INITIALIZERS 0 > > #else > > #define HAVE_DESIGNATED_INITIALIZERS \ > > - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > > + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > > #endif > > #endif > > > > @@ -590,7 +590,7 @@ extern int vsnprintf (char *, size_t, const > > char * #define HAVE_DESIGNATED_UNION_INITIALIZERS (GCC_VERSION >= > > 4007) #else > > #define HAVE_DESIGNATED_UNION_INITIALIZERS \ > > - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > > + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > > #endif > > #endif
[PATCH] Fix r242743 change of gcc/system.h
Hello Paolo! Building older GCC releases with clang tends to issue warnings. This can be annoying especially when they originate from a header. While backporting r242743 I noticed that the non-C++ cases of the changed macro definitions in gcc/system.h are broken. Since GCC trunk is build in C++ mode this is not an issue, but should be fixed nevertheless I think. Regards, Gunther gcc: 2017-03-XX Gunther Nikl <gn...@users.sourceforge.net> * system.h (HAVE_DESIGNATED_INITIALIZERS, HAVE_DESIGNATED_UNION_INITIALIZERS): Fix non C++ case. Index: gcc/system.h === --- gcc/system.h(revision 246106) +++ gcc/system.h(working copy) @@ -581,7 +581,7 @@ extern int vsnprintf (char *, size_t, const char * #define HAVE_DESIGNATED_INITIALIZERS 0 #else #define HAVE_DESIGNATED_INITIALIZERS \ - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) #endif #endif @@ -590,7 +590,7 @@ extern int vsnprintf (char *, size_t, const char * #define HAVE_DESIGNATED_UNION_INITIALIZERS (GCC_VERSION >= 4007) #else #define HAVE_DESIGNATED_UNION_INITIALIZERS \ - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) #endif #endif
Re: [PATCH] Honour DriverOnly for enum values in error messages.
Dominik Vogt schrieb:
The attached patch fixes a glicht in the error message generated
for invalid values of enum options.
IMHO, the patch is incomplete.
diff --git a/gcc/opts-common.c b/gcc/opts-common.c
index 8e51974..3bcbaf1 100644
--- a/gcc/opts-common.c
+++ b/gcc/opts-common.c
@@ -1079,6 +1079,8 @@ read_cmdline_option (struct gcc_options *opts,
p = s;
for (i = 0; e-values[i].arg != NULL; i++)
{
+if (!enum_arg_ok_for_language (e-values[i], lang_mask))
+ continue;
size_t arglen = strlen (e-values[i].arg);
memcpy (p, e-values[i].arg, arglen);
p[arglen] = ' ';
The invalid values are skipped with that change, but there is still
space allocated for them. I propose the following additional patch
if only the space for valid values should be allocated:
-- cut --
diff -up a/gcc/opts-common.c b/gcc/opts-common.c
--- a/gcc/opts-common.c
+++ b/gcc/opts-common.c
@@ -1001,7 +1001,10 @@ read_cmdline_option (struct gcc_options
len = 0;
for (i = 0; e-values[i].arg != NULL; i++)
- len += strlen (e-values[i].arg) + 1;
+ {
+ if (enum_arg_ok_for_language (e-values[i], lang_mask))
+ len += strlen (e-values[i].arg) + 1;
+ }
s = XALLOCAVEC (char, len);
p = s;
-- cut --
Regards,
Gunther
Re: [m68k] Fix option handling for -m68020-40 and -m68020-60
Andreas Schwab wrote: Gunther Nikl gn...@users.sourceforge.net writes: The patch should be installed on trunk and on the 4.7 branch. Thanks, done. The 4.7 branch required some adjustment, since it's not compiled as C++. Right. Maybe a better solution would have been then to only change m68k.c/m68k_option_override to additionally check for -m68020-[46]0 in global_options_set when setting cpu and tune entries. Thank you for taking care of the patch. Sorry that I didn't remember to adjust the copyright year. Regards, Gunther Nikl
Re: [m68k] Fix option handling for -m68020-40 and -m68020-60
Andreas Schwab wrote: Gunther Nikl gn...@users.sourceforge.net writes: While working with GCC 4.7, I noticed that the -m68020-40 and -m68020-60 options are broken. Broken in which way? These compound options are supposed to cause m68k.c/m68k_option_override to set m68k_cpu_entry and m68k_tune_entry. However that code does only trigger if cpu/tune fields in global_options_set are nonzero which only happens if -mcpu=/-mtune= are used. My patch for m68k_handle_option simply sets cpu and tune fields in the provided opts_set function argument. The bug is more visible with a compiler configured for a plain 68000 because such a compiler will generate normal 68000 code despite requesting 68020 code with -m68020-40 or -m68020-60. The bug can also be seen with a compiler defaulting to 68020 code because the expected mc680x0 macros are not present. eg. m68k-elf-gcc -m68020-40 -x c /dev/null -E -dM -o - | grep mc68 will only show __mc68020__, but __mc680[34]0__ should be defined as well, see m68k.h/TARGET_CPU_CPP_BUILTINS. The patch should be installed on trunk and on the 4.7 branch. Regards, Gunther
[m68k] Fix option handling for -m68020-40 and -m68020-60
Hello,
While working with GCC 4.7, I noticed that the -m68020-40 and -m68020-60
options are broken. This bug was introduced in May 2011 with the patch
at http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02278.html. The code
in m68k_option_override to set cpu and tune doesn't trigger when using
-m68020-40 and -m68020-60 since global_options_set is not touched by
the evaluation code for -m68020-40 and -m68020-60 in m68k_handle_option.
This patch was tested by checking the -dM output of a patched cc1 for
the present __mc680X0__ macros.
Regards,
Gunther Nikl
-- cut --
2012-10-23 Gunther Nikl gn...@users.sourceforge.net
* common/config/m68k/m68k-common.c (m68k_handle_option): Set
gcc_options fields of opts_set for -m68020-40 and -m68020-60.
-- cut --
Index: common/config/m68k/m68k-common.c
===
--- common/config/m68k/m68k-common.c(revision 192718)
+++ common/config/m68k/m68k-common.c(working copy)
@@ -33,7 +33,7 @@
static bool
m68k_handle_option (struct gcc_options *opts,
- struct gcc_options *opts_set ATTRIBUTE_UNUSED,
+ struct gcc_options *opts_set,
const struct cl_decoded_option *decoded,
location_t loc)
{
@@ -45,12 +45,16 @@
{
case OPT_m68020_40:
opts-x_m68k_tune_option = u68020_40;
+ opts_set-x_m68k_tune_option = (uarch_type) 1;
opts-x_m68k_cpu_option = m68020;
+ opts_set-x_m68k_cpu_option = (target_device) 1;
return true;
case OPT_m68020_60:
opts-x_m68k_tune_option = u68020_60;
+ opts_set-x_m68k_tune_option = (uarch_type) 1;
opts-x_m68k_cpu_option = m68020;
+ opts_set-x_m68k_cpu_option = (target_device) 1;
return true;
case OPT_mshared_library_id_:
-- cut --
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c
Michael Meissner wrote: On Thu, Oct 04, 2012 at 06:33:33PM +0200, Gunther Nikl wrote: Michael Meissner schrieb: On Tue, Oct 02, 2012 at 10:13:25AM +0200, Gunther Nikl wrote: Michael Meissner wrote: Segher Boessenkool asked me on IRC to break out the fix in the last change. This patch is just the change to set the default options if the user did not use -mcpu=xxx and the compiler was not configured with --with-cpu=xxx. Here are the patches. Which GCC releases are affected by this bug? All of them. So this bug is as old as the rs6000 port has PowerPC support? Then GCC 2.95 is also affected? I took a closer look. AFAICT, the above mentioned bug is a result of the rewritten option parsing for GCC 4.6. And that was what I wanted to know. Since this is a regression, should this be fixed in 4.6/4.7? Well as I said, it is pretty latent, and most people never have noticed it. It really depends on what the options are whether you run into the problem. Yes, I understood that but this did not address my question. Regards, Gunther
Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c
Michael Meissner wrote: Segher Boessenkool asked me on IRC to break out the fix in the last change. This patch is just the change to set the default options if the user did not use -mcpu=xxx and the compiler was not configured with --with-cpu=xxx. Here are the patches. Which GCC releases are affected by this bug? Regards, Gunther I can submit this patch first if David desires, and then resubmit the first of the infrastructure patches again, or commit both together. 2012-09-28 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/rs6000.c (rs6000_option_override_internal): If -mcpu=xxx is not specified and the compiler is not configured using --with-cpu=xxx, use the bits from the TARGET_DEFAULT to set the initial options. Index: gcc/config/rs6000/rs6000.c === --- gcc/config/rs6000/rs6000.c(revision 191831) +++ gcc/config/rs6000/rs6000.c(working copy) @@ -2461,6 +2461,11 @@ rs6000_option_override_internal (bool gl target_flags |= (processor_target_table[cpu_index].target_enable set_masks); + /* If no -mcpu=xxx, inherit any default options that were cleared via + POWERPC_MASKS. */ + if (!have_cpu) +target_flags |= (TARGET_DEFAULT ~target_flags_explicit); + if (rs6000_tune_index = 0) tune_index = rs6000_tune_index; else if (have_cpu)
Re: Convert legacy m68k options to .opt aliases
Joseph S. Myers wrote:
m68k-aout was obsoleted in 4.4 and removed in 4.5 - while some OSes
with various odd object file formats are still supported, various
newer features such as LTO may not work so well with them.
I am aware that generic m68k-aout as target was deprecated and is gone
now. Apparently that didn't affect my target. I know that eg LTO will
never be available for a.out object files.
Is with your change really no way to test/pass the original options
to assembler/linker?
You could write specs that check for the -mcpu= options and translate
them back to old-style options acceptable to your assembler and linker.
Yes, that would work and the assembler part is easier that I expected.
The following is inspired by something I noticed in the alpha port:
%{march=*:-m%*} %{mcpu=*:-m%*}
However, the link spec seems to be harder.
%{m68020-*|m68040|m68060:-fl libm020}
Do I have to replace every m680x0 option with a matching mcpu= (maybe
even together with a march=) option?
You won't be able to use the generic m68k.h ASM_CPU_SPEC, so all the
complexity of supporting old assemblers falls on your port, but it should
be possible - you just can't pass through the options without translating
them.
The port doesn't use the generic ASM_SPECs. AFAIK the port never used
the generic definitions and I kept it that way because I felt more
comfortable using custom definitions.
So problem (almost) solved thanks to the versatile SPEC machinery.
Regards,
Gunther
Re: [m68k] hookize FUNCTION_ARG co.
Joseph S. Myers wrote: On Thu, 7 Apr 2011, Gunther Nikl wrote: Is there a (recommended) way how a subtarget can override hook functions? The implementation of the hook should contain if (preferred over #if) conditions on the particular ABI in use, which could be determined by a macro in subtarget headers. Yes, that could work. Unfortunately in this particular case if () won't work because the subtarget does also override CUMULATIVE_ARGS with a version that has additional fields. This probably means that the only solution is to redefine the affected target hook definitions within an #if block and the replacement functions within a similar #if block. Regards, Gunther
Re: Convert legacy m68k options to .opt aliases
On Wed, Apr 06, 2011 at 10:04:37PM +, Joseph S. Myers wrote: Similar to http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00265.html, this patch converts legacy m68k options for non-ColdFire CPUs into aliases for the corresponding -mcpu= options. (Note that -mcpu32 is While I agree with the CF change, I am sceptical with the m68k case. an alias for -mcpu=68332 rather than -mcpu=cpu32, to match the old code in m68k_handle_option.) This significantly simplifies the multilibs code in t-mlibs, since it no longer needs to handle those old-style options (and all cases where two -mcpu= options get the same multilib are already handled by the generic logic there rather than needing to be listed specially). The requirement for binutils 2.17 or later (to support these options to the assembler) is documented. I am using m68k-amigos which is not part of the official sources. Since this target is only about m68k it was no problem to use old(er) binutils versions. Especially if a target cares only about m68k I would like to see the legacy m68k options retained. Regards, Gunther Nikl
