On Wed, Jan 25, 2017 at 04:45:23PM -0600, Segher Boessenkool wrote:
> On Wed, Jan 25, 2017 at 06:36:04PM +0100, Dominik Vogt wrote:
> > On the other hand, Combine
> > does not know that they are "outlawed" and happily generates
> > them.
>
> combine should not
ann a
pass right after it that forces a reaload into a pseudo for such
memory references (for the targets that don't want them)? (Not
sure if theat would result in a noticeable gain or not.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Thu, Mar 17, 2016 at 01:22:04PM -0700, Richard Henderson wrote:
> On 03/16/2016 11:35 PM, Dominik Vogt wrote:
> > How does combine get this idea (it's the only match in the
> > function)?
> >
> > Trying 7 -> 12:
> > Successfully matched thi
ff000f". That is the correct result for combining insn 6 + 7
+ 12, however. (Eventually the two "and"s with constant values
are not merged into a single "and" with a single constant.)
(dumps attached)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
;; Function andc
(This is a copy of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70078)
I'd like to clean up this documentation issue, but need some help:
Dominik Vogt 2016-03-04 11:05:16 UTC
> The section "Defining How to Split Instructions" in the gccint
> manual claims
>
> The
On Mon, Mar 07, 2016 at 03:41:37PM +0100, Dominik Vogt wrote:
> On Mon, Mar 07, 2016 at 03:18:34PM +0100, Richard Biener wrote:
> > On Mon, Mar 7, 2016 at 3:12 PM, Dominik Vogt
> > wrote:
> > > On Mon, Mar 07, 2016 at 03:00:03PM +0100, Richard Biener wrote:
> > >
On Mon, Mar 07, 2016 at 03:18:34PM +0100, Richard Biener wrote:
> On Mon, Mar 7, 2016 at 3:12 PM, Dominik Vogt wrote:
> > On Mon, Mar 07, 2016 at 03:00:03PM +0100, Richard Biener wrote:
> >> On Mon, Mar 7, 2016 at 2:12 PM, Dominik Vogt
> >> wrote:
> >> >
On Mon, Mar 07, 2016 at 03:00:03PM +0100, Richard Biener wrote:
> On Mon, Mar 7, 2016 at 2: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
--
(The compiler in PATH is "gcc (GCC) 4.8.5 20150623 (Red Hat
4.8.5-1)").
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Thu, Dec 31, 2015 at 12:42:56PM +, Jonathan Wakely wrote:
> On 31 December 2015 at 11:54, Dominik Vogt wrote:
> > Is there a requirement for a certain minimum Glibc version for
> > this to work?
>
> It doesn't work with any glibc, because it doesn't declar
On Thu, Dec 31, 2015 at 12:45:06PM +0100, Marc Glisse wrote:
> On Thu, 31 Dec 2015, Dominik Vogt wrote:
>
> >The minimal failing program is
> >
> >-- abs.C --
> >#include
> >static float (*p1_)(float) = abs;
> >-- abs.C --
>
> This is allowe
On Thu, Dec 31, 2015 at 10:11:55AM +, Jonathan Wakely wrote:
> On 31 December 2015 at 09:57, Marc Glisse wrote:
> > On Thu, 31 Dec 2015, Dominik Vogt wrote:
> >
> >> This snippet ist from the Plumhall 2014 xvs test suite:
> >>
> >> #if CXX03 || CXX1
ssive]
(Of course even with -fpermissive this won't work because (at
least on my platform) ints are passed in different registers than
floats.)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Mon, Dec 07, 2015 at 11:48:10AM -0800, Andrew Pinski wrote:
> On Mon, Dec 7, 2015 at 6:44 AM, Dominik Vogt wrote:
> > On S/390 the test case gcc.dg/loop-9.c currently fails:
> >
> > void f (double *a)
> > {
> > int i;
> > for (i = 0;
lly, the constant should be moved (from the literal pool) to
a floating point register (and actually is in the assembly
output), and that move could be moved out of the loop (it's not).
Where should I look for the root cause?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Tue, Oct 13, 2015 at 11:06:48AM -0600, Jeff Law wrote:
> On 10/13/2015 07:12 AM, Dominik Vogt wrote:
> >In some cases, the work of the cse1 pass is counterproductive, as
> >we noticed on s390x. The effect described below is present since
> >at least 4.8.0. Note tha
other targets (big
endian?). Gcc seems to do a better job optimising code for x86 in
some complicated situations, so the extra logic might pay off more
on other targets.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
(reg:DI 2 %r2)
(reg:DI 2 %r2)) /home/vogt/foo.c:5 897 {*movdi_64}
(expr_list:REG_DEAD (reg/v:DI 61 [ x ])
(nil)))
--- foo.c.196r.cse1 ---
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
foo.tgz
Description: application/gtar-compressed
>From a7fc5b13c7f0eb59e0c0d1389d031acfa
olleague next door who requested the new
functionality for use in the kernel).
To sum it up, given that we don't expect any current users, making
an incompatible change and thus avoiding the extra hassle in
favour of a clean design seemed acceptable. It would certainly be
possible to keep the interfaces compatible, but we think it is not
worth the effort.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
libffi to
work.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt wrote:
> > I'm not quite sure about the best approach. The attempt to
> > represent C unions in the "right" way is ultimately futile as Go
> > does
insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
#define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
^
../../gcc/ifcvt.c:2381:5: note: in expansion of macro ‘HAVE_cbranchcc4’
#if HAVE_cbranchcc4
^
-- snip --
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
32; } }
with the proper size, alignment and offset, but y is addressed as
".artificial_name.y" insted of just ".y", and y is a byte array
and not an int16.
I could remove the "artificial_name struct" and add padding before
and after y instead:
struct { X byte; pad_0 [3]byte; Y in
uestion is: Is it possible to turn only this one warning
into an error inside a dejagnu test? As I understand it, there
are no -W... switches for "enabled by default" options, and I
cannot use -Werror because that would break other tests in the
file.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
atch_operand:ITER2 2 ...)]
...
so that the pattern is copied only for the combinations DI-SI,
SI-HI and HI-QI, not for all nine combinations of the two
iterators? (Or is there another way to get mode of the second
argument depending on the first argument?)
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> > Given a specific VAR_DECL tree node, I need to find out whether
> > its type is built in or not. Up to now I have
> >
> > tree tn = TYP
r both,
int x;
const int x;
...
and
typedef int i_t;
i_t x;
const i_t x;
...
I need to weed out the class of VAR_DECLs that directly use built
in types.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
27 matches
Mail list logo
