this semantics. Especially the check within delete_output_reload is not
> correct.
I'm not sure how delete_output_reload comes into play here. The decision
to inherit was already made long ago, in choose_reload_regs, and that is
already incorrect. Even if the output reload for insn 1597 were not
deleted at this point, the code would still be incorrect.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
s not counted.
I see. This does look exactly like the problem Alexandre Oliva fixed for
PR target/28146:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00592.html
This patch is in mainline, but hasn't been applied to the 4.1 branch.
Could you check whether it fixes your problem?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
n have a look at that one.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
iginal anonymous struct type has already
run through rest_of_type_compilation at this stage, which has already called
dwarf2out_decl on it. This in turn has already allocated the DIE and set up
the name information. Changing TYPE_NAME afterwards has no effect on the
debug data any more.
Any suggestions how to fix this?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
has just a single
element, you might just as well use the hard reg directly in
the insn pattern here.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
that the register has to exist as a class because you can only specify
> secondary reloads on a per-reg-class basis.
I see, that makes sense.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
HARD_REGNO_NREGS (offsetted_regno, inmode);
!
! for (k = 0; k < nregs; k++)
! if (! TEST_HARD_REG_BIT (*usable_regs, offsetted_regno + k))
! return IT_NONE;
!
! can_use_inheritance_reg = 0;
! }
else
{
nregs = HARD_REGNO_NREGS (offsetted_regno, mode);
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
Bernd Schmidt <[EMAIL PROTECTED]> wrote on 03/20/2005 07:41:14 PM:
> This is OK. Would you check it in?
Done, thanks.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Sch
t additionally checks EXTRA_CONSTRAINT, and if the current operand
is rejected, reload will automatically reload the operand into a
base register.
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
run the test suite
without regressions (all languages, including Ada) on s390-ibm-linux
and s390x-ibm-linux.
Thanks for taking care of this problem!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland
t the 'make check-abi' run will overwrite the
libstdc++.log and libstdc++.sum files generated by the main 'make check' run.
This is why the results are missing from the test_summary report ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
his works because combine will treat the initial parallel as a
'single-set' insn, and nearly all optimizations will be enabled.
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
h, when building with the C++ front-end, the debug
info is properly emitted. I'm not sure where exactly the difference is ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
;
with -S -O2 -g on gcc 3.4 and 4.0 and look at the resulting
assembler file, the difference is quite obvious ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
Paolo Bonzini wrote:
> Maybe this is responsible for part of PR21828?
I'd say this *is* PR21828: note that the variables whose
type is unknown are global variables in C code compiled
with -O2 ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
c) is does indeed appear that it is
possible for edges to get deleted without the corresponding prediction
structure being removed as well ...
How is this supposed to work?
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
ompilation failed to produce
executable
FAIL: libmudflap.c++/pass57-frag.cxx (-O3) (test for excess errors)
WARNING: libmudflap.c++/pass57-frag.cxx (-O3) compilation failed to produce
executable
with current mainline on s390-ibm-linux.
Thanks for looking into this issue!
Bye,
Ulrich
--
Dr. Ulric
ion
list -- but it still remains on the old one's list ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
6/msg00583.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00584.html
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
Mark Michell wrote:
> GCC 4.0.1 RC2 is now available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616
Still fine on s390(x):
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01103.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01104.html
Bye,
Ulrich
--
D
0% in some
SPECfp cases from getting induction variable reduction wrong ...)
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
_NAME: TMT.628_22 in statement:
TMT.628_41 = PHI ;
PHI argument
TMT.628_22
for PHI node
TMT.628_41 = PHI ;
../../gcc-head/gcc/tree-ssa-operands.c:570: internal compiler error: verify_ssa
failed.
Before I start debugging, does this ring any bells?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
Linux
Diego Novillo <[EMAIL PROTECTED]> wrote on 28.06.2005 20:51:52:
> On Tue, Jun 28, 2005 at 08:38:13PM +0200, Ulrich Weigand wrote:
> > Hello,
> >
> > with current GCC mainline bootstrap fails on s390(x)-ibm-linux
> > during stage2 build with:
> >
> I&#x
ur systems.
s390(x)-ibm-linux is still looking good:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00182.html
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00183.html
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
lems, please file them in
> bugzilla, and add me to the CC: list.
s390(x)-ibm-linux are looking good:
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00688.html
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00689.html
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
r as I can recall, 4.0.2 will be the first
ever GCC release with zero testsuite FAILs across all
languages on s390-ibm-linux ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
to have crept in:
FAIL: g++.dg/template/array14.C (test for excess errors)
The error is:
array14.C: In function 'void t(int)':
array14.C:9: error: invalid lvalue in unary '&'
Any idea what this is all about?
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
unknown to the front end and gets
assigned a default alias set allowing it to alias *nothing* else.
(Note that even for Ada, fold_builtin_memcmp *will* be called,
e.g. from gimplify.c:gimplify_variable_sized_compare.)
Any suggestions how to fix this?
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
anager
* GCC 4.0.2 released.
+2005-09-21 Mark Mitchell <[EMAIL PROTECTED]>
+
+ PR c++/23993
+ * init.c (integral_constant_value): Use DECL_INTEGRAL_CONSTANT_VAR_P.
+
2005-09-16 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/23914
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
worse code generation, but only in the -O0 case, which I'm not
particularly concerned about ...
Any suggestions what the proper fix should be?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
ld -r" and the linker will pull together all input files,
including those from archives, and combine them into one single
object file. Then invoke the new "link-optimizer" on that single
object file, resulting in an optimized object file.
Any reasons why this cannot work?
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
RESS isn't actually involved, as you note:
> (*) This is exactly what code in find_reloads_address does on
> encoutering invalid indexed address. The trouble is that its
> transformation isn't valid until the reloads are done, and we check
> constraints before doing the substitutions. :-(
Bye,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
90: we want to
support -m64 (multilibs can be easily added), and 64-bit HWI simplifies
constant handling significantly. There are multiple places in the
s390 backend that rely on the size of HWI being > 32-bit, and would
likely cause overflow problems otherwise ...
Bye,
Ulrich
--
Dr.
plied by -ffast-math?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Joseph Myers wrote:
> On Mon, 20 Jan 2020, Ulrich Weigand wrote:
>
> > This has the effect that e.g. after
> >
> > -ffast-math -fno-finite-math-only
> >
> > the __FAST_MATH__ macro is no longer predefined, but after
> >
> > -ffast-math -fno-a
Joseph Myers wrote:
> On Tue, 21 Jan 2020, Ulrich Weigand wrote:
>
> > It looks like there's multiple cases here. For the two flags
> > -fassociative-math and -freciprocal-math, it seems to have happened just as
> > you describe: they were created (split out o
Joseph Myers wrote:
> On Mon, 27 Jan 2020, Ulrich Weigand wrote:
> > I see. I guess that makes me wonder what -fno-fast-math *ever* does
> > (except canceling a -ffast-math earlier on the command line). Looking
> > at the current code, -fno-fast-math (just like -ffast-mat
Joseph Myers wrote:
> On Tue, 28 Jan 2020, Ulrich Weigand wrote:
>
> > The following patch (not yet fully tested) implements the above changes.
> > Note that this now brings the set of flags set and reset by
> > set_fast_math_flags completely in sync with the se
.
If the set of operands accepted by a constraint does *not* have that
property, it must not be defined via define_memory_constraint, and
you should simply use define_constraint instead.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Jim Wilson wrote:
> On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand wrote:
> > But the only difference between define_memory_constraint and a plain
> > define_constraint is just that define_memory_constraint guarantees
> > that any memory operand can be made valid by
sibly duplicated, operand that is a far mem.
The Wfr constraint must not be marked as memory constraint (so as to avoid
reload attmpting to use it to access a stack slot). But the Y constraint
*can* be marked as memory constraint.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
really see much drawbacks from not marking it ...
(You really need the memory constraint marker for constraints that
accept only a *subset* of legitimate addresses, so that reload will
attempt to reload even addresses that would otherwise be considered
legitimate.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
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 +=
the issue, but nothing seems to have happened
so far: https://sourceware.org/bugzilla/show_bug.cgi?id=14857
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Joseph Myers wrote:
> On Wed, 30 Sep 2015, Ulrich Weigand wrote:
>
> > - Extend the official DWARF standard in some way
>
> I think you should do this.
>
> Note that TS 18661-4 will be coming out very soon, and includes (optional)
> types
>
> * _FloatN, wher
Joseph Myers wrote:
> On Thu, 1 Oct 2015, Ulrich Weigand wrote:
>
> > The _DecimalN types are already supported by DWARF using a base type with
> > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size.
>
> Which doesn't actually say whether the DPD or
Joseph Myers wrote:
> On Fri, 2 Oct 2015, Ulrich Weigand wrote:
> > I see. Well, one could add a DW_ATE_decimal_interchange_float for
> > completeness, if necessary.
>
> Since both DPD and BID are interchange encodings, that doesn't actually
> determine things with
ly be because
IRA chooses another alternative for the insn to begin with.
Do you have an example that shows the problem?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
asm). Not a problem, just a bit
> of a surprise.
I think on many targets a clobber "cc" works because the backend
actually defines a register named "cc" to correspond to the flags.
Therefore the normal handling of clobbering named hard registers
catches this case as well.
This doesn't work on i386 because there the flags register is called
"flags" in the back end.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
instructions to implement atomic operations on
16-byte data types on those machines.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Szabolcs Nagy wrote:
> On 20/12/16 13:26, Ulrich Weigand wrote:
> > I may have missed the context of the discussion, but just on the
> > specific ISA question here: both Power and z not only have the
> > 16-byte CAS (or load-and-reserve/store-conditional), but they also both
bove cast (explicit or implicit) supposed to
modify the notion of "closest surrounding subobject"?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
(if incorrectly) to
the pointer, not the pointed-to data ... (LLVM actually also
does it this way.)
Is this a bug in GCC (or the documentation)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Jakub Jelinek wrote:
> On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
> > the following C++ test case:
> >
> > struct pollfd
> > {
> > int fd;
> > short int events;
> > short int revents;
> > };
> >
>
Jason Merrill wrote:
> On 09/15/2014 11:21 AM, Ulrich Weigand wrote:
> > Jakub Jelinek wrote:
> >> On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
> >>> the following C++ test case:
> >>>
> >>> struct pollfd
>
Jason Merrill wrote:
> On 09/15/2014 11:55 AM, Ulrich Weigand wrote:
> > (https://gcc.gnu.org/ml/gcc/2014-06/msg00116.html)
>
> > From the __builtin_object_size documentation, it's not immediately
> > clear to me whether this is supposed to work or not:
> &
Jason Merrill wrote:
> On 09/16/2014 06:23 AM, Ulrich Weigand wrote:
> > Now in this case, we cast a pointer to the array to a pointer to a base
> > type of the array element type -- but the intent is for the pointer to still
> > refer to the whole array. (Of course, this o
OURCE set to 2 some more checking is added,
but some conforming programs might fail.
I guess having to use a workaround like the above is good enough.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
tps://gcc.gnu.org/ml/gcc-patches/2013-08/msg01634.html
https://gcc.gnu.org/ml/gcc-patches/2013-09/msg00450.html
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Richard Biener wrote:
> On Wed, Dec 10, 2014 at 10:09 PM, Ulrich Weigand wrote:
> > So at the very least, we should bring the documentation in line with the
> > actual behavior. However, as seen above, that actual behavior is probably
> > not really useful in an
Richard Biener wrote:
> On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand wrote:
> > However, if we make that change, there will be some cases that regress: the
> > problem is that an expression "x + y" has *one* result type, and some things
> > you do with the r
Richard Biener wrote:
> On Fri, Dec 12, 2014 at 1:08 PM, Ulrich Weigand wrote:
> > Richard Biener wrote:
> >> On Thu, Dec 11, 2014 at 4:04 PM, Ulrich Weigand
> >> wrote:
> >> > However, if we make that change, there will be some cases that regress
dule2.so");
}
dlclose (m1);
dlclose (m2);
return 0;
}
module.c
#include
__thread int x __attribute__ ((tls_model ("initial-exec")));
void func (void)
{
printf ("Module %d TLS variable is: %d\n", MODULE, x);
}
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
hat would fix the issue! Thanks for pointing this out.
I see that the latest revision:
https://sourceware.org/ml/libc-alpha/2014-11/msg00590.html
has been pinged a couple of times already, so let me add another ping :-)
Bye,
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
to be extra work in the libraries to enable 31-bit mode.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
operand, which is written before the instruction is
finished using the input operands. Therefore, this operand may not lie
in a register that is read by the instruction or as part of any memory
address.
Note in particular "... as part of any memory address."
Bye,
Ulrich
--
Dr. Ulr
.3453_2 = data;
It seems that for some reason, the pass claims to be able to
eliminate all statements that take the address of "data",
but then leaves the MEM reference unchanged ...
Any suggestions on what might cause this problem?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> A bug? Can you file a bugreport and CC me? I'll look into the
> problem.
Sure, this is now PR tree-optimization/47621.
Thanks for looking into it!
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ons though, much like today they pass constraints through.
At the point where register allocation decisions are made, those
register annotations would then be acted on.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
efined to work according to TR 18037, and it does actually
work for me on spu-elf.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
DJ Delorie wrote:
> > The only target supporting named address spaces today is spu-elf,
>
> m32c-elf does too.
Huh, I totally missed that, sorry ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Georg-Johann Lay wrote:
> Ulrich Weigand wrote:
> > This is pretty much working as expected. "pallo" is a string literal
> > which (always) resides in the default address space. According to the
> > named address space specification (TR 18037) there are no str
Georg-Johann Lay wrote:
> Ulrich Weigand wrote:
> > I'd be happy to bring this up to date if you're willing to work with
> > me to get this tested on a target that needs this support ...
>
> Just attached a patch to bugzilla because an AVR user wanted to play
> w
or RAM.
Then a plain dereference of a __far pointer would do the equivalent
of your cast_3 routine above.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Michael Matz wrote:
> On Fri, 5 Aug 2011, Ulrich Weigand wrote:
> > Instead, if you just have a address and you don't know ahead of time
> > whether it refers to Flash or RAM space, you ought to hold that number
> > in an "int" (or "short" or whate
as m32c doesn't implement those, just applying the
patch wouldn't change anything. But if that capability
*would* be helpful on your target, it would certainly be
good if you could try it out ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
porary; that's up to the target to
implement.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > It's not a restriction so much, it's simply that TR 18037 does not say
> > anything
> > about string literals at all, so they keep working as they do in standard C.
>
> Take the following bit more elabora
in touch with the IRA maintainers ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
the register allocator knows how
> to solve.
This seems to be pretty much the same as my proposal here:
http://gcc.gnu.org/ml/gcc/2011-08/msg00064.html
But there was some push-back on requiring additional semantics
by some users ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Li
:2703: error: unable to generate reloads for:
You'll need to mark your new constraint as EXTRA_MEMORY_CONSTRAINT
so that reload knows what to do when an argument doesn't match.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
that const_int's do not carry a mode, so you
cannot just look at the literal's mode to determine the required
size, but have to take the full instruction into account ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ODE (in), op0, op1);
insn = emit_insn (gen_rtx_SET (VOIDmode, out, in));
code = recog_memoized (insn);
Note how this actually performs the check whether to swap operands
for commutativity.
Can you debug this and find out why this doesn't work in your case?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
eeds to look at op1 instead.
Can you try changing the lines
if (GET_CODE (XEXP (in, 1)) == REG
&& REGNO (out) == REGNO (XEXP (in, 1)))
to
if (GET_CODE (op1) == REG
&& REGNO (out) == REGNO (op1))
instead?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
hich memory accesses support pre-increment. Therefore, the
middle-end will still always check the target's legitimate_address
callback to ensure any particular pre-incremented memory access
is actually valid. This mechanism can already look at the address
space to make its decision ...
B
PRINT_OPERAND, there already
seems to be such a format: 'W'. (Maybe not quite; since 'W'
sign-extends a 32-bit operand to 64-bit. But since 'W'
doesn't seem to be used anyway, maybe this can be changed.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Georg-Johann Lay wrote:
> Ulrich Weigand schrieb:
> > Georg-Johann Lay wrote:
> >
> >>http://gcc.gnu.org/ml/gcc/2011-08/msg00131.html
> >>
> >>Are you going to install that patch? Or maybe you already installed it?
> >
> > No, it isn'
, MEM_ADDR_SPACE
> (x))
>&& !targetm.addr_space.subset_p (MEM_ADDR_SPACE (x), MEM_ADDR_SPACE
> (mem)))
> return 0;
> else
> return 1;
> }
>
> Is this correct?
Yes, this looks correct to me ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
)
(clobber (reg:CC RCC))]
ought to work as expected.
(The remaining match_dup is fine, since reload already knows
operand 1 is used as input, so the dup doesn't introduce a
new type of use.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
piling simple
test cases, but I'd expect effects to be visible in more complex
scenarios.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
at?
There doesn't seem to be an easy way to do this from the
compiler. At the time compiler output is generated, the
original source code text isn't even kept any more; you'd
have to go back and re-read the original source files using
the line-number debug data, just as the assembler would ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ode line (and column) numbers. However, in GCC 3.x
I think this wasn't yet present, but you had to rely on line number
notes interspersed with the insn stream.
In any case, if you build with -g and use in addition the "debug
assembler output" flag -dA the assembler output should cont
contain
> > human-readable comments containing line number information.
>
> The GCC assembler is never invoked. After getting the assembler
> output from the -S option, this is fed into IFOX00/IEV90/ASMA90.
As Paolo mentioned, the -dA flag is an option to the *compiler* that
causes it to place additional information into its output stream
(the assembler source code).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
fork" feature.
B.t.w. if you cannot execute sub-tasks at all, how does the
MVS GCC invoke the preprocessor (I think this was still a
separate process in 3.2) and the core compiler (cc1) from
the compiler driver? Do you even have a separate compiler
driver?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
y ? 'X' : 'S',
>mvs_function_name);
> #else
At this point, you may refer to "current_function_decl" to
retrieve information about the function currently being output.
In particular, you can retrieve the original source-level name
associated with the routine via DECL_NAME (current_function_decl).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
. If you were e.g. to build the Fortran compiler, your
back-end gets linked against the Fortran front-end instead of the C
front-end, and that function simply will not be there. Generally,
the rule is that the back-end must not directly call front-end routines.
In any case, for C source code fname_as_string does pretty much
nothing else than what I suggested above ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ch_dest routine needs to handle
those as well. Probably something along the following lines:
if (GET_CODE (dest) == IF_THEN_ELSE)
{
if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
dest = XEXP (dest, 1);
else
dest = XEXP (dest, 2);
}
gcc_assert (GET_CODE (dest
1 - 100 of 165 matches
Mail list logo
