* Linus Torvalds wrote:
> (a) the "official" rules are completely pointless, and make sense
> only because the standard is written for some random "abstract
> machine" that doesn't actually exist.
Presuming the intent of the abstract machine specification is to avoid
being seen as biased to
Am Thu, 21 May 2015 07:45:19 -0500
schrieb mark maule :
>
>
> On 5/20/2015 2:13 PM, Martin Uecker wrote:
> > mark maule :
> >> On 5/20/2015 3:27 AM, Richard Biener wrote:
> >>> On Mon, May 18, 2015 at 10:01 PM, mark maule
> >>> wrote:
> >>> The usual issue with this kind of behavior is out-o
On Thu, May 21, 2015 at 07:39:16AM -0500, Segher Boessenkool wrote:
> On Thu, May 21, 2015 at 08:06:04PM +0930, Alan Modra wrote:
> > FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
>
> It doesn't trigger on big-endian; what is different?
Register dependencies. One of the argumen
Snapshot gcc-4.8-20150521 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150521/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, May 21, 2015 at 01:42:11PM -0700, Linus Torvalds wrote:
> On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
> wrote:
> >
> > The compiler can (and does) speculate non-atomic non-volatile writes
> > in some cases, but I do not believe that it is permitted to speculate
> > either volatile or
On Thu, May 21, 2015 at 2:40 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 2:25 PM, H.J. Lu wrote:
>> On Thu, May 21, 2015 at 2:08 PM, H.J. Lu wrote:
>>> On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
On 05/20/2015 10:00 AM, H.J. Lu wrote:
> By default, alignment of DImode and DFmod
On Thu, May 21, 2015 at 2:25 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 2:08 PM, H.J. Lu wrote:
>> On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
>>> On 05/20/2015 10:00 AM, H.J. Lu wrote:
By default, alignment of DImode and DFmode is set to 8 bytes.
Intel MCU psABI specifies ali
On Thu, May 21, 2015 at 2:08 PM, H.J. Lu wrote:
> On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
>> On 05/20/2015 10:00 AM, H.J. Lu wrote:
>>> By default, alignment of DImode and DFmode is set to 8 bytes.
>>> Intel MCU psABI specifies alignment of DImode and DFmode
>>> to be 4 bytes. I'd like
On Thu, 2015-05-21 at 11:59 -0700, Richard Henderson wrote:
> On 05/21/2015 11:44 AM, Segher Boessenkool wrote:
> > On Thu, May 21, 2015 at 11:34:14AM -0700, Richard Henderson wrote:
> >> Actually, I believe that the way CA is modeled at the moment is dangerous.
> >> It's not a 64-bit value, but a
On Thu, May 21, 2015 at 1:56 PM, Jim Wilson wrote:
> On 05/20/2015 10:00 AM, H.J. Lu wrote:
>> By default, alignment of DImode and DFmode is set to 8 bytes.
>> Intel MCU psABI specifies alignment of DImode and DFmode
>> to be 4 bytes. I'd like to make get_mode_alignment to return
>> 32 bits for DI
On 05/20/2015 10:00 AM, H.J. Lu wrote:
> By default, alignment of DImode and DFmode is set to 8 bytes.
> Intel MCU psABI specifies alignment of DImode and DFmode
> to be 4 bytes. I'd like to make get_mode_alignment to return
> 32 bits for DImode and DFmode. Is there a way to adjust alignment
> of
On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney
wrote:
>
> The compiler can (and does) speculate non-atomic non-volatile writes
> in some cases, but I do not believe that it is permitted to speculate
> either volatile or atomic writes.
I do *not* believe that a compiler is ever allowed to specu
On Thu, May 21, 2015 at 02:23:47PM -0600, Jeff Law wrote:
> On 05/21/2015 01:08 PM, Vladimir Makarov wrote:
> >On 05/21/2015 05:54 AM, Ilya Enkovich wrote:
> >>>Thanks. For me it looks like an inheritance bug. It is really hard
> to fix the bug w/o the source code. Could you send me your pat
On 05/21/2015 01:08 PM, Vladimir Makarov wrote:
On 05/21/2015 05:54 AM, Ilya Enkovich wrote:
Thanks. For me it looks like an inheritance bug. It is really hard
>to fix the bug w/o the source code. Could you send me your patch in
>order I can debug RA with it to investigate more.
>
Sure! Here
On Thu, May 21, 2015 at 08:24:22PM +0100, Will Deacon wrote:
> On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote:
> > On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote:
> > > On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> > > > Indeed, something like th
On Wed, May 20, 2015 at 07:16:06PM +0100, Paul E. McKenney wrote:
> On Wed, May 20, 2015 at 04:46:17PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> > > Indeed, something like this does -not- carry a dependency from the
> > > memory_order_consume
On 05/21/2015 05:54 AM, Ilya Enkovich wrote:
Thanks. For me it looks like an inheritance bug. It is really hard
>to fix the bug w/o the source code. Could you send me your patch in
>order I can debug RA with it to investigate more.
>
Sure! Here is a patch and a testcase. I applied patch to r
On 05/21/2015 11:44 AM, Segher Boessenkool wrote:
> On Thu, May 21, 2015 at 11:34:14AM -0700, Richard Henderson wrote:
>> Actually, I believe that the way CA is modeled at the moment is dangerous.
>> It's not a 64-bit value, but a 1-bit value.
>
> It's a fixed register and it is only ever set to 0
On Thu, May 21, 2015 at 11:34:14AM -0700, Richard Henderson wrote:
> On 05/21/2015 05:39 AM, Segher Boessenkool wrote:
> >> > Trying 18, 9 -> 24:
> >> > Failed to match this instruction:
> >> > (set (reg:DI 4 4 [+8 ])
> >> > (plus:DI (plus:DI (reg:DI 5 5 [ val+8 ])
> >> > (reg:DI 76
On Thu, May 21, 2015 at 06:17:43PM +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 21 May 2015, Paul E. McKenney wrote:
>
> > The point is -exactly- to codify the current state of affairs.
>
> Ah, I see, so it's not yet about creating a more useful (for compilers,
> that is) model.
There are seve
On 05/21/2015 05:39 AM, Segher Boessenkool wrote:
>> > Trying 18, 9 -> 24:
>> > Failed to match this instruction:
>> > (set (reg:DI 4 4 [+8 ])
>> > (plus:DI (plus:DI (reg:DI 5 5 [ val+8 ])
>> > (reg:DI 76 ca))
>> > (reg:DI 169 [+8 ])))
> For some reason it has the CA reg not
Hi,
On Thu, 21 May 2015, Paul E. McKenney wrote:
> The point is -exactly- to codify the current state of affairs.
Ah, I see, so it's not yet about creating a more useful (for compilers,
that is) model.
> > char * fancy_assign (char *in) { return in; }
> > ...
> > char *x, *y;
> >
> >
On Thu, May 21, 2015 at 04:22:38PM +0200, Michael Matz wrote:
> Hi,
>
> On Wed, 20 May 2015, Paul E. McKenney wrote:
>
> > > > I'm not sure... you'd require the compiler to perform static analysis of
> > > > loops to determine the state of the machine when they exit (if they
> > > > exit!)
> > >
Hi,
On Wed, 20 May 2015, Paul E. McKenney wrote:
> > > I'm not sure... you'd require the compiler to perform static analysis of
> > > loops to determine the state of the machine when they exit (if they exit!)
> > > in order to show whether or not a dependency is carried to subsequent
> > > operat
On 5/20/2015 2:13 PM, Martin Uecker wrote:
mark maule :
On 5/20/2015 3:27 AM, Richard Biener wrote:
On Mon, May 18, 2015 at 10:01 PM, mark maule wrote:
The usual issue with this kind of behavior is out-of-bound accesses of
arrays in a loop
or invoking undefined behavior when signed integer
On Thu, May 21, 2015 at 08:06:04PM +0930, Alan Modra wrote:
> FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
> is seen on powerpc64le-linux since somewhere between revision 218587
> and 218616. See
> https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01287.html and
> https://gcc.gn
FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
is seen on powerpc64le-linux since somewhere between revision 218587
and 218616. See
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01287.html and
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01325.html
A regression hunt fing
On 20 May 23:27, Vladimir Makarov wrote:
>
>
> On 20/05/15 04:17 AM, Ilya Enkovich wrote:
> >On 19 May 11:22, Vladimir Makarov wrote:
> >>On 05/18/2015 08:13 AM, Ilya Enkovich wrote:
> >>>2015-05-06 17:18 GMT+03:00 Ilya Enkovich :
> >>>Hi Vladimir,
> >>>
> >>>Could you please comment on this?
> >
28 matches
Mail list logo
