On 9/14/2021 8:53 AM, Aldy Hernandez wrote:
On 9/14/21 4:13 PM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
typedef unsigned short uint16_t;
uint16_t a, b;
int *j_global;
uint16_t f(
On 9/14/21 4:13 PM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
typedef unsigned short uint16_t;
uint16_t a, b;
int *j_global;
uint16_t f(void)
{
int c, **p;
short d = 2, e = 4;
Hello,
On Mon, 13 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
The testcase still tests what it's supposed to test with ...
> > typedef unsigned short uint16_t;
> >
> > uint16_t a, b;
> >
> > int *j_global;
> > uint16_t f(void)
> > {
> >int c, **p;
> >short d = 2, e = 4;
> >
... "c =
On 9/13/21 4:18 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
>
>>> So it looks like there's some undefined behavior going on, even before
>>> my patch. I'd like to get some feedback, because this is usually the
>>> type of problems I see in the presence
On 9/13/2021 8:18 AM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
So it looks like there's some undefined behavior going on, even before
my patch. I'd like to get some feedback, because this is usually the
type of problems I see in the presence of a smar
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
> > So it looks like there's some undefined behavior going on, even before
> > my patch. I'd like to get some feedback, because this is usually the
> > type of problems I see in the presence of a smarter threader... things
> > get shuff
On 9/13/2021 7:29 AM, Aldy Hernandez wrote:
Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86
Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86 with -Wall yields:
$ gcc -c -O2 pr55107.c -Wall
This change:
985b3a6837dee7001e6b618f073ed74f0edf5787 is the first bad commit
commit 985b3a6837dee7001e6b618f073ed74f0edf5787
Author: H.J. Lu
Date: Mon Jun 10 09:57:15 2019 -0700
Generate offset adjusted operation for op_by_pieces operations
Add an overlap_op_by_pieces_p target hook
