or addr.indx, since s390_decompose_address will never fill in
*just* an index.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
features provided in gthr-simple.h as well.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ibgfortran on spu, and presumably
> any platform that uses gthr-simple instead of gthr-posix.
The file is called gthr-single.h, not gthr-simple.h ... sorry for the typo.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
th
&& opts->x_flag_unsafe_math_optimizations
&& opts->x_flag_finite_math_only
- && !opts->x_flag_signed_zeros
&& !opts->x_flag_errno_math
+ && opts->x_flag_cx_limited_range
&& opts->x_flag_excess_precision == EXCESS_PRECISION_FAST);
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Richard Biener wrote:
> On Fri, Jan 31, 2020 at 6:01 PM Ulrich Weigand wrote:
> > The overall effect of this patch is that now all component flags of
> > -ffast-math are treated exactly equivalently:
> > * they are set (changed from their default) with -ffast-math
>
Joseph Myers wrote:
> On Fri, 7 Feb 2020, Ulrich Weigand wrote:
>
> > I thought that a *more specific* option like -fsignalling-nans was always
> > intended to override a more generic option like -ffast-math, no matter
> > whether it comes before or after it on the comman
Segher Boessenkool wrote:
> On Fri, Feb 07, 2020 at 05:47:32PM +0100, Ulrich Weigand wrote:
> > > but what happens to -fsignalling-nans -ffast-math then? Better leave
> > > those
> > > in I'd say.
> >
> > Ah, it seems I was confused about the int
Joseph Myers wrote:
> On Mon, 10 Feb 2020, Ulrich Weigand wrote:
> > I'm not sure how this can be implemented in the current option handling
> > framework. The -ffast-math handling case would have to check whether
> > or not there is any explicit use of -f(no-)finite-m
te_math_only
- && !opts->x_flag_signed_zeros
&& !opts->x_flag_errno_math
+ && !opts->x_flag_rounding_math
+ && opts->x_flag_cx_limited_range
&& opts->x_flag_excess_precision == EXCESS_PRECISION_FAST);
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Joern Rennecke wrote:
> 2013-05-02 Joern Rennecke
>
> * reload.c (find_valid_class): Allow classes that do not include
> FIRST_PSEUDO_REGISTER - 1.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
> * gcc.dg/lower-subreg-1.c: Disable on arm-*-* targets.
I just noticed that the triple is incomplete; we're supposed to use
arm*-*-* instead of just arm-*-*.
Checked in the the following fix as obvious.
Bye,
Ulrich
2012-10-01 Ulrich Weigand
* gcc.dg/lower-su
unspec
in the first place, but only plain moves, and check MEM_ALIGN in the
move insn emitter to see which variant of the instruction is required ...]
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Uros Bizjak wrote:
> On Fri, Oct 12, 2012 at 7:57 PM, Ulrich Weigand wrote:
> > I was wondering if the i386 port maintainers could have a look at this
> > pattern. Shouldn't we really have two patterns, one to *load* an unaligned
> > value and one to *store* and unali
Richard Earnshaw wrote:
> On 20/09/12 16:49, Ulrich Weigand wrote:
> > Richard Earnshaw wrote:
> >
> >> Hmm, this is going to cause bottlenecks on Cortex-A15: writing a Neon
> >> single-precision register and then reading it back as a double-precision
> >
Tejas Belagod wrote:
> > Ulrich Weigand wrote:
> >> The following patch implements this idea; it passes a basic regression
> >> test on arm-linux-gnueabi. (Obviously this would need a lot more
> >> testing on various platforms before getting into mainline .
"n"])
This seems to add just a single alternative. Is that OK if it gets
substituted into a pattern that used multiple alternatives otherwise?
> +; In the subst pattern we have to disable the alternative where op2 is
> +; already a constant. This attribute is supposed to be used in the
> +; "disabled" insn attribute to achieve this.
> +(define_subst_attr "addr_style_op_disable" "addr_style_op_subst" "0" "1")
Is this necessary given that the subst adds a REG_P (operands[2])
condition?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
"setcc_subst"
> +; This adds an explicit CC reg set to an operation while dropping the
> +; result of the operation.
> +(define_subst "cconly_subst"
These are nice! It would seem they could be applied to simplify many
of the non-shift patterns too, right?
Bye
+ "tabort\t%1(%0)"
This seems dangerous: const_int_operand may match a constant that does
not fit into the "J" constraint, which would lead to an abort in reload.
What is the semantics for the abort code anyway? It is supposed to be
automatically truncated or not?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
v")
> +(plus:SI (match_operand:SI 2 "register_operand"
> "a, I")
The second alternative can never match here, can it?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
t;shift_count_or_setmem_operand" "")
> + (subreg:SI (match_operand:TI 4 "register_operand" "")
> + 12)]
> + UNSPEC_REPLICATE_BYTE))
> + (use (match_operand:TI 1 "register_operand" ""))
> + (clobber (reg:CC CC_REGNUM))])
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
nt 1)
>
> (and (eq_attr "cpu_facility" "ieee")
So I'm wondering what the difference is between this and simply
overriding the default implementation of "enabled" per-insn?
So instead of adding
(set_attr "disabled" "0,1")])
to an insn, you might simply add instead:
(set_attr "enabled" "*,0")])
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Andreas Krebbel wrote:
> * config/s390/s390.c (s390_decompose_address): Don't accept SImode
> anymore.
Great! Very nice to finally get rid of this.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Andreas Krebbel wrote:
> On 02/01/2016 02:30 PM, Ulrich Weigand wrote:
> > This seems to add just a single alternative. Is that OK if it gets
> > substituted into a pattern that used multiple alternatives otherwise?
> Yes. This is supposed to work. The new constraint will b
and 3 "const_int_operand" "n"))
if that is possible via the subst mechanism ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Andreas Krebbel wrote:
> On 02/01/2016 02:45 PM, Ulrich Weigand wrote:
> > So I'm wondering what the difference is between this and simply
> > overriding the default implementation of "enabled" per-insn?
> >
> > So instead of adding
> > (set_at
me* full stack check is generated as for any
other routine. Now I'm wondering: is there are reason why
this check would be necessary (and there's simply a bug in
the rs6000 implementation)? Then we obviously should do the
same on s390.
On the other hand, if rs6000 works fine *without* any code
in frameless routines, why wouldn't that work for s390 too?
Emitting a nop (that is always executed) still looks weird to me.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
atch_operand 3 "consttable_operand" "X")]
And similarly here, just use const_int_operand.
Otherwise, this all looks very good to me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Changes applied. Testsuite still running, still works on my simple tests.
>
> As for common code prerequisites: #3 is no longer needed, and very likely
> so is #4 (it fixes problems that I've only seen with ESA mode, and testsuite
> runs just fine without it now).
OK, I see
x that bug. That won't help for existing objects,
but those don't use split stack either, so that shouldn't matter.
If we fix that bug before (or at the same time as) adding split-stack
support, the linker will still be able to distigunish function pointer
loads from calls (including
tg
brxh
brxhg
brxle
brxlg
crj
cgrj
clrj
clgrj
cij
cgij
clij
clgij
Note that those are *all* branch instructions, so it might
make sense to add any PC16DBL targetting a function symbol
to the list of calls, just in case. (But since basically
nobody ever uses -msmall-exec, it doesn't really matte
be producing an error, instead of silently
> emitting code with unfixed prologue.
OK, fine with me. B.t.w. Andreas has checked in the sibcall fix,
so you no longer should be seeing larl used for sibcalls.
> I've updated and resubmitted the gold patch.
Thanks!
Bye,
Ulrich
--
Dr. Ulr
t (match_operand:VM2 0 "register_operand" "=v")
> + (match_operand:VM2 1 "memory_operand" "Z"))
> + (unspec [(const_int 0)] UNSPEC_SET_VSCR)])]
> + "TARGET_ALTIVEC"
> + "lvx %0,%y1"
>[(set_attr "type" "vecload")])
now causes vec_ldl to emit the lvx instead of the lvxl instruction.
I assume this was not actually intended?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
preted as V4SFmode when used as input to xscvspdpn, which
gets a DFmode output that is again silently re-interpreted as
SFmode.
This isn't really wrong as such, just maybe a bit confusing.
Maybe instead have p8_mtvsrd use DImode as output (instead of
DFmode), which shouldn't be any harder to us
is double double)
in any pair of registers where DFmode is allowed, since the type *is* just a
pair of DFmode values. Again, really more a stage 1 matter ...
> On Thu, Feb 11, 2016 at 07:38:15PM +0100, Ulrich Weigand wrote:
> > It's not a bug, it's deliberate behavior. The reloa
Alan Modra wrote:
> On Fri, Feb 12, 2016 at 02:57:22PM +0100, Ulrich Weigand wrote:
> > Right. It's a bit unfortunate that we can't just use IFmode
> > unconditionally,
> > but it seems rs6000_scalar_mode_supported_p (IFmode) may return false, and
> > t
something wrong in how GCC implements the AIX ABI. But I'm
not really familar with AIX, so I can't help much with that.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ops" "addr_style_op_subst" "%Y2" "%Y3(%2)")
and we don't need addr_style_op_enabled any more? %Y would continue
to emit both simple constants and register operands (and full address
operands e.g. for setmem) as before.
> +(define_subst "masked_op
(plus:SI (match_operand:SI 2 "nonmemory_operand"
> "a, I")
> + (match_operand:SI 3 "const_int_operand"
> "n, I"))]
> +UNSPEC_VEC_EXTRACT))]
> + "TARGET_VX"
> + "@
> + vlgv\t%0,%v1,%3(%2)
> + vste\t%v1,%0,%2"
> + [(set_attr "op_type" "VRS,VRX")])
Likewise for %3. Also, the second alternative seems odd, it matches solely a
PLUS of two CONST_INTs, which is not canonical RTL ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
e mail),
this all looks now very good to me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
0 "register_operand" "")
(unspec:V_HW [(match_operand: 1 "register_operand" "")
(match_operand:SI2
"shift_count_or_setmem_operand" "")
(match_dup 0)]
UNSPEC_VEC_SET))]
"TARGET_VX"
"")
Then the only remaining users of shift_count_or_setmem_operand are the
actual setmem patterns (so maybe the predicate can be renamed to
"setmem_operand") :-)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
size is nonzero)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
be more careful to
avoid violating aliasing, e.g. by using memcpy or union-based
type-punning to access its free list info.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Richard Biener wrote:
> On July 17, 2015 3:11:51 PM GMT+02:00, Ulrich Weigand
> wrote:
> >(Since there is no C++ operator new involved at all anymore,
> >this clearly violates even the C aliasing rules ...)
> >
> >I really think the allocate routine needs to be more
286.
So do we now consider host compilers < 4.3 (4?) unsupported for building
mainline GCC, or should we try to work around the issue (e.g. by moving
the allocator out-of-line or using some other aliasing barrier)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
On July 17, 2015 6:54:32 PM GMT+02:00, Ulrich Weigand
wrote:
> >So do we now consider host compilers < 4.3 (4?) unsupported for
> >building
> >mainline GCC, or should we try to work around the issue (e.g. by moving
> >the allocator out-of-line or using some other ali
bler as an additional
verification to detect compiler bugs where the compiler erroneously
generates an incorrect instruction for that architecture.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
changing the sequence of the three existing
rules. Why not just move MARCH_MTUNE_NATIVE_SPECS first?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
IVE_SPECS, \
"%{!m31:%{!m64:-m" S390_TARGET_BITS_STRING "}}", \
"%{!mesa:%{!mzarch:%{m31:-mesa}%{m64:-mzarch}}}", \
"%{!march=*:%{mesa:-march=g5}%{mzarch:-march=z900}}"
But there should not be any functional di
r targets.
I think this should be fine on s390. The problem with i386 is that
the driver-native.c file uses data types only defined by the i386
target files (e.g. enum processor_type). But on s390, the file does
not any target-specific types and should be fully portable.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Join specs for 31 and 64 bit.
> (S390_TARGET_BITS_STRING): Macro to simplify specs.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Jakub Jelinek wrote:
> On Thu, Jul 23, 2015 at 02:46:43PM +0200, Ulrich Weigand wrote:
> > > I bet that is gone break also cross-compilers from s390* to other targets.
> >
> > I think this should be fine on s390. The problem with i386 is that
> > the driver-nati
Dominik Vogt wrote:
> gcc/ChangeLog
>
> * config.hosto_plugin_soname): Include driver-native.c only when
> building with s390* as host and target.
(There seems to be a typo in the log entry ...)
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux c
is used or not. This is because the
@@ -986,7 +988,8 @@ ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \
# The C++ version.
ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \
- $(COVERAGE_FLAGS) $(NOEXCEPTION_FLAGS) $(WARN_CXXFLAGS) @DEFS@
+ $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \
+ $(WARN_CXXFLAGS) @DEFS@
# Likewise. Put INCLUDES at the beginning: this way, if some autoconf macro
# puts -I options in CPPFLAGS, our include files in the srcdir will always
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Richard Biener wrote:
> On Wed, Jul 29, 2015 at 3:57 PM, Ulrich Weigand wrote:
> > Hello,
> >
> > this patch is a workaround for the problem discussed here:
> > https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01597.html
> >
> > The problem is that the new poo
Francois Dumont wrote:
> * include/debug/formatter.h
> (_Error_formatter::_Parameter::_M_print_field): Delete.
> (_Error_formatter::_Parameter::_M_print_description): Likewise.
> (_Error_formatter::_M_format_word): Likewise.
> (_Error_formatter::_M_print_word): Likewise.
>
Jonathan Wakely wrote:
> On 18/09/15 13:00 +0200, Ulrich Weigand wrote:
> >/home/uweigand/dailybuild/spu-tc-2015-09-17/gcc-head/src/libstdc++-v3/src/c++11/debug.cc:
> > In function 'void {anonymous}::print_word({anonymous}::PrintContext&, const
> >char*, std::
rt));
if (start)
! maskbits += ((unsigned HOST_WIDE_INT)1 << (32 - start));
emit_move_insn (mask, GEN_INT (maskbits));
break;
case 64:
! maskbits = (~(unsigned HOST_WIDE_INT)0 << (64 - width - start));
if (start)
! maskbits +=
;; memory
+ (match_operand:AINT 2 "" "")) ;; operand
+(match_operand:SI 3 "const_int_operand" "")] ;; model
+ ""
+ {
+ if (MEM_ADDR_SPACE (operands[1]))
+ FAIL;
+
+ spu_expand_atomic_op (, operands[1], operands[2],
+ operands[0], NULL_RTX);
+ DONE;
+ })
+
+ (define_expand "atomic__fetch"
+ [(match_operand:AINT 0 "spu_reg_operand" "");; output
+(ATOMIC:AINT
+ (match_operand:AINT 1 "memory_operand" "") ;; memory
+ (match_operand:AINT 2 "" "")) ;; operand
+(match_operand:SI 3 "const_int_operand" "")] ;; model
+ ""
+ {
+ if (MEM_ADDR_SPACE (operands[1]))
+ FAIL;
+
+ spu_expand_atomic_op (, operands[1], operands[2],
+ NULL_RTX, operands[0]);
+ DONE;
+ })
+
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
the patch, I could always use --with-header to say: just assume headers
are present in the prefix, and everything worked.
This is not a critical problem since I have a work-around: remove --with-headers
and also manually create a symlink from sys-include to include in the prefix.
But it would still be nice to avoid having to do the symlink ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Hans-Peter Nilsson wrote:
> > From: Ulrich Weigand
> > Date: Tue, 6 Oct 2015 16:04:35 +0200
>
> > I'm using the build procedure: build initial GCC (--without-headers),
> > use it to build newlib, install newlib into prefix, build final GCC
> > (
;t quite understand how the whole sys-include thing was
intended to work in the first place ...
[ Note there's also CROSS_SYSTEM_HEADER_DIR, which is also sometimes
set to sys-include ... ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Hans-Peter Nilsson wrote:
>
> > From: Ulrich Weigand
> > Date: Tue, 6 Oct 2015 18:55:53 +0200
>
> > > Maybe make with_headers=yes (i.e. not a path) have the effect of
> > > setting target_header_dir to include instead of sys-include?
>
> (...and inspec
headers Use headers from prefix include directory
Use existing sys-include directory
--without-headers Do not use any headers
I agree that this is the smallest change to current behavior;
on the other hand, it seems quite odd overall (i.e. hardest to
explain to someone unfamiliar with current behavior). At the
very least, the docs would have to be adapted.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
headers" != x && test "x$with_headers" != xyes; then
target_header_dir=$with_headers
elif test "x$with_sysroot" = x; then
target_header_dir="${test_exec_prefix}/${target_noncanonical}/sys-include"
I'll probably not spend any more time right now t
t DW_AT_segment
as a valid attribute for a DW_TAG_pointer_type or DW_TAG_reference_type DIE.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
course, to do the latter, you still need access to the segment base values,
as discussed on the GDB mailing list.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
c=
> c.dg/debug/dwarf2/pr66728.c
> new file mode 100644
> index 000..ba41e97
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr66728.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile { target { x86_64-*-* && lp64 } } } */
> +/* { dg-options "-O -gdwarf -dA" } */
> +
> +__uint128_t
> +test (void)
> +{
> + static const __uint128_t foo =3D __uint128_t) 0x22334455) << 96)
> + | 0x99aabb);
> +
> + return foo;
> +}
> +
> +/* { dg-final { scan-assembler {\.quad\t0x99aabb\t# DW_AT_const_value} } }=
> */
> +/* { dg-final { scan-assembler {\.quad\t0x22334455\t} } } */
>
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ng caused by my forwarding of the patch.
Richard's original patch is here:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01312.html
(I'll leave it to Richard to answer your other questions ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
t;)
> - (unspec [(mem:BLK (match_dup 1))
> + (unspec:P [(mem:BLK (match_dup 1))
>(mem:BLK (match_dup 3))
>(reg:SI 0)] UNSPEC_MVST))
> (clobber (reg:CC CC_REGNUM))]
Don't you have to change the expander too? Otherwise the
pattern will no
atch_operand:P 2 "shift_count_or_setmem_operand" "Y")]
UNSPEC_P_TO_BLK)
(match_operand 4 "const_int_operand" "n"))
(This explains why the pattern would never match.)
The AND should be on the filler byte instead:
(unspec:BL
see that the sh port uses this:
(define_mode_attr lowpart_be [(QI "3") (HI "2")])
[(set (reg:SI T_REG)
(eq:SI
(subreg:QIHI
(and:SI (match_operand:SI 0 "arith_reg_operand")
(match_operand:SI 1 "arith_reg_oper
ain listed with other roles.
Ah, you're right -- thanks for catching this!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
TARGET_CONSTANT_ALIGNMENT
#define TARGET_CONSTANT_ALIGNMENT spu_constant_alignment
+#undef TARGET_HAVE_SPECULATION_SAFE_VALUE
+#define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
+
struct gcc_target targetm = TARGET_INITIALIZER;
#include "gt-spu.h"
--
Dr. Ulrich Weigand
Since branch splitting is gone, this whole logic is superfluous;
the loop will never execute more than once. (It may not be
necessary any longer to split the logic into the various
chunkify_start/finish routines either ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers a
assume aligned_alloc
is not available, but then the new_opc.cc file tries to define its own
version, conflicting with the newlib prototype that is actually there.
So one way or the other this needs to be fixed ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
n
Yes, exactly ... this commit introduced the regression.
> OK, I've regressed the branches then - I'll fix that.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
if (INSN_P (insn) && INSN_CODE (insn) == CODE_FOR_blockage && next_insn)
{
if (GET_MODE (insn) == TImode)
PUT_MODE (next_insn, TImode);
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
_emit_epilogue as above,
this point is moot; you don't even need to generate a REG RTX
if it's for r14 then.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
> 2018-09-19 Ilya Leoshkevich
>
> PR target/80080
> * gcc.target/s390/risbg-ll-3.c: Expect conditional returns.
> * gcc.target/s390/zvector/vec-cmp-2.c: Likewise.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
tion. This
seems a completely unrelated change, and looks just wrong to me ...
Was this done intentionally or is this just an oversight?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
unchanged in current sources.)
Now, the comment says BASE_REGNUM should be avoided, but the actual
implementation of the macro seems to avoid *all* registers *but*
BASE_REGNUM ...
Am I misreading this, or is there indeed a logic error here?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux c
to apply to the example above; that is really
about the second problem: don't substitute into a clobber.
I understand the reason why this particular substitution is rejected is
simply that if it weren't, we'd be substituting flags:CC=cmp(r84:SI,0x1)
into clobber flags:CC, resulting in clobber cmp(r84:SI,0x1), which is
invalid RTL.
Now I guess this check could be relaxed if somewhere else in combine we'd
recognize the substitution into a clobber and simply omit it in that case.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
er_regs)
> + && (ira_hard_reg_set_intersection_p (regno, mode,
> call_used_reg_set)
> - || HARD_REGNO_CALL_PART_CLOBBERED (regno, mode))
If a register is in crossed_calls_clobber_regs, can it ever *
ALLEL arguments.
Tested on powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* calls.c (store_unaligned_arguments_into_pseudos): Skip PARALLEL
arguments.
Index:
2013-11-11 Ulrich Weigand
Alan Modra
ChangeLog:
* function.c (assign_parms): Use all.reg_parm_stack_space instead
of re-evaluating REG_PARM_STACK_SPACE target macro.
(locate_and_pad_parm): New parameter REG_PARM_STACK_SPACE. Use it
instead of
field
is different in little-endian.
Tested on powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
libgcc/ChangeLog:
2013-11-11 Ulrich Weigand
Alan Modra
* config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Correct
location of CR save area
powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/rs6000.c (rs6000_emit_prologue): Do not place a
RTX_FRAME_RELATED_P marker on the UNSPEC_MOVESI_FROM_CR insn.
Instead, add USEs of all modified call
ye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/rs6000.c (rs6000_call_indirect_aix): Rename to ...
(rs6000_call_aix): ... this. Handle both direct and indirect calls.
Create call insn directly instead of via various gen_... routines.
Mention special regi
them for both floating-point and vector
arguments. For the current ABI, the result should be exactly
the same.
No change in generated code intented.
Tested on powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000
.
OK for mainline?
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/rs6000.c (rs6000_option_override_internal): Replace
"DEFAULT_ABI != ABI_AIX" test by testing for ABI_V4 or ABI_DARWIN.
(rs6000_savres_strategy): Likewise.
(rs6000_r
generated code intented.
Tested on powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/rs6000.c (USE_FP_FOR_ARG_P): Remove TYPE argument.
(USE_ALTIVEC_FOR_ARG_P): Likewise
logic by making
explicit the fact that rs6000_arg_partial_bytes does not actually need to
handle the cases described above.
No change in generated code expected.
Tested on powerpc64-linux and powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
uw_install_context to install values for multiple fields.
(Note that there is already precedent for unwinder routines being
treated specially in the rs6000.c prologue/epilogue code ...)
Bye,
Ulrich
gcc/ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/rs6000.c (struct rs6000_stack
eds to go into the Go repository first ...)
Bye,
Ulrich
gcc/ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/rs6000.c (machine_function): New member
r2_setup_needed.
(rs6000_emit_prologue): Set r2_setup_needed if necessary.
(rs6000_output_mi_thunk): Set
ch
gcc/ChangeLog:
2013-11-11 Ulrich Weigand
* config.gcc [powerpc*-*-* | rs6000-*-*]: Support --with-abi=elfv1
and --with-abi=elfv2.
* config/rs6000/option-defaults.h (OPTION_DEFAULT_SPECS): Add "abi".
* config/rs6000/rs6000.opt (mabi=elfv1): New option.
an now get called for BLKmode arguments,
and has to handle them using a PARALLEL.
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
Michael Gschwind
* config/rs6000/rs6000.h (AGGR_ARG_NUM_REG): Define.
* config/rs6000/rs6000.c (rs6000_aggregate_candidate): Ne
ded in a number of
places ...
The patch also updates a number of test cases that hardcoded the
stack layout.
Bye,
Ulrich
gcc/ChangeLog:
2013-11-11 Ulrich Weigand
Alan Modra
* config/rs6000/rs6000.h (RS6000_SAVE_AREA): Handle ABI_ELFv2.
value is returned formatted exactly as if
it were being passed as first argument. In order to get this correct
in the big-endian ELFv2 case, we need to provide a non-default
implementation of TARGET_RETURN_IN_MSB.
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
Michael Gschwind
ich
ChangeLog:
2013-11-11 Ulrich Weigand
Alan Modra
* config/rs6000/rs6000-protos.h (rs6000_reg_parm_stack_space):
Add prototype.
* config/rs6000/rs6000.h (RS6000_REG_SAVE): Remove.
(REG_PARM_STACK_SPACE): Call rs6000_reg_parm_stack_space.
Hello,
this patch finally throws the switch and enables the ELFv2 ABI
by default on powerpc64le-linux.
Bye,
Ulrich
ChangeLog:
2013-11-11 Ulrich Weigand
* config/rs6000/sysv4le.h (LINUX64_DEFAULT_ABI_ELFv2): Define.
Index: gcc/gcc/config/rs6000/sysv4le.h
1 - 100 of 480 matches
Mail list logo
