"Paul Edwards" wrote on 03.09.2021 13:35:10:
> > Specifically, if you try to run AMODE64 with Pmode equals
> > SImode, the compiler will not be aware that the hardware
> > uses the high 32 bits of base and index registers, and
> > will not necessarily keep them zero.
> The compiler naturally
"Paul Edwards" wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.
OK, that makes things clearer. This implies in particular:
- 4GB address space means you need to run in AMODE64
- AMODE64 means the native address size
"Paul Edwards" wrote on 02.09.2021 17:26:25:
> > Therefore again my question, what is the actual goal
> > you want to achieve? I'm still not sure I understand
> > that ...
> I would like to know what is required to implement
> “-m32” in the S/390 target. I realize that z/Arch
> doesn’t have a
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to address computation, of course.
For example, GCC may use LA on -m31 to implement a
31-bit addition, w
Hi Paul,
> I just checked my copy of s390.md and I don’t see
> LA being used for arithmetic.
This would be the "*la_31" and "*la_31_and" patterns.
(Note that the addition is implicit in the use of
the "address_operand" constraint.)
> If your copy of s390.md is using LA for arithmetic
> then wo
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
>
> It all worked fine, and we w
ions on what to do here?
>
> This kind of extension is pretty normal in DWARF, so I think it isn't a
> big deal to emit it. Consumers are ordinarily expected to simply ignore
> things they don't understand.
Given Eric's GCC change above, this is no longer necessary now.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
lso
DW_TAG_reference_type, DW_TAG_rvalue_reference_type,
DW_TAG_ptr_to_member_type and possibly others). Also, the
implementation in GDB would need to be changed accordingly.
Any comments or suggestions on what to do here?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
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
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, 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, 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
plied by -ffast-math?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
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
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/
)
if test "x$enable_obsolete" != xyes; then
--
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
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
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
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
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
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
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
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 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
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
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 +=
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
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
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
.
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
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
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
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
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 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
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
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
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
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/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
>
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;
> > };
> >
>
(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
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
it was correct (in most cases, including
your test case), but somewhat confusing and proved not particularly
useful in the end, so we changed it. Current compilers will never
transform paradoxical subregs to accessing excess bytes in memory
any more.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
). Only the second question really provides any actual
*new* information ...
See also the reload patch I recently posted to get rid of some uses
of offsettable_memref_p in favor of simply doing the change and testing
its validity afterwards:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.htm
is probably incomplete. I think I need to write more
> secondary reload patterns. For example to handle a 64-bit mem with
> an offset in the range 7ffc to 7fff used with 32-bit gprs.
> Second reload question: Am I correct in assuming this is needed? The
> case I'm thinking of
Andrew Pinski wrote:
> On Tue, May 8, 2012 at 4:56 AM, Ulrich Weigand wrote:
> > Hmm, SPU also supports only SJLJ exceptions ...
>
> IIRC the main reason is because SJLJ exceptions produced smaller
> binary size. Though I wonder if this should not be looked at again to
> s
Steven Bosscher wrote:
> On Tue, May 8, 2012 at 1:56 PM, Ulrich Weigand wrote:
> > Steven Bosscher wrote:
> >
> >> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions.
> >
> > Hmm, SPU also supports only SJLJ exceptions ...
>
> Then w
Steven Bosscher wrote:
> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions.
Hmm, SPU also supports only SJLJ exceptions ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
.
This is exactly the reason why you need a constraint letter
that accepts only addresses without index register, instead of
just using plain "m".
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ARGET_64BIT"
"@
la\t%0,%a1
lay\t%0,%a1"
[(set_attr "op_type" "RX")
(set_attr "type" "la")])
(define_expand "reload_insi"
[(parallel [(match_operand:SI 0 "register_operand" "=a")
(match_ope
d be fine.
If you want to support 64-bit hosts as well, however, you
will need to handle 64-bit CONST_INT values too.
> But regardless I don't know how to make this code:
>
> mvs_check_page (0, 6, 8);
> return \"MVC^I%O0(8,%R0),%1\";
>
> make use of that 'W' operand.
>
> Do I change that %1 to %W1 perhaps?
Yes, exactly.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote:
> > we've noticed that the loop optimizer sometimes inserts weirdly
> > inefficient code to compute the value of an induction variable
> > at the end of the loop.
[snip]
> The issue i
else I'm overlooking right now?
I'd appreciate any tips / suggestions how to fix this ...
Thanks,
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
, 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
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'
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
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
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
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
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
: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
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
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
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
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
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
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
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
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
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
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
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
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
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
.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
o a *jump* pattern, and those
must never have output reloads, since reload has no place to
put them.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
own to be sufficient to make the address valid
again. Therefore, we can simply assume that the final address
after all reloads are applied will be legitimate, without having
to explicitly check for that ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Ian Lance Taylor wrote:
> "Ulrich Weigand" writes:
> > The way some ports take around this issue is to recognize, in your
> > EXTRA_CONSTRAINT_STR implementation, certain forms of complex
> > addresses as those which you *know* reload will already have marked
&
g, and therefore *accept* them (if they'd otherwise
match the constraint).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
in the first pattern inside the
> PARALLEL, and there is a USE of CC0 in the second pattern of the
> PARALLEL.
That's incorrect; the second pattern of the PARALLEL is just a CLOBBER.
The USE of CC0 happens in a completely separate second INSN that is
emitted by this define_expand. (Note
oblems with dataflow not recognizing a parallel set of two
subregs as actually fully setting the whole register ...
But of course, that was a long time ago, maybe the new dataflow
mechanism has fixed this now.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Michael Meissner wrote:
> On Wed, May 26, 2010 at 08:09:57PM +0200, Ulrich Weigand wrote:
> > In the current patch, the SPU back-end uses somewhat of a hack to actually
> > perform that call: it is included in the REGISTER_TARGET_PRAGMAS macro.
> > Note that this macro is alre
Mike Meissner wrote:
> On Wed, May 26, 2010 at 10:16:22AM -0700, Mark Mitchell wrote:
> > Ulrich Weigand wrote:
> >
> > >> So the question is: The goal is to have hooks, not macros, right? If
> > >> so, can reviewers please take care to reject p
the same?
I'll have a look. What is the preferred solution these days for
hooks between the C front-end and a back-end? targetcm?
(Why is there both targetcm and targetm.c ?)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
because it ought to know that reload will already load the (sp + const)
into a register anyway.
If this is *not* the case, please send me the instruction pattern
and constraints for the insn pattern that matched insn 320 before
reload so I can investigate in more detail.
(Please note that I'm cu
at target code running on the
mainframe would. This can manifest in the same source code
leading to different results when compiled with optimizations
as compared to without optimizations, for example.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ine DATA_SECTION_ASM_OP "* Program data area"
> #define INIT_SECTION_ASM_OP "* Program initialization area"
> + /* +++ now poisoned */
> + #if 0
> #define SHARED_SECTION_ASM_OP "* Program shared data"
> + #endif
This is no longer needed; it was used to support -fshared-data
which is no longer present.
Note that I'd expect that with the above obvious issues fixed,
you may well run into additional problems in moving the port
forward ... At some point, it will be necessary to be able
to debug the back-end and resolve problems.
Overall, I still think that adding HLASM support to the s390
back-end would probably be a simpler task ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
a comment should be trivial at the place in the
Makefile.in where gencheck.h is generated (s-gencheck).
In any case, more recent GCC versions no longer refer to this
file at all.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
:
>
> //ST2CMP PROC GCCPREF='GCC',MEMBER='',
> // PDPPREF='PDPCLIB',
> // COS1='-Os -S -ansi -pedantic-errors -remap -DHAVE_CONFIG_H',
> // COS2='-DIN_GCC -DPUREISO -o dd:out -'
>
> Having another define, just to define an empty string, seems very
> ugly indeed, even assuming it comes in under 100 characters.
Ah, OK.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
> for a few largish chunks of flags to mask out.
Note that with current GCC versions, all these flag global
variables are defined by C source code that is automatically
generated from various option parameter files. This should
make it simpler to change this e.g. to use a struct instead
of m
e this by hand? The usual make process will
define PREFIX while building prefix.c, using the appropriate
value determined at configure time ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Paul Edwards wrote:
> The QI must be a signed char, and thus rejecting any value greater than 127.
> As you can see, I changed it to SI, which, with the constraints and tests
> in place, should be fine.
Ah, OK. That would explain it.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Tool
ss then operates wholly in the build directory, without
changing anything in the source directory. For doing the second compiler
build, you can either delete the build directory, or just use yet another
directory.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
odd must be going on ...
Are you running the top-level configure? (If you run a
subdirectory configure, e.g. the one in gcc/, directly,
things may not work correctly.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ure.
Did you make sure to use the proper build / host / target flags?
In particular, the --build= configure argument must be present
and refer to the build architecture. This is used to determine
which architecture to build the generator programs for.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
===
> RCS file: /cvsroot/gccnew/gcc/configure,v
For now, just patching configure to see how far you get is of course fine.
Longer term, however, note that configure is a generated file. You'd have
to make those changes either in configure.ac or possible wit
[configure-gcc] Error 1
>
> I haven't had a chance to investigate what it's trying to do there, to
> see if I can devise a workaround.
The compiler error output found in the config.log file should hopefully
point to the problem ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
1 - 100 of 165 matches
Mail list logo
