Jeff Law wrote:
> On 11/11/13 07:32, Ulrich Weigand wrote:
> > However, looking more closely, it seems
> > store_unaligned_arguments_into_pseudos
> > is not really useful for PARALLEL arguments in the first place. What this
> > routine does is load arguments into args[
Joseph Myers wrote:
> On Mon, 11 Nov 2013, Ulrich Weigand wrote:
> > The ELFv2 ABI is the intended ABI for the new powerpc64le-linux port.
> > However, it is not inherently tied to the byte order; it it possible
> > in principle to use the ELFv2 ABI in big-endian mode too.
&g
Jakub Jelinek wrote:
> On Mon, Nov 11, 2013 at 03:40:48PM +0100, Ulrich Weigand wrote:
> > @@ -355,7 +364,11 @@ extern int dot_symbols;
> > #define LINK_OS_DEFAULT_SPEC "%(link_os_linux)"
> >
> > #define GLIBC_DYNAMIC_LINKER32 "/lib/ld.so.1"
>
.5.
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59119
for a reduced test case ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
/home/uweigand/src/gcc/gcc/df-scan.c:265
0x1037480f df_scan_alloc(bitmap_head_def*)
/home/uweigand/src/gcc/gcc/df-scan.c:324
0x106189c7 do_reload
/home/uweigand/src/gcc/gcc/ira.c:5470
0x106189c7 rest_of_handle_reload
/home/uweigand/src/gcc/gcc/ira.c:5536
0x106189c7 execute
y 0x1033713B: compile() (cgraphunit.c:2195)
==15063==
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Vladimir Makarov wrote:
> On 11/13/2013, 8:34 PM, Ulrich Weigand wrote:
> >> Unfortunately, this patch causes cc1 for powerpc64-linux to crash for me
> >> even when compiling "int main () { return 0; }" with -O due to a memory
> >> corruption somewhere:
&
): Similarly.
> (insert_trap_and_remove_trailing_statements): Remove statements
> in reverse order.
This does indeed fix the Python build problem for me.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Jeff Law wrote:
> On 11/11/13 07:32, Ulrich Weigand wrote:
> > 2013-11-11 Ulrich Weigand
> >
> > * calls.c (store_unaligned_arguments_into_pseudos): Skip PARALLEL
> > arguments.
> OK, so after a lot of worrying, I think this is OK. I kept thinking
>
n the same test fail with the 4.6.0
baseline compiler installed on the system. My assumption
would be that this is simply a pre-existing bug (either
the alignment is computed incorrectly, or it is not being
respected properly throughout the toolchain), and you were
seeing successful runs in the
Joseph Myers wrote:
> On Tue, 12 Nov 2013, Ulrich Weigand wrote:
> > > > Therefore, it is introduces via a new pair of options
> > > >-mabi=elfv1 / -mabi=elfv2
> > > > where -mabi=elfv1 select the current Linux ABI, and -mabi=elfv2
> > > >
David Edelsohn wrote:
> On Thu, Nov 14, 2013 at 5:07 PM, Ulrich Weigand wrote:
>
> > Here's a patch to add documentation along the lines of what we have
> > for the longdouble switches.
> >
> > Doc build tested on powerpc64-linux.
> >
> > David,
ave a test case, I think it would be good to add it
to the GCC test suite ...
Otherwise, this looks reasonable to me (but I cannot approve the patch):
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
);
emit_insn (gen_movsd_hardfloat (operands[0], mem));
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
turn;
+}
+
if (REG_P (src) && REG_P (dst) && (REGNO (src) < REGNO (dst)))
{
/* Move register range backwards, if we might have destructive
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
r57363.c: New test.
> +/* Check if adding a sNAN and a normal long double does not generate a
> + inexact exception. */
qNaN again :-)
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
IG_ENDIAN
&& VECTOR_MEM_VSX_P (mode)
&& mode != TImode
+ && !gpr_or_gpr_p (operands[0], operands[1])
&& (memory_operand (operands[0], mode)
^ memory_operand (operands[1], mode)))
{
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
if (sp->slot[4].l != MAKE_SLOT (1, 2)
+ || sp->slot[6].l != MAKE_SLOT (5, 6))
abort();
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
longlong.c (working copy)
@@ -11,7 +11,11 @@
int i[2];
} ud;
ud.ll = in;
+#ifdef __LITTLE_ENDIAN__
+ return ud.i[1];
+#else
return ud.i[0];
+#endif
}
int main()
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
David Edelsohn wrote:
> On Mon, Nov 18, 2013 at 3:07 PM, Ulrich Weigand wrote:
> > Also note that this patch does not change how TDmode values are loaded
> > into GPRs: on little-endian, this means we do get the usual LE subreg
> > order there (least significant word in low
, then
this will need to be modified similar to the x86 case. */
#define TARGET_FOLD_BUILTIN SUBTARGET_FOLD_BUILTIN
+
+/* Use standard DWARF numbering for DWARF debugging information. */
+#define RS6000_USE_DWARF_NUMBERING
+
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
rohitarulraj wrote:
> > -Original Message-
> > From: Maciej W. Rozycki [mailto:ma...@codesourcery.com]
> > To: Ulrich Weigand
> > Cc: Dharmakan Rohit-B30502; Wienskoski Edmar-RA8797; David Edelsohn; gcc-
> > patc...@gcc.gnu.org; Alan Modra; Jakub Jelinek
&g
that I wanted to
> investigate. In the end they turned out intermittent and the failures
> happen sometimes whether your change is applied or not. So I'm fine with
> your change, thanks for your work and patience.
Thanks for verifying!
David, is the patch OK to commit now?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
se FOR_EACH_SUBRTX.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ed to be passed in a VR or in GPRs.
(Noticed by running the ABI compatibility test suite.)
Fortunately, this bug never made it into any (FSF or distribtion)
GCC release, so we can simply fix it now without introducing any
incompatibilities ...
I've checked in the following patch as obvious.
Mike Stump wrote:
> On Jun 28, 2014, at 3:31 AM, Ulrich Weigand wrote:
> > Mike Stump wrote:
> >
> >>(rs6000_aggregate_candidate): Use wide-int interfaces.
> > [snip]
> >> - /* Can't handle incomplete types. */
> >> - if (!COMPLETE
Richard Henderson wrote:
> On 11/12/2014 09:41 PM, Ulrich Weigand wrote:
> > * optabs.c (prepare_operand): Gracefully fail if the mode of X
> > does not match the operand mode expected by the insn pattern.
>
> This is ok.
I've checked this in now, thanks.
4"
[(set (pc)
! (if_then_else (match_operator 0 "s390_comparison"
[(match_operand 1 "cc_reg_operand" "")
! (match_operand 2 "const_int_operand" "")])
(label_ref (match_operand 3 "" ""))
(pc)))]
! ""
! "")
;;
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
compiler).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
}
-#endif
y = XVECEXP (y, 0, 0);
#ifdef HAVE_AS_TLS
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
s set in this insn unless IN
is also OUT. */
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Don't
> predefine __vector/__bool/__pixel macros nor context sensitive
> macros for CLK_ASM.
> * config/spu/spu-c.c (spu_cpu_cpp_builtins): Similarly.
The SPU part is OK.
Thanks,
Ulrich
--
Dr. Ulrich Wei
g in type-based aliasing. But
on the other hand, I'm not completely sure whether this *is* a bug --
is the code above supposed to be valid C++, or does it in fact violate
the aliasing rules after all?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
mainline, right?
Patch is OK for mainline if it passes regression tests there.
Backports to release branches are fine with me if OK with the
release maintainers, after the change has been in mainline with
no problems reported for a bit.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ms like a mistake in the backend.
We do indeed allow the CC register as general_operand, since it has a
register class of CC_REGS. This has been in place for over 10 years now
and was a deliberate decision to allow for pseudos that carry a condition
value to be allocated to the actual CC register
Richard Henderson wrote:
> On 11/06/2014 05:10 PM, Ulrich Weigand wrote:
> >>> + /* For s390, CC REG is general_operand. But cstorecc4
> >>> only
> >>> + handles CCZ1, which can not handle others like CCU.
> >>> */
mpleted)
return NULL_RTX;
! if (GET_MODE (x) != op_mode && GET_MODE (x) != VOIDmode)
! return NULL_RTX;
! x = copy_to_mode_reg (op_mode, x);
}
return x;
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
.com/epubs/pdf/dz9ar008.pdf";>ESA/390
Principles of Operation
http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_zSeries.html";>Linux for
z Systems ABI
+ http://refspecs.linuxbase.org/ELF/zSeries/lzsabi0_s390.html";>Linux for
S/390 ABI
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ot* switch to keyword-and-
predefine mode, as far as I can tell. Rather, to switch to that mode
you'll have to disable GNU extensions, e.g. via -std=c11, and then
include to get the predefine.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
t; +extensions (e.g., by using @code{-std=c11}) and including
> +@code{}.
> +@end itemize
This looks correct to me, and I've just verified that the example
does indeed build with -std=c11 and #include and fails
to build without either of these.
Bye,
Ulrich
--
Dr. Ulrich We
les. I think this is a
> reasonable way to deal with architecutral differences without making
> inliner hard to tune in long term.
Thanks for the heads-up! This looks interesting, we'll have a look.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Oleg Endo
sparc port David S. Miller
sparc port Eric Botcazou
-spu port Trevor Smigiel
-spu port David Edelsohn
-spu port Ulrich Weigand
tilegx port
[RFA][2/3] Remove Cell Broadband Engine SPU targets: testsuite
Remove all references to spu from the testsuite directory.
Tested on s390x-ibm-linux.
OK for mainline?
(Deleted directories omitted from patch.)
Bye,
Ulrich
gcc/testsuite/ChangeLog:
* lib/compat.exp: Remove references t
__eaa * (__c2 - __pndev * __c3)
+ _Tp __s3 = __pndev * __ea * (__c2 - __pndev * __c3)
- __c2 * __pndev * __ec;
return _Tp(3) * __sigma + __power4 * (__s1 + __s2 + __s3)
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
- __int128 lock;
+ aligned_int128 lock;
__int128 rval;
lock = oval;
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Richard Biener wrote:
> On Mon, Sep 2, 2019 at 10:35 PM Ulrich Weigand wrote:
> > Now one question might be, why does get_pointer_alignment not take
> > type alignment into account by itself? This appears to be deliberate
> > to avoid considering numeric pointer values to
Richard Biener wrote:
> On Tue, Sep 3, 2019 at 1:56 PM Ulrich Weigand wrote:
> > combined with the fact that get_object_alignment_2 actually itself
> > uses type alignment if we have an actual memory object:
> > /* When EXP is an actual memory refe
Richard Biener wrote:
> On Tue, Sep 3, 2019 at 3:09 PM Ulrich Weigand wrote:
> > > If you read the C standards fine-print then yes. But people (or
> > > even the C frontend!) hardly get that correct since for example
> > > for
> > >
> >
Richard Biener wrote:
> On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand wrote:
> > But as far as I can see, for *atomic* operations at least, we do make
> > that assumption. The x86 back-end for example just assumes that any
> > "int" or "long" object tha
ontains a register reference, so it shouldn't
really be CONST. (And if it were, why make the change just here and not
everywhere a UNSPEC_LTREF is generated?)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Ilya Leoshkevich wrote:
> Am 29.10.2018 um 19:45 schrieb Ulrich Weigand :
>
> > This is true. But something else must still be going on here. Note that
> > many other instruction patterns might contain constant pool addresses,
> > since they are accepted e.g. by the &#
Ilya Leoshkevich wrote:
> Am 30.10.2018 um 16:20 schrieb Ulrich Weigand :
> > Not sure that this is fully correct either. *Some* instructions, like
> > e.g. floating-point loads, do not accept relative operands. And even
> > for the relative loads that exist, there may
re
not going to replace it! That was the whole point of not annotating
it in the first place ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Ilya Leoshkevich wrote:
> Am 30.10.2018 um 18:22 schrieb Ulrich Weigand :
> > This definitely looks wrong. If we haven't annotated the address,
> > it should *not* be found by find_constant_pool_ref, since we are
> > not going to replace it! That was the whole point o
P_IN_RANGE (INTVAL (frame_off)))
> {
> - insn = gen_rtx_SET (frame_pointer,
> - gen_rtx_PLUS (Pmode, frame_pointer, frame_off));
> - insn = emit_insn (insn);
> + insn = emit_insn (copy_rtx (cfa));
> }
This seems unrelated?
Bye,
Ulrich
--
) || CALL_P (insn))
&& !s390_safe_relative_long_p (insn))
(This last change is just a suggestion, only if it makes the
overall code simpler and more readable.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
): Likewise.
> (s390_emit_prologue): Likewise.
> (s390_emit_epilogue): Likewise.
This version is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
)
if test "x$enable_obsolete" != xyes; then
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
cc.gnu.org/ml/gcc/2018-10/msg00139.html";>
announcement.
+
+ Cell Broadband Engine SPU (spu*-*-*). Details can be
found
+ in the https://gcc.gnu.org/ml/gcc/2019-04/msg00023.html";>
+ announcement.
+
--
Dr. Ulrich Weigand
GNU/
Eric Gallagher wrote:
> On 4/2/19, Ulrich Weigand wrote:
> > Hello,
> >
> > the spu-elf target in GCC supports generating code for the SPU processors
> > of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
> >
> > However, at this poin
because they do not use a base
register. */
static void
annotate_constant_pool_refs (rtx_insn *insn)
{
if (s390_safe_relative_long_p (insn))
return;
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
testsuite/ChangeLog:
>
> 2019-02-11 Ilya Leoshkevich
>
> PR target/89233
> * gcc.target/s390/pr89233.c: New test.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
* gcc.c-torture/compile/pr72771.c: New.
Yes, this makes sense. address_reloaded == -1 means that the address
may or may not have been fully reloaded, so we always need to take the
conservative action in that case.
The patch is OK.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and
Andre Vieira (lists) wrote:
> On 07/04/16 10:30, Andre Vieira (lists) wrote:
> > On 17/03/16 16:33, Andre Vieira (lists) wrote:
> >> On 23/10/15 12:31, Bernd Schmidt wrote:
> >>> On 10/12/2015 11:58 AM, Ulrich Weigand wrote:
> &g
t;#endif
>}
>
> which means your self test is broken by design for any compiler
> that is not GCC in at least version 4.3, isn't it?
Just to confirm that I'm seeing the same failure on my SPU
daily build machine, which is running RHEL 5 with a host
compiler of GCC
David Malcolm wrote:
> On Mon, 2016-06-13 at 13:36 +0200, Ulrich Weigand wrote:
> > Gerald Pfeifer wrote:
> >
> > > The source code of need_finalization_p in ggc.h reads
> > >
> > >template
> > >static inline bool
> > >
s fix
> > most of the problems reported in PR 80080:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080
> >
> > Bootstrapped and regression tested on a zEC12 with s390 and s390x
> > biarch.
>
> New version attached.
No, it isn't :-)
Bye,
Ulrich
--
Dr. Ul
Dominik Vogt wrote:
> > v3:
> >
> > * Remove sne* patterns.
> > * Move alignment check from s390_expand_cs to s390.md.
> > * Use s_operand instead of memory_nosymref_operand.
> > * Remove memory_nosymref_operand.
> > * Allow any CC-mode in cstorecc4 for TARGET_Z196.
> > * Fix EQ with
you're just emitting RTL directly, maybe you could simply use
> the expander pattern above to do so (and not use emit_insn followed
> by DONE in this case?)
Therefore this doesn't work either.
Sorry for the confusion.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
of the CS changes now
actually *rely* on this change to cstorecc4 ... s390_expand_cs_tdsi only
calls cstorecc4 on !TARGET_Z196, where the above change is a no-op, and
in the TARGET_Z196 case it deliberates does *not* use cstorecc4.
Now, in general this improvement to cstorecc4 is of course valuable
in itself. But I think at this point it might be better to separate
this out into an independent patch (and measure its effect separately).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Dominik Vogt wrote:
> On Fri, Apr 07, 2017 at 04:34:44PM +0200, Ulrich Weigand wrote:
> > > +; Peephole to combine a load-and-test from volatile memory which combine
> > > does
> > > +; not do.
> > > +(define_peephole2
> > >
t stage1.
Andreas, do you have an opinion on this?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
symref memory operands. Remove CC mode and call s390_match_ccmode
> instead.
> ("atomic_exchange"): Allow and implement all integer modes.
>
> gcc/testsuite/ChangeLog-dv-atomic-gcc7
>
> * gcc.target/s390/md/atomic_compare_exchange-1.c: New tes
and VSX modes don't allow them) or is a pre-increment or decrement.
On the other hand, for addresses based on a virtual register,
legitimate_address_p does not depend on the mode since those
are special-cased to be always accepted (see the discussion above).
So I'm not sure that th
y_to_reg (newval);
+
mem = rs6000_pre_atomic_barrier (mem, mod_s);
label1 = NULL_RTX;
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
lrich Weigand
s390 port Andreas Krebbel
score port Chen Liqin
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
(spu_legitimate_address_p): Fix logic error and add missing fallthru
> comment.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
a to investigate
why that isn't happening in this test case. [ There is a chance that
the underlying bug will reappear in a different context, even after
the '?' change is applied. ]
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Alan Modra wrote:
> On Mon, Jul 11, 2016 at 03:26:46PM +0200, Ulrich Weigand wrote:
> > However, there still seems to be another underlying problem: reload
> > should never generate invalid instructions. (Playing with '?' to
> > fix *inefficient* instructions is
Alan Modra wrote:
> On Tue, Jul 12, 2016 at 02:02:43PM +0200, Ulrich Weigand wrote:
> > The second time around, get_secondary_mem should reuse the
> > same stack slot it already allocated, and the elimination
> > offsets should already be set to accommodate that stack slot
27;re accepting the correct values and generate correct assembler ...
> gcc/ChangeLog
>
> * config/s390/s390-builtins.def: S390: Fix value range of
> vec_load_bndry.
The "S390: " seems out of place here.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Li
Dominik Vogt wrote:
> gcc/ChangeLog
>
> * config/s390/s390-builtins.def: Fix value range of vec_load_bndry.
>
> gcc/testsuite/ChangeLog
>
> * gcc.target/s390/zvector/vec-load_bndry-1.c: New test.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GN
ktrace be optional in some form?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
s, confusing the test.
+ have_mmap=no ;;
+esac
else
AC_CHECK_FUNC(mmap, [have_mmap=yes], [have_mmap=no])
fi
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Jeff Law wrote:
> On 08/24/2015 06:55 AM, Ulrich Weigand wrote:
> > I guess we can always just hard-code that SPU does not have mmap, similar
> > to how Solaris is hard-coded to not have dl_iterate_phdr.
> >
> > Would something like the below be OK (if it passes testing)
e that makes this determination, and sets the
shell variable "can_build_shared" to "no" on SPU. Would it be
valid to use this variable in the test whether to use -fPIC?
(I'm not sure which of the many libtool variables are intended
to be used outside, and which are pr
Hans-Peter Nilsson wrote:
> > From: Ulrich Weigand
> > Date: Tue, 25 Aug 2015 14:59:05 +0200
>
> > The other GCC run-time libraries rely on libtool to figure out
> > that even though -fPIC works, dynamic libraries are still not
> > supported on the platform
Hans-Peter Nilsson wrote:
> > From: Ulrich Weigand
> > Date: Tue, 25 Aug 2015 19:45:06 +0200
>
> > However, neither works for the SPU, because in both cases libtool
> > will only do the test whether the target supports the -fPIC option.
> > It will not test wh
uild host code as shared libraries])],
-[PIC_FLAG=-fPIC], [])
+[PIC_FLAG=-fPIC], [PIC_FLAG=])
AC_SUBST(PIC_FLAG)
# Test for __sync support.
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Ian Lance Taylor wrote:
> "Ulrich Weigand" writes:
>
> > I've verified that this works on x86_64: the resulting
> > libgfortran.so uses the -fPIC version of the libbacktrace
> > object, while libgfortran.a uses the non-PIC versions.
> >
> > O
esac
else
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
n, coff_syminfo);
else
! (void) __sync_bool_compare_and_swap (&state->syminfo_fn,
!NULL, coff_nosyms);
}
if (!state->threaded)
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Ian Lance Taylor wrote:
> On Fri, Aug 28, 2015 at 9:54 AM, Ulrich Weigand wrote:
> >
> > this is the (hopefully) last compatibility problem with libbacktrace on SPU:
> > we do not have either the __sync or the __atomic routines (since the SPU
> > is a fundamentally sing
reg.
>
> I'm okay with this patch, but I'd like Uli to double-check it when he
> has a moment.
The patch looks OK to me. We definitely need to check for replacements
in secondary reload in such cases.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
s not DImode LABEL_REFs, but rather VOIDmode LABEL_REFs when
matched against a match_operand:DI.
Otherwise, this patch is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
nally) as temp register in s390_emit_prologue in certain cases;
the upcoming split-stack code will also need to use r1 in some cases.
r2 through r4 should be fine. [ Not sure if there will be many (any?) cases
where one of those is unused but r5 isn't, however. ]
Bye,
Ulrich
--
Dr. Ulrich
Richard Sandiford wrote:
> "Ulrich Weigand" writes:
> > The problem is not DImode LABEL_REFs, but rather VOIDmode LABEL_REFs when
> > matched against a match_operand:DI.
>
> It'd be good to fix this in a more direct way though, rather than
> hack around
Dominik Vogt wrote:
> On Mon, Dec 14, 2015 at 04:08:32PM +0100, Ulrich Weigand wrote:
> > I don't think that r1 is actually safe here. Note that it may be used
> > (unconditionally) as temp register in s390_emit_prologue in certain cases;
> > the upcoming split-stack cod
Dominik Vogt wrote:
> On Wed, Dec 16, 2015 at 01:51:45PM +0100, Ulrich Weigand wrote:
> > Dominik Vogt wrote:
> > > > r2 through r4 should be fine. [ Not sure if there will be many (any?)
> > > > cases
> > > > where one of those is unused but r5 isn&
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01521.html
Ping.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
101 - 200 of 480 matches
Mail list logo
