Great job, Stefan! Congratulations!
Thank you David!
Bye,
Andreas
On 9/30/24 16:33, David Edelsohn via Gcc wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Stefan Schulze Frielinghaus as a s390x port co-maintainer.
Please join me in congratulating Stefan on his n
The current implementation assumes to always be invoked with register
operands. For memory operands we even have an instruction
though (vlrep). With the patch we try this first and only if it fails
force the input into a register and continue.
vec_splats generation fails for single element 128bit
On 5/16/22 08:29, Andreas Krebbel via Gcc wrote:
> Hi,
>
> I'm trying to provide a simple dwarf unwinder with access to the
> argument register content. The goal is to make this information
> available for optimized code without having to access debug
> information for thi
On 5/16/22 16:39, Andreas Schwab wrote:
> On Mai 16 2022, Andreas Krebbel via Gcc wrote:
>
>> The only way I see right now is adding a new reg note to invalidate
>> the save information in the reg_save array in dwarf2cfi.
>>
>> Would this be acceptable? Is there pe
Hi,
I'm trying to provide a simple dwarf unwinder with access to the
argument register content. The goal is to make this information
available for optimized code without having to access debug
information for things like call site args. The extra overhead
of saving the values to the stack is accep
On 4/13/22 09:30, Richard Biener via Gcc wrote:
>
> Status
> ==
>
> The gcc-11 branch is now frozen in preparation for a GCC 11.3 release
> candidate and the GCC 11.3 release next week. All changes now require
> release manager approval.
Hi,
I would like to push:
https://gcc.gnu.org/piper
On 3/21/22 17:28, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping port maintainers about
> https://gcc.gnu.org/PR102024
>
> As I wrote, the int : 0 bitfields are present early in the TYPE_FIELDS
> during structure layout and intentionally affect the layout.
> We had some code to remove those from
On 6/4/21 8:18 PM, Paul Koning wrote:
...
> Yes, I would think this should be made a general mechanism that any target
> could use.
>
> I wonder if instead of creating a new mechanism you could do this simply by
> creating new constraint names, where each name matches exactly one hard
> registe
Hi,
I wonder if we could replace the register asm construct for
inline assemblies with something a bit nicer and more obvious.
E.g. turning this (real world example from IBM Z kernel code):
int diag8_response(int cmdlen, char *response, int *rlen)
{
register unsigned long reg2 asm ("2") =
On 22.11.18 10:30, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 7 branch is open for regression and documentation fixes.
>
> I plan to do a GCC 7.4 release in a few weeks starting with a
> first release candidate at the end of next week, likely Nov. 29th.
>
> Please go through your ass
On 04/25/2017 12:25 PM, Jakub Jelinek wrote:
> On Mon, Apr 24, 2017 at 06:08:15PM +0200, Andreas Krebbel wrote:
>> On 04/20/2017 12:02 PM, Jakub Jelinek wrote:
>>> Status
>>> ==
>>>
>>> We have reached zero P1 regressions today (and < 100 i
On 04/20/2017 12:02 PM, Jakub Jelinek wrote:
> Status
> ==
>
> We have reached zero P1 regressions today (and < 100 important
> regressions) and the branches/gcc-7-branch has been created;
> GCC 7.1-rc1 will be built and announced likely tomorrow.
> The branch is now frozen for blocking regres
On 03/07/2016 02:12 PM, Dominik Vogt wrote:
> A recent patch has broken bootstrapping (s390x) in stage3. The
> failure creeped into trunk between friday and today:
>
> -- snip --
> g++ -std=gnu++98 -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narro
On 10/27/2015 06:09 PM, Jakub Jelinek wrote:
> On Tue, Oct 27, 2015 at 05:47:19PM +0100, Andreas Krebbel wrote:
>> Hi,
>>
>> what does speak against folding SUBREGs on constants in fold_rtx?
>>
>> CSE does refuse to propagate constants into subreg expressions proba
Hi,
what does speak against folding SUBREGs on constants in fold_rtx?
CSE does refuse to propagate constants into subreg expressions probably because
fold_rtx does not
handle it - and in fact a subreg on a constant does not seem to be defined. I'm
wondering why this
is the case? What's the prob
Hi,
I would like to commit the IBM z13 support patchset before that.
>From a common code perspective it is:
recog: Increased max number of alternatives - v2
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html
optabs: Fix vec_perm -> V16QI middle end lowering.
https://gcc.gnu.org/ml/gcc-pat
On 06/04/2015 09:15 AM, Ondřej Bílka wrote:
> On Thu, May 28, 2015 at 05:37:53PM +0200, Andreas Krebbel wrote:
>> On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote:
>>>> On May 28, 2015, at 11:59 AM, Richard Biener
>>>> wrote:
>> ...
>>>> Mayb
On 06/03/2015 12:53 AM, Richard Henderson wrote:
> On 06/02/2015 08:32 AM, Andreas Krebbel wrote:
>> -(define_insn "*3"
>> +(define_insn "*3_reg"
>> [(set (match_operand:GPR 0 "register_operand" "=d")
&
On 06/02/2015 07:13 PM, Jeff Law wrote:
> But isn't that 3 registers used in the address computation if the
> (const_int 1) gets reloaded? one of the value shifted, two for the
> shift count? I'm not familiar with the s390, so if you can handle that
> kind of insn, then, umm, cool.
The address
On 06/01/2015 05:06 PM, Jeff Law wrote:
> On 06/01/2015 06:23 AM, Andreas Krebbel wrote:
>> On 05/30/2015 02:57 AM, DJ Delorie wrote:
>>> In config/s390/s390.c we accept addresses that are SImode:
>>>
>>>if (!REG_P (base)
>>> || (GET_MO
On 05/30/2015 02:57 AM, DJ Delorie wrote:
> In config/s390/s390.c we accept addresses that are SImode:
>
> if (!REG_P (base)
> || (GET_MODE (base) != SImode
> && GET_MODE (base) != Pmode))
> return false;
>
> However, there doesn't seem to be anything in the s390's
On 05/28/2015 11:16 AM, Maxim Kuvyrkov wrote:
>> On May 28, 2015, at 11:59 AM, Richard Biener
>> wrote:
...
>> Maybe follow s390 -mhotpatch instead?
>
> Regarding implementation of the option, it will follow what s390 is doing
> with function attributes to mark which functions to apply nop-trea
On 05/22/2015 10:54 AM, Richard Biener wrote:
> On Fri, 22 May 2015, Andreas Krebbel wrote:
>
>> On 05/22/2015 10:22 AM, Richard Biener wrote:
>>> On Fri, 22 May 2015, Andreas Krebbel wrote:
>>>
>>>> Hi,
>>>>
>>>>
On 05/22/2015 10:22 AM, Richard Biener wrote:
> On Fri, 22 May 2015, Andreas Krebbel wrote:
>
>> Hi,
>>
>> in order to get the IBM z13 support into present distros the Linux
>> distributors asked me to get this
>> stuff upstream into the older GCC branc
Hi,
in order to get the IBM z13 support into present distros the Linux distributors
asked me to get this
stuff upstream into the older GCC branches first. This would ease the whole
backporting efforts,
interactions with other patches and would make sure that everybody uses the
same code level.
On 01/27/2015 10:04 AM, Richard Biener wrote:
> On Tue, 27 Jan 2015, Andreas Krebbel wrote:
>
>> Hi,
>>
>> I would like to apply the following patch:
>>
>> [PATCH] S/390: -mhotpatch v2
>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02370.html
>>
Hi,
I would like to apply the following patch:
[PATCH] S/390: -mhotpatch v2
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02370.html
It is a backend only change to our existing -mhotpatch feature
requested by the Linux kernel guys for the ftrace implementation:
https://lkml.org/lkml/2015/1/26/32
On 01/16/2015 06:47 PM, Vladimir Makarov wrote:
>
> On 2015-01-16 12:30 PM, Andreas Krebbel wrote:
>> Hi,
>>
>> on S/390 I see invalid subregs being generated by LRA although
>> CANNOT_CHANGE_MODE_CLASS is supposed
>> to prevent these. The reason appe
Hi,
on S/390 I see invalid subregs being generated by LRA although
CANNOT_CHANGE_MODE_CLASS is supposed
to prevent these. The reason appears to be the code you've added with:
commit c6a6cdaaea571860c94f9a9fe0f98c597fef7c81
Author: vmakarov
Date: Tue Oct 23 15:51:41 2012 +
...
int
simplify
On 06/02/14 14:55, Sebastian Huber wrote:
> Hello,
>
> for the test case gcc.dg/uninit-13.c:
>
> /* { dg-do compile } */
> /* { dg-options "-O -Wuninitialized" } */
>
> typedef _Complex float C;
> C foo()
> {
>C f;
>__imag__ f = 0;/* { dg-warning "is used" "unconditional" } */
>r
On 21/05/13 20:01, Richard Henderson wrote:
> On 05/21/2013 05:40 AM, Andreas Krebbel wrote:
>> Hi,
>>
>> I'm currently implementing support for hardware transactional memory
>> in the S/390 backend and ran into a problem with saving and restoring
>> the fl
On 21/05/13 16:28, Torvald Riegel wrote:
> On Tue, 2013-05-21 at 14:40 +0200, Andreas Krebbel wrote:
> You could also start with supporting s390 HTM through the transactional
> language constructs we already support (__transaction_atomic etc.) and
> libitm. The advantage would be
Hi,
I'm currently implementing support for hardware transactional memory
in the S/390 backend and ran into a problem with saving and restoring
the floating point registers.
On S/390 the tbegin instruction starts a transaction. If a subsequent
memory access collides with another the transaction i
On 24/04/13 15:40, Richard Biener wrote:
> I expected we preserve edges across RTL expansion? We cannot re-create
> them optimally from scratch, but yes, re-construction is possible. Can you
> open a bugreport pointing out the missing RTL bits?
Done.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
On 23/04/13 17:19, Florian Weimer wrote:
> On 04/23/2013 04:45 PM, Andreas Krebbel wrote:
>> I was not able to reproduce the problem with head GCC. But I couldn't
>> find anything which addresses the problem either. So I assume that a
>> different situation before the
Hi,
with GCC 4.1 and GCC 4.4 (RHEL 5.9) the example below prints a value
of 1 for netwait (on x86_64 and s390x). The problem is that the
assignment at /* 2 */ is moved to /* 1 */ during instruction
scheduling.
The quick fix is to make "netwait" volatile. But according to the C
standard (7.13.2.
Hi,
I've committed the following patch.
It should even perform better since we are able to often get rid of the
instructions extracting the condition code into a register (ipm, srl).
If all targets have been migrated the files probably could be merged?!
Bye,
-Andreas-
2012-06-15 An
On 02/15/2012 08:53 PM, Richard Sandiford wrote:
> This fixes gdb backtraces from a stripped executable, but libgcc's
> unwinder seems to get confused by having a stub in the middle of the
> trace that (a) isn't a signal handler and (b) has no frame of its own.
> The CFA at the point of the call to
On 01/27/2012 06:16 PM, Andrew Haley wrote:
> On 01/27/2012 05:14 PM, Dave Korn wrote:
>> On 27/01/2012 17:01, Andrew Haley wrote:
>>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>>
>>>> Starting with this IRA patch:
>>>> http://gcc.gnu.org/ml
On Fri, Jan 27, 2012 at 06:08:23PM +0100, Eric Botcazou wrote:
> > To my understanding this can only happen if there is control flow from
> > a leaf function which in turn should only occur with signals. Perhaps
> > we could modify the CFA "a bit" for the frame where the signal
> > occurred? Ther
Hi,
while debugging the java failure Divide_1 on s390 I stumbled over
some weird behaviour in the unwinding code.
In the testcase a divide by zero is triggered intentionally. So that
the java sigfpe handler is invoked in __divdi3:
Divide_1::probe_1() -> __divdi3
|SIGFP
David,
for s390 we would also be interested in a solution like that. s390 is big
endian and
endianess conflicts often come in the way when porting an application from
'other'
platforms. Linus Torvalds already in 2001 made a quite similiar suggestions
using a type
attribute:
http://gcc.gnu.org
I've opened bz #41535 for this problem.
Bye,
-Andreas-
Hi,
on s390x I see broken debug info generated for the attached C++
testcase (compile with -O2 -g -fPIC).
The debug info contains a symbol reference with a @GOTENT modifier
what should not happen (and is not accepted by gas):
.LLST3:
On Sun, Jun 14, 2009 at 11:02:04PM +0200, Giuseppe Scrivano wrote:
> Hello,
>
> last GCC revision has a compiler warning at line 8502. Is this
> extremely trivial patch OK?
This has already been fixed:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01109.html
Sorry for the breakage.
Bye,
-Andre
Hi,
> r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
The cond-optab branch (rev. 145751) fails to bootstrap on s390x:
/build2/gcc-condoptab/libgcc/../gcc/libgcc2.c: In function '__fixunsdfti':
/build2/gcc-condoptab/libgcc/../gcc/libgcc2.c:1266: internal compiler error: i
Hi,
> I.e. we need (primaries) x86-freebsd, x86-darwin, sparc-solaris2.10 and
> (secondaries) hppa-hpux11, ppc-aix5.2, ppc-darwin, x86-mingw32 and
> s390-linux-gnu.
I've tested with:
gmp-4.2.2-7 (fedora core 9)
mpfr-2.4.1 (vanilla)
gcc 4.3.2
mpc-0.6
The mpc testsuite is clean on s390-linux-
Andrey made me aware that this is PR37535. Vladimir is obviously
already working on this.
Bye,
-Andreas-
Hi,
I'm debugging the S/390 bootstrap problem and stumbled over an IRA
behaviour which I don't quite understand.
The following code in process_bb_node_lives ira-lives.c makes sure
that for clobbered regs which are also used for inputs the proper
conflicts are recorded:
static bool
def_conflicts_
Hello Ian,
> In that case, just comment out the bulk of the test based on
> STACK_SIZE.
Ok. How about that patch? It should be ok until someone digs out a
target with a stack size below 64 bytes ;) (plus the bytes for the
other auto variables).
I've decided not to disable the testcase completel
Hello,
I'm experimenting with a hardware dfp libgcc_s for S/390. The target
is to have an additional variant of that lib built using the multilib
machinery.
Regarding this I'm wondering how to set MULTILIB_OSDIRNAMES correctly.
This variable is usually set in a makefile fragment in the back end
Hello,
the uninit-13.c testcase fails on s390 and s390x:
1 /* { dg-do compile } */
2 /* { dg-options "-O -Wuninitialized" } */
3
4 typedef _Complex float C;
5 C foo()
6 {
7 C f;
8 __imag__ f = 0; /* { dg-warning "is used" "unconditional" } */
9 return f;
10 }
On s390 and s390x the repo
Hi Ian,
have you had time to look at this? Or does anyone else like to
comment?
http://gcc.gnu.org/ml/gcc/2007-10/msg00092.html
Bye,
-Andreas-
Hi Ian,
have you had time to look at this? Or does anyone else like to
comment?
http://gcc.gnu.org/ml/gcc/2007-10/msg00092.html
Bye,
-Andreas-
Hi Ian,
sorry for the late response. I was on vacation for the last two
weeks. (Btw. thats also the reason for the S/390 daily build system
being down over the last days. It is back online now.)
> > The lengthy part is necessary to have attribute getter functions which
> > allow to specify the
Hi Ian,
> I'm sorry I haven't had time to reply to this patch, but I'm not
> entirely happy with it. Conceptually it seems reasonable, but I don't
> understand why your implementation has to work the way it does; it
> seems overly complicated. And I wonder whether it wouldn't be simpler
> to ach
Hi Mark,
there are 3 simple patches waiting for review which I hoped to get in
in stage 2. They should be a nop for targets not exploiting the new
insn attribute. So I hope they still qualify for early stage 3. I've
several patches on my harddisk relying on that feature to be present
so I would
Hello,
the bootstrap failure you are seeing is caused by my decompose
multiword shift patch:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html
It is the same failure as reported by Andreas Tobler:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00533.html
I don't have access to a sparc machin
> We explicitly pull out initializers from variables that are:
> /* Pull out any truly constant values. */
> if (TREE_READONLY (rhs)
> && TREE_STATIC (rhs)
> && DECL_INITIAL (rhs)
> && valid_gimple_expression_p (DECL_INITIAL (rhs)))
>ret
Hi,
GCC currently doesn't bootstrap on s390x. The problem is that
gengtype is miscompiled and I suspect the fre - sccvn changes to be
the culprit.
When sccvn performs the depth-first search for uses it might reach
global variable definitions. If the global variable is initialized
with a value th
Hi,
On Wed, May 02, 2007 at 01:34:18PM -0700, Mark Mitchell wrote:
> GCC 4.2.0 RC3 is now available from:
Successfully built on s390 and s390x:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00142.html
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00143.html
Bye,
-Andreas-
Hi,
> OK. Then would it be enough to weaken the condition of the removal test to
>
> if (loop_invariant_p (loop, ...) != 1)
>
> in order to solve your problem?
Sure, that would be an alternative compared to always removing the
REG_EQUAL notes when hoisting an insn and it would fix my particul
Hi Eric,
> The note doesn't look particularly helpful in this case, given that gcse
> has replaced r974 with r1218 in the insn. How is it created?
The register replacement is done by gcse but the cse pass invoked from gcse
modifies the REG_EQUAL note. The limited scope of cse compared to gcse i
> To answer that, I'm afraid my patch is to blame:
>
> 2007-04-24 Richard Sandiford <[EMAIL PROTECTED]>
>
> * optabs.c (set_conv_libfunc): Prefer libgcc2's __ffsMM2 functions
> over an external ffs function.
>
> We used to use ffs to implement __builtin_ffs if sizeof (int),
> even
Hi,
I'm debugging a problem with the GCC 4.1 old loop optimizer.
Consider the following example:
After gcse1 a loop body contains the following two insns. Note that gcse
has already replaced r974 with r1218 in insn 1743 and has attached a REG_EQUAL
note. Insn 2308 stays as a dead store - maybe t
Hi,
java is currently not bootstrapping on s390. The problem appears
to be that the __ffssi libgcc function is not exported since it is
not listed in libgcc-std.ver.
Here are the details:
Building the gcj-dbtool linking against libgcj.so the following error
is reported:
/build2/gcc-4.3-build/
Hi,
gcc currently doesn't boostrap on s390 and s390x:
/build2/gcc-4.3-build/s390x-ibm-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:2025:
internal compiler error: in cse_find_path, at cse.c:5930
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.
Hi,
please could someone comment on this one:
http://gcc.gnu.org/ml/gcc/2007-01/msg01261.html
I still don't have a solution to replace the mode(word) uses in unind-generic.h
with a different mechanism. Currently mode(word) is the only way how non-gcc
code can define the _Unwind_Word data type.
Hi,
the gcc 4.1 testsuite currently shows a failure for the libstdc++ abi_check
testcase
on s390 and s390x and I see this one failing on several other targets as well.
On s390x abi_check complains about 22 missing functions in libstdc++.so:
FUNC:acosl@@GLIBCXX_3.4.3
FUNC:asinl@@GLIBCXX_3.4.3
FU
Hello,
I've grepped through the remaining uses of Unwind_Word in libgcc and
the related word_mode uses in gcc and would like to discuss how to go
on with these.
One target is to identify more places where we can get rid of _Unwind_Word.
Other places exist where we definitely need a data type lik
Hi,
I could successfully bootstrap the dataflow branch on s390 and s390x.
Configure options:
--enable-shared --with-system-zlib --enable-threads=posix
--enable-__cxa_atexit --enable-checking
--enable-languages=c,c++,fortran,java,objc
No testsuite regressions occurred comparing dataflow branch
Hi Robert,
On Mon, Oct 09, 2006 at 08:21:45AM -0400, Robert Dewar wrote:
> >In the criteria for primary plattforms I've read that primary plattforms
> >have to be "popular systems". Reading this as "widely used" I think that
> >this will be a requirement which mainframes are unlikely to meet in th
Hello Mark,
sorry for tuning in so late to the GCC 4.3 primary/secondary
plattform discussion.
As you probably expect I'll give a vote for s390-ibm-linux-gnu
and s390x-ibm-linux-gnu to be marked as gcc secondary plattforms.
I think the s390 back end is in a pretty good shape. The languages
c,ad
Hi,
my daily build for s390(x) still shows the 2 following
gfortran testcases failing on the 4.0 branch:
actual_array_constructor_2.f90 (#28167)
actual_array_substr_2.f90 (#28174)
Both were committed with rev. 115186 for gcc 4.1 and with rev. 115185
for 4.0 by Alexandre Oliva. The patch
Hi,
> On those grounds, please submit a change to fix both places in
> cse.c. If we run into further problems of this kind, we'll have to
> rethink whether such patterns are valid.
Ok. I'll do so as soon as possible. Unfortunately the trivial fix of
just removing the else branch doesn't work.
> An insn matched by anddi_1_rex64 must not be emitted via the "anddi3"
> expander.
"must not" should be replaced here by "does not need to"
a common error for Germans ... or well at least for me ;-)
Hi,
> The x86 pattern is called "anddi_1_rex64", which is not one of the standard
> names: that means the compiler will never emit it directly.
Not necessarily. Someone simply could call gen_andidi_1_rex64 (e.g. from i386.c)
to emit this pattern. That the insn doesn't use a standard name only
Hi,
> Hmm. I note that if you /were/ using match_dups, the problem would be
> solved because all four changes would go through the 'then' clause of the
> if...else construct. Maybe it would be more worthwhile for you to have
> separate patterns after all and find some other way of making reloa
Hi,
could please someone help me with this one:
http://gcc.gnu.org/ml/gcc/2006-05/msg00337.html
Bye,
-Andreas-
Hi Dave,
thanks for your comments.
> Doesn't this mean that your insn patterns should be using numerical (aka
> "matching") constraints?
Oh we are using matching constraints. But of course nobody except reload does
care
about them. If the only constraints for an operand are matching constrain
Hello,
when cse replaces registers in an insn it tries to avoid calls to
validate_change, what causes trouble in some situations.
>From validate_canon_reg:
/* If replacing pseudo with hard reg or vice versa, ensure the
insn remains valid. Likewise if the insn has MATCH_DUPs. */
if (ins
> Does this help?
>
> @@ -13802,9 +13777,8 @@
> s->refcount++;
> /* Avoid unnecessarily putting strings that are used less than
>twice in the hash table. */
> - if (s->refcount == 2
> - || (s->refcount == 1
> - && (DEBUG_STR_SECTION_FLAGS
Hi,
> Ada currently does not have built-in support for multilibs (there's a related
> PR I believe).
#5911 I suppose.
> Instead, it has another (similar but different) mechanism via the --RTS
> make/compile/bind switch, which require manual build/install of several
> gnatlib via calls to make -C
Hi,
31bit Ada executables segfault when built on a 64bit system with gcc 4.x.
The 31bit libgnat library is installed in /usr/lib. When I build an 31bit
executable with -m31 using a 64bit gcc executing the result failes with
a segfault in the gnatbind generated adainit function. Further debugging
On Fri, Feb 24, 2006 at 09:00:25AM -0800, Mark Mitchell wrote:
> GCC 4.1 RC2 is now available from:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.0-20060223
Looks good on s390-ibm-linux and s390x-ibm-linux
http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01489.html
http://gcc.gnu.org/ml/gcc-testre
> struct foo { int n; };
> extern unsigned long c = 0;
>
> {
> int b;
>
> b = 2;
> ((struct foo*)(&b + c))->n = 3;
> }
For having a true dependency the example should look like this:
struct foo { int n; };
extern unsigned long c = 0;
{
int b;
int d;
b = 2;
d = ((struct foo*)(&b
Hi,
in true_dependence (alias.c) a varying struct
address is considered to never alias a fixed scalar value. This
rule is triggered also in something like the following:
struct foo { int n; };
extern unsigned long c = 0;
{
int b;
b = 2;
((struct foo*)(&b + c))->n = 3;
}
This is a bit ove
(I've sent this first to gcc-patches accidently :(
> Kenny thought it would be nice, rather than pass the actual bb info to free
> to the freeing function, to instead pass some random bitmap.
>
>
> The attached fixes *that*, but this just causes a crash deeper in trying to
> free some chains.
>
tch for
mainline gcc.
Bootstrapped on i686, s390 and s390x without testsuite regressions.
This patch fixes the 920501-4.c regression on s390x.
Bye,
-Andreas-
2005-10-13 Andreas Krebbel <[EMAIL PROTECTED]>
* flow.c (mark_set_1): Handle CLOBBERs like SETs if the register
ession on s390x.
Bye,
-Andreas-
2005-10-13 Andreas Krebbel <[EMAIL PROTECTED]>
* flow.c (mark_set_1): Handle CLOBBERs like SETs if the register
is live afterwards.
Index: gcc/flow.c
===
RCS file: /cvs/gcc/
Hello,
I've opened a bugzilla for this: #24034
Bye,
-Andreas-
Hello Richard,
s390 and s390x can't bootstrap with the following patch, because the new
assertion
introduced with the fixup_eh_region_note function is triggered.
http://gcc.gnu.org/ml/gcc-cvs/2005-08/msg01022.html
2005-08-31 Richard Henderson <[EMAIL PROTECTED]>
PR rtl-opt/23601
Hi,
I see the same failure on s390 and s390x.
It is probably caused by one these patches.
Bye,
-Andreas-
> 2005-09-01 Jakub Jelinek <[EMAIL PROTECTED]>
>
> PR c/23506
> * c-common.c (c_common_nodes_and_builtins): Increase builtin_types
> array by one element, initialize the
Hello,
sorry for the late answer.
> Vlad promised to update it to use df.c once it wasn't "1% slower", which
> would make it easily reusable elsewhere, but never did.
> Of course, you could reuse it without that, but then someone will
> invariably come along and mess with it.
Ok I understand tha
Hello,
the 920501-4.c testcase currently fails on s390x with a
"fatal error: internal consistency failure" in reg rename.
The example uses an uninitialized variable. Normal live analysis
consideres this variable to be live over all basic blocks.
But global alloc uses a special liveness checker co
Hi,
mainline bootstrap on s390 currently fails with:
build/genmddeps ../../gcc/config/s390/s390.md > tmp-mddeps
../../gcc/config/s390/s390.md:2041: undefined attribute 'DBL' used for mode
../../gcc/config/s390/s390.md:2041: following context is `'
DBL is a macro attribute defined as:
(define_mo
Hi Richard,
the protoize utility can't be built with gcc 4.x.
Your patch "Using .opt files for target options"
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01297.html
makes options.h to be included by tm.h by adding it to tm_include_list
in gcc/configure.ac. tm.h is included by protoize.c. That
Hi Richard,
I've recently experimented with TARGET_SHIFT_TRUNCATION_MASK
macro and have posted a patch defining it for S/390.
On S/390 only the least significant six bits of a shift count
operand are used and I therefore expected the modulo operation
in the following example to be optimized awa
Hi,
thanks for your responses.
I've debugged a little further and found out that
the testcase breakage was caused by (the elfos.h part):
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00913.html
The elfos.h part of the patch was reverted on 04/14/2005:
http://gcc.gnu.org/ml/gcc-patches/2005-04/ms
Hi,
on S/390 we have currently a plenty of testsuite failures
due to inlining effects.
ld complains about testcases which try to link two files containing the same
function
in .gnu.linkonce sections but with different code sizes. The sizes differ due
to different inlining decisions. The problem
100 matches
Mail list logo