Resend to gcc@gcc.gnu.org to avoid spam filter
> From: Michael Matz
> > Sent: 07 October 2018 16:53
> ...
> > I think the examples I saw from Boris were all indirect inlines:
> >
> > static inline void foo() { asm("large-looking-but-small-asm"); }
> > static void bar1() { ... foo() ... }
> >
> It's not quite obvious what SSE has to do with this - any hint please?
SSE introduced alignment constraints into the non-strict-alignment target x86
so people didn't really want to play by the rules of strict-alignment targets.
> (according to my quick check this changed between gcc-4.5 and gc
On Tue, 9 Oct 2018, Richard Biener wrote:
> >This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK
> >for every language on strict-alignment platforms. This was changed only
> >because of SSE on x86.
>
> And because we ended up ignoring all pointer casts.
It's not quite o
On October 8, 2018 11:43:00 PM GMT+02:00, Eric Botcazou
wrote:
>> That's correct, I was explaining from the middle-end perspective.
>There
>> we are consciously more lenient as we have to support the real world
>and
>> other languages than C. This is one of the cases.
>
>This had worked as Paul
On Sat, Sep 29, 2018 at 11:35 PM Notification
wrote:
>
>
--
Kind Regards,
TH
> On Oct 8, 2018, at 5:43 PM, Eric Botcazou wrote:
>
>> That's correct, I was explaining from the middle-end perspective. There
>> we are consciously more lenient as we have to support the real world and
>> other languages than C. This is one of the cases.
>
> This had worked as Paul expect
> That's correct, I was explaining from the middle-end perspective. There
> we are consciously more lenient as we have to support the real world and
> other languages than C. This is one of the cases.
This had worked as Paul expects until GCC 4.4 IIRC and this was perfectly OK
for every languag
On 10/06/2018 06:07 AM, Tejas Joshi wrote:
I have gcc source code, stage1-build and test directories as siblings
and I've been trying to compile test.c in test/ using:
../stage1-build/gcc/cc1 test.c
That isn't expected to work. You need to use the compiler driver, which
is called xgcc in the
Patch submitted:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00452.html
[C++ PATCH] Fix pretty-print of enumerator ids (PR c++/87364)
My first GCC patch attempt, so more eyes would be good.
Cheers, Will
On Tue, Sep 25, 2018 at 4:25 PM will wray wrote:
> BTW The bug is still UNCONFIRMED
> ht
Hi,
On Mon, 8 Oct 2018, Paul Koning wrote:
> > So all you'd actually have to say is
> >
> > void f1(void)
> > {
> >*i; *j;
> >__builtin_memcpy (i, j, 32);
> > }
>
> No, that doesn't help. Not even if I make it:
>
> void f1(void)
> {
> k = *i + *j;
> __builtin_memcpy (i, j, 4);
> On Oct 8, 2018, at 1:29 PM, Andrew Haley wrote:
>
> On 10/08/2018 06:20 PM, Michael Matz wrote:
>> Only if you somewhere visibly add accesses to *i and *j. Without them you
>> only have the "accesses" via memcpy, and as Richi says, those don't imply
>> any alignment requirements. The i a
Hi,
On Mon, 8 Oct 2018, Alexander Monakov wrote:
> > Only if you somewhere visibly add accesses to *i and *j. Without them
> > you only have the "accesses" via memcpy, and as Richi says, those
> > don't imply any alignment requirements. The i and j pointers might
> > validly be char* pointer
On 10/08/2018 06:20 PM, Michael Matz wrote:
> Only if you somewhere visibly add accesses to *i and *j. Without them you
> only have the "accesses" via memcpy, and as Richi says, those don't imply
> any alignment requirements. The i and j pointers might validly be char*
> pointers in disguise a
On Mon, 8 Oct 2018, Michael Matz wrote:
> > Ok, but why is that not a bug? The whole point of passing alignment to
> > the movmem pattern is to let it generate code that takes advantage of
> > the alignment. So we get a missed optimization.
>
> Only if you somewhere visibly add accesses to *i
Hi,
On Mon, 8 Oct 2018, Paul Koning wrote:
> >> extern int *i, *j;
> >> extern int iv[40], jv[40];
> >>
> >> void f1(void)
> >> {
> >>__builtin_memcpy (i, j, 32);
> >> }
> >>
> >> void f2(void)
> >> {
> >>__builtin_memcpy (iv, jv, 32);
> >> }
> >
> > Yes, memcpy doesn't require anythin
> On Oct 8, 2018, at 11:09 AM, Richard Biener
> wrote:
>
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning wrote:
>>
>> I have a movmem pattern in my target that pays attention to the alignment
>> argument.
>>
>> GCC isn't passing in the expected alignment part of the time. I have this
>> te
On Mon, Oct 8, 2018 at 3:57 PM Paul Koning wrote:
>
> I have a movmem pattern in my target that pays attention to the alignment
> argument.
>
> GCC isn't passing in the expected alignment part of the time. I have this
> test case:
>
> extern int *i, *j;
> extern int iv[40], jv[40];
>
> void f1(
I have a movmem pattern in my target that pays attention to the alignment
argument.
GCC isn't passing in the expected alignment part of the time. I have this test
case:
extern int *i, *j;
extern int iv[40], jv[40];
void f1(void)
{
__builtin_memcpy (i, j, 32);
}
void f2(void)
{
__buil
18 matches
Mail list logo
