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
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? Switc
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}}"
AF
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
Paolo Bonzini :
>
> 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 n
++ mode this is not an issue, but should be fixed nevertheless I
think.
Regards,
Gunther
gcc:
2017-03-XX Gunther Nikl
* system.h (HAVE_DESIGNATED_INITIALIZERS,
HAVE_DESIGNATED_UNION_INITIALIZERS): Fix non C++ case.
Index: gcc/system.h
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
>
Andreas Schwab wrote:
> Gunther Nikl 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
Andreas Schwab wrote:
> Gunther Nikl 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
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 G
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 ask
Michael Meissner wrote:
> @@ -10326,7 +10352,7 @@ static rtx
> altivec_expand_ld_builtin (tree exp, rtx target, bool *expandedp)
> {
>tree fndecl = TREE_OPERAND (CALL_EXPR_FN (exp), 0);
> - unsigned int fcode = DECL_FUNCTION_CODE (fndecl);
> + enum rs6000_builtins fcode = (enum rs6000_built
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
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= and the compiler was not configured with --with-cpu=.
> Here are the patches.
Which GCC releases are aff
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
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
no
Joseph S. Myers wrote:
> On Thu, 7 Apr 2011, Gunther Nikl wrote:
>
>>> 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 ne
On Fri, Oct 08, 2010 at 09:58:14AM -0400, Nathan Froyd wrote:
> The patch below hookizes FUNCTION_ARG and related macros for the m68k
> backend. Nothing special here.
With the old macro approach it was easy for a subtarget to override
these target properties. That doesn't work anymore for target
os 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
19 matches
Mail list logo
