On Oct 8, 2012, at 5:17 PM, Andrew Haley wrote:
> On 10/06/2012 11:59 AM, _ wrote:
>> Not that I think that STL/Boost are not great solutions for many
>> problems out there.
>> But the fact is that there is and always will be c/c++ code that can't
>> and will not use it.
>
> But surely the set
+ lots of people and linux-toolchains
On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> Hello!
>
> I was looking at the recent linux patch series [1] where segment
> qualifiers (named address spaces) were introduced to handle percpu
> variables. In the patch [2], the author mention
On Mon, Nov 09, 2020 at 01:38:51PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> >
> > + lots of people and linux-toolchains
> >
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > > Hell
On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> wrote:
> >
> > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > >
> > > + lots of people and linux-toolchains
> >
On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> When I think of qualifiers, I think of const and volatile. I'm not
> sure why the first post I'm cc'ed on talks about "segment" qualifiers.
> Maybe it's in reference to a variable attribute that the kernel
> defines? Looking at
fiers. The syntax as proposed above seems
very error prone to me.
---
Subject: compiler: Improve __unqual_typeof()
Improve our __unqual_scalar_typeof() implementation by relying on C
dropping qualifiers for lvalue convesions. There is one small catch in
that GCC is currently known broken in this re
On Mon, Nov 16, 2020 at 12:10:56PM +0100, Peter Zijlstra wrote:
> > > Another way to drop qualifiers is using a cast. So you
> > > can use typeof twice:
> > >
> > > typeof((typeof(_var))_var) tmp__;
> > >
> > > This also works for non-scal
On Mon, Nov 16, 2020 at 12:23:17PM +, Uecker, Martin wrote:
> > > > Another way to drop qualifiers is using a cast. So you
> > > > can use typeof twice:
> > > >
> > > > typeof((typeof(_var))_var) tmp__;
> > > >
> > > > This also works for non-scalars but this is a GCC extension.
>
> (That c
7;t have anything to do with those specifically.
>
> I'm dumping a bunch of info here largely for posterity / archival, and to find
> out who (from the kernel side) is willing and able to test proposed compiler
> fixes, once those are available.
>
> I'm happy to do so for aarch64; Peter, I assume you'd be happy to look at the
> x86 side?
Sure..
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> int x = 0;
> int y = 0;
> int r0, r1;
>
> int dummy;
>
> void t0(void)
> {
> __atomic_store_n(&x, 1, __ATOMIC_RELAXED);
>
> __atomic_exchange_n(&dummy, 1, __ATOMIC_SEQ_CST);
> __atomic_thre
On Fri, Jul 07, 2023 at 10:04:06AM -0400, Olivier Dion wrote:
> On Tue, 04 Jul 2023, Peter Zijlstra wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> [...]
> >> On x86-64 (gcc 13.1 -O2) we get:
> >>
> >> t0():
> >>
On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
> Hopefully some discussion of out-of-thin-air values as well.
Yes, absolutely shoot store speculation in the head already. Then drive
a wooden stake through its hart.
C11/C++11 should not be allowed to claim itself a memory model
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
> Understood, but that doesn't explain why Paul wants to add ISB/isync
> instructions which affect the *CPU* rather than the compiler!
I doubt Paul wants it, but yeah, I'm curious about that proposal as
well, sounds like someone took a b
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
> Hi Paul,
>
> On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
> > On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
> > > On Thu, Feb 06, 2014 at 08:20:51PM -0800
achine wouldn't do. This is different to the sequential
> code that Peter posted because it uses atomics, and thus one can't
> easily assume that the difference is not observable.
Yeah, my bad for not being familiar with the atrocious crap C11 made of
atomics :/
On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
> As near as I can tell, compiler writers hate the idea of prohibiting
> speculative-store optimizations because it requires them to introduce
> both control and data dependency tracking into their compilers. Many of
> them seem to
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote:
> On Mon, Feb 10, 2014 at 11:48:13AM +0000, Peter Zijlstra wrote:
> > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
> > > As near as I can tell, compiler writers hate the idea of prohibiting
>
> I don't know the specifics of your example, but from how I understand
> it, I don't see a problem if the compiler can prove that the store will
> always happen.
>
> To be more specific, if the compiler can prove that the store will
> happen anyway, and the region of code can be assumed to always
On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote:
> You need volatile semantics to force the compiler to ignore any proofs
> it might otherwise attempt to construct. Hence all the ACCESS_ONCE()
> calls in my email to Torvald. (Hopefully I translated your example
> reasonably.)
My
On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
> That depends on what your goal is.
A compiler that we don't need to fight in order to generate sane code
would be nice. But as Linus said; we can continue to ignore you lot and
go on as we've done.
e - perhaps Torvald could comment?
For more context, this example is taken from a summary of the thin-air
problem by Mark Batty and myself,
, and the problem with
dependencies via other compilation units was AFAIK first pointed out
by Hans Boehm.
Peter
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
> Several of you have said that the standard and compiler should not
> permit speculative writes of atomics, or (effectively) that the
> compiler should preserve dependencies.
The example below only deals with control depende
Hi Paul,
On 18 February 2014 14:56, Paul E. McKenney wrote:
> On Tue, Feb 18, 2014 at 12:12:06PM +0000, Peter Sewell wrote:
>> Several of you have said that the standard and compiler should not
>> permit speculative writes of atomics, or (effectively) that the
>> com
On 18 February 2014 12:53, Peter Zijlstra wrote:
> On Tue, Feb 18, 2014 at 12:12:06PM +0000, Peter Sewell wrote:
>> Several of you have said that the standard and compiler should not
>> permit speculative writes of atomics, or (effectively) that the
>> compiler should
On 18 February 2014 17:38, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell
> wrote:
>>
>> For example, suppose we have, in one compilation unit:
>>
>> void f(int ra, int*rb) {
>> if (ra==42)
>> *rb=42;
>>
d based on BPF: https://lwn.net/Articles/437981/
>
> And probably other stuff as well.
interesting list. So are you saying that value-range-analysis and
such-like (I say glibly, without really knowing what "such-like"
refers to here) are fundamentally incompatible with
the kern
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> Well, that's how atomics that aren't volatile are defined in the
> standard. I can see that you want something else too, but that doesn't
> mean that the other thing is broken.
Well that other thing depends on being able to see the
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
> Yes, I do. But that seems to be "volatile" territory. It crosses the
> boundaries of the abstract machine, and thus is input/output. Which
> fraction of your atomic accesses can read values produced by hardware?
> I would still su
> > 4. Some drivers allow user-mode code to mmap() some of their
> > state. Any changes undertaken by the user-mode code would
> > be invisible to the compiler.
>
> A good point, but a compiler that doesn't try to (incorrectly) assume
> something about the semantics of mmap will simply s
On 18 February 2014 20:43, Torvald Riegel wrote:
> On Tue, 2014-02-18 at 12:12 +0000, Peter Sewell wrote:
>> Several of you have said that the standard and compiler should not
>> permit speculative writes of atomics, or (effectively) that the
>> compiler should preserve dep
On Wed, Feb 19, 2014 at 12:07:02PM +0100, Torvald Riegel wrote:
> > Its not only hardware; also the kernel/user boundary has this same
> > problem. We cannot a-priory say what userspace will do; in fact, because
> > we're a general purpose OS, we must assume it will willfully try its
> > bestest to
On 21 February 2014 19:41, Linus Torvalds wrote:
> On Fri, Feb 21, 2014 at 11:16 AM, Linus Torvalds
> wrote:
>>
>> Why would this be any different, especially since it's easy to
>> understand both for a human and a compiler?
>
> Btw, the actual data path may actually be semantically meaningful ev
ut them will be maintained at the
source level).
The C11 syntactic notion of dependency, whatever its faults, was at
least precise, could be reasoned about locally (just looking at the
syntactic code in question)
On 1 March 2014 08:03, Paul E. McKenney wrote:
> On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
>> Hi Paul,
>>
>> On 28 February 2014 18:50, Paul E. McKenney
>> wrote:
>> > On Thu, Feb 27, 2014 at 12:53:12PM -0800, Paul E. McKenney wrote:
>
On 2 March 2014 23:20, Paul E. McKenney wrote:
> On Sun, Mar 02, 2014 at 04:05:52AM -0600, Peter Sewell wrote:
>> On 1 March 2014 08:03, Paul E. McKenney wrote:
>> > On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
>> >> Hi Paul,
>> >&g
On 3 March 2014 20:44, Torvald Riegel wrote:
> On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
>> On 1 March 2014 08:03, Paul E. McKenney wrote:
>> > On Sat, Mar 01, 2014 at 04:06:34AM -0600, Peter Sewell wrote:
>> >> Hi Paul,
>> >>
>>
On 5 March 2014 17:15, Torvald Riegel wrote:
> On Tue, 2014-03-04 at 22:11 +0000, Peter Sewell wrote:
>> On 3 March 2014 20:44, Torvald Riegel wrote:
>> > On Sun, 2014-03-02 at 04:05 -0600, Peter Sewell wrote:
>> >> On 1 March 2014 08:03, Paul E. McKenney
>&
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC)
peter@peter-lap ~/src/test/obj_vs_ptr
$ cat ./t
#!/bin/bash
cat $1.c && gcc -std=c99 -O0 -g -o $1 $1.c &&
Hi David,
Sorry, I had included more information in an earlier draft which I
edited out for brevity.
> You cannot learn useful timing
> information from a single run of a short
> test like this - there are far too many
> other factors that come into play.
I didn't mention that I have run it d
In order to see what difference a different processor makes I also tried
the same code on a fairly old 32 bit "AMD Athlon(tm) XP 3000+" with the
current stable gcc (4.7.2). The difference is even more striking
(dereferencing is much faster). I see that the size of the code inside
the loop for t
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
> +# Tell gcc to never replace conditional load with a non-conditional one
> +KBUILD_CFLAGS+= $(call cc-option,--param allow-store-data-races=0)
> +
Why do we not want: -fmemory-model=safe? And should we not at the very
least als
On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
> On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
> > > +# Tell gcc to never replace conditional load with a non-conditional one
&g
On 12 October 2014 16:32, Chen Gang wrote:
> Hello All:
>
> I found an issue about g++, it is OK for "-Wall -O0", but will report
> -Wunused-variable for "-Wall -O1|2|3|s". The original version (e.g.
> gcc 4.8.3 redhat version) does not report warning for "-Wall -O?".
>
> The related operation:
>
ath/to/gcc/source/directory/configure
Peter
ts work on compiler testing (by Zappa Nardelli, Morisset, and
Pawan).
many thanks,
Kayvan Memarian and Peter Sewell
On 17 April 2015 at 15:19, wrote:
>
>> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote:
>>
>> Dear gcc list,
>>
>> we are trying to clarify what behaviour of C implementations is
>> actually relied upon in modern practice, and what behaviour
On 17 April 2015 at 17:03, wrote:
> On 04/17/2015 09:01 AM, Peter Sewell wrote:
>>
>> On 17 April 2015 at 15:19, wrote:
>>>
>>>
>>>> On Apr 17, 2015, at 9:14 AM, Peter Sewell
>>>> wrote:
>>>>
>>>> Dear gc
a; we have more responses from Clang and
OS kernel developers). The survey is here:
http://goo.gl/iFhYIr
It consists of 15 short questions about the sequential behaviour of C
memory and pointers.
thanks,
Peter
On 25 April 2015 at 22:42, Joseph Myers wrote:
> On Fri, 17 Apr 2015, Peter Sewe
On 5 June 2015 at 16:55, Paolo Bonzini wrote:
> The GCC manual says "GCC does not use the latitude given in C99 and C11
> only to treat certain aspects of signed '<<' as undefined, but this is
> subject to change". It would certainly be nice if they removed the
> "this is subject to change" part.
ther below or by mailing the
Cerberus mailing list:
cl-cerbe...@lists.cam.ac.uk
https://lists.cam.ac.uk/mailman/listinfo/cl-cerberus
many thanks,
Kayvan Memarian and Peter Sewell (University of Cambridge)
What is C in practice? (Cerberus survey): C
On 26 June 2015 at 18:08, Joseph Myers wrote:
> On Fri, 26 Jun 2015, Peter Sewell wrote:
>
>> **If you calculate an offset between two separately allocated C memory
>> objects (e.g. malloc'd regions or global or local variables) by
>> pointer subtraction, can you
On 26 June 2015 at 20:27, Joseph Myers wrote:
> On Fri, 26 Jun 2015, Peter Sewell wrote:
>
>> > It's s simple matter of points-to analysis. &foo + anything may be
>> > assumed (in practice) to point to something within foo (or just past the
>> > end) an
ack, thanks - in that case, it's a nice example, but not really
relevant to what we're asking about
Peter
On 30 June 2015 at 00:21, Andreas Hollmann wrote:
> Sorry for my first misleading email. The code needs disabled
> optimizations to ensure that the execution time is
If we move to git (I'm all for
it), I would hope that those can remain in the official source code
repository.
That said, if the GCC project created an "official" side repository
where branches are stored, we could participate in that.
Peter
On Wed, 2015-08-26 at 16:35 -0400, Eric S. Raymond wrote:
> Joseph Myers :
> > > irar = irar
> >
> > Ira Rosen
>
> I pretty much knew these two guys went with these two names, but couldn't
> figure out which was which. Thanks.
Actually, Ira Rosen is a "she" and not a "he".
Peter
On Wed, 2015-08-26 at 13:44 -0700, Ian Lance Taylor wrote:
> On Wed, Aug 26, 2015 at 12:31 PM, Eric S. Raymond wrote:
> > click = click
>
> You've got me on that one. Any hints?
Just purely looking at the name, did Cliff Click ever
contribute to gcc in the past?
Peter
On Wed, 2015-08-26 at 18:55 -0500, Peter Bergner wrote:
> On Wed, 2015-08-26 at 16:35 -0400, Eric S. Raymond wrote:
> > Joseph Myers :
> > > > irar = irar
> > >
> > > Ira Rosen
> >
> > I pretty much knew these two guys went with these two
On Wed, 2015-08-26 at 20:12 -0400, Eric S. Raymond wrote:
> Peter Bergner :
> > On Wed, 2015-08-26 at 16:35 -0400, Eric S. Raymond wrote:
> > > Joseph Myers :
> > > > > irar = irar
> > > >
> > > > Ira Rosen
> > >
> > >
> these to emails yet.
> acsawdey
Aaron Sawdey / acsaw...@linux.vnet.ibm.com
> bergner
Peter Bergner / berg...@vnet.ibm.com
> boger
Lynn Boger ? labo...@linux.vnet.ibm.com
> pthaugen
Pat Haugen / pthau...@linux.vnet.ibm.com
> revitale
Revital Eres / e...@il.ibm.c
he hooks directory.
>From your list, I also see that alanm and amodra are both listed with
Alan's old bigpond.net.au address which no longer exists. He now uses:
amo...@gmail.com
Peter
golovanevsky.o...@gmail.com
> spop = Sebastian Pop
Sebastian is now at Samsung and his address is:
s@samsung.com
Peter
On Fri, 2015-08-28 at 11:00 -0400, Eric S. Raymond wrote:
> Peter Bergner :
> > On Thu, 2015-08-27 at 10:38 -0400, Eric S. Raymond wrote:
> > > I've made it available at:
> > >
> > > http://thyrsus.com/gitweb/?p=gcc-conversion.git
> > >
> &g
;t appear in this table?
Probably because that category is only implemented on some (one?) cpus
(eg, E6500) and not on any of the server cpus (eg, power[45678]), so no
one cared enough to add that info? :-) It would probably be useful to
add though.
Peter
those
> flags for some of the compilation steps.
>
> I was only successful after I manually edited the makefile to replace
> "-g" with "-g3".
Try CFLAGS_FOR_TARGET='-O0 -g3 -fno-inline' and CXXFLAGS_FOR_TARGET='-O0 -g3
-fno-inline'
Peter
eduling itself of course).
We've been underwhelmed with the RTL unroller on POWER and I think
we concur that a GIMPLE level unroller would be interesting.
Peter
Hi,
I am interested in having a link on your website much like others have on your
site here;
http://www.cbloom.com/poker/beginners.html
If there is a cost, please could you let me know how much it is for a permanent
link?
Many Thanks,
Peter Hill
evision? Does it work
before my
revision 264897 commit and broken after? If so, could you try the following to
see
whether that fixes things for you?
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html
My commit above exposed some latent LRA bugs and my patch above tries
to fix issues similar to what you're seeing.
Peter
On 11/1/18 8:40 PM, Segher Boessenkool wrote:
> Hi Peter,
>
> On Thu, Nov 01, 2018 at 07:49:36PM -0500, Peter Bergner wrote:
>> On 11/1/18 7:25 PM, Paul Koning wrote:
>>> I'm running the testsuite on the pdp11 target, and I get a failure when
>>> using
ed the rs6000 (ie, ppc*) port over to LRA
from reload, we hit many target problems. It seems LRA is much less
forgiving to bad constraints, predicates, etc. than reload was.
I think that's actually a good thing.
Peter
ry has this covered, but in the TCB, we
> only have zeroed-out reservations today.
We have non-zero initialized TCB entries on powerpc*-linux which are used
for the GCC __builtin_cpu_is() and __builtin_cpu_supports() builtin
functions. Tulio would know the magic that was used to get them setup.
Peter
; input and tries to spill it, but
it's not a pseudo, but an explicit hard register already. I'm not
sure LRA can really safely spill an operand that is an explicit hard
register.
Thoughts?
Peter
On 2/19/19 9:09 PM, Alan Modra wrote:
> On Mon, Feb 18, 2019 at 01:13:31PM -0600, Peter Bergner wrote:
>> long input;
>> long
>> bug (void)
>> {
>> register long output asm ("r3");
>> asm ("blah %0, %1, %2" : "=&r" (outp
spilling a hard register in the case where we used asm reg("...").
Peter
On 2/20/19 4:04 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 10:08:07AM -0600, Peter Bergner wrote:
>> On 2/19/19 9:09 PM, Alan Modra wrote:
>> That said, talking with Segher and Uli offline, they both think the
>> inline asm usage in the test case should be legal
>
&g
On 2/20/19 9:39 PM, Alan Modra wrote:
> On Wed, Feb 20, 2019 at 08:57:52PM -0600, Peter Bergner wrote:
>> Yes, because they don't have my IRA and LRA patches that exposed this
>> problem. I would say they were buggy for not complaining and silently
>> spilling a hard reg
Zdravím,
Obsah této posty je velmi duverný a legální. Jmenuji se Peter Wong, pracuji s
bankou tady v Hong Kongu. Rozhodl jsem se vás kontaktovat pro moznost
investovat do lukrativního podnikání ve va?í zemi. Jsem ochoten Vám nabídnout
40% investicního zisku jako muj obchodní partner.
Nase
d especially like to know whether
it would be feasible to implement - our hope is that it would only require
minor changes. It's presented in three documents:
N2362 Moving to a provenance-aware memory model for C: proposal for C2x
by the memory object model study group. Jens Gustedt, Pete
and let the old ones refer to the description like it is
today.
Best Regards,
Peter
A big fan
On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
>
> On 4/2/19 2:11 AM, Peter Sewell wrote:
> > Dear all,
> >
> > continuing the discussion from the 2018 GNU Tools Cauldron, we
> > (the WG14 C memory object model study group) now
> > have a detailed propo
On 17/04/2019, Richard Biener wrote:
> On Fri, Apr 12, 2019 at 5:31 PM Peter Sewell
> wrote:
>>
>> On Fri, 12 Apr 2019 at 15:51, Jeff Law wrote:
>> >
>> > On 4/2/19 2:11 AM, Peter Sewell wrote:
>> > > Dear all,
>> > >
>>
On Wed, 17 Apr 2019 at 15:12, Uecker, Martin
wrote:
>
> Am Mittwoch, den 17.04.2019, 15:34 +0200 schrieb Richard Biener:
> > On Wed, Apr 17, 2019 at 2:56 PM Uecker, Martin
> > wrote:
> > >
> > > Am Mittwoch, den 17.04.2019, 14:41 +0200 schrieb Richard Biener:
> > > > On Wed, Apr 17, 2019 at 1:53
n would be to not track
> provenance through non-pointers and make
> conversions of non-pointers to pointers have
> "anything" provenance.
>
> The additional issue that appears here though
> is that we cannot even turn (int *)(uintptr_t)p
> into p anymore since with the conditional
> substitution we can then still arrive at
> effectively (&y)[-1] = 1 which is of course
> undefined behavior.
>
> That is, your proposal makes
>
> ((int *)(uintptr_t)&y)[-1] = 1
>
> well-defined (if &y - 1 == &x) but keeps
>
> (&y)[-1] = 1
>
> as undefined
that's true (if x has been exposed).
>which strikes me as a little bit
> inconsistent. If that's true it's IMHO worth
> a defect report and second consideration.
There's a trade-off here. We could permit roundtrips
of pointer-to-integer-to-pointer only recover provenance
if the pointer is properly within the object, giving empty
provenance for a one-past pointer. That would fix the
above, but it's not clear whether this would be a bad
restriction for existing code.
best,
Peter
> Richard.
>
> > Best,
> > Martin
quot; provenance.
> >
> > The additional issue that appears here though
> > is that we cannot even turn (int *)(uintptr_t)p
> > into p anymore since with the conditional
> > substitution we can then still arrive at
> > effectively (&y)[-1] = 1 which is of course
> > undefined behavior.
> >
> > That is, your proposal makes
> >
> > ((int *)(uintptr_t)&y)[-1] = 1
> >
> > well-defined (if &y - 1 == &x) but keeps
> >
> > (&y)[-1] = 1
> >
> > as undefined which strikes me as a little bit
> > inconsistent. If that's true it's IMHO worth
> > a defect report and second consideration.
>
> Similarly that
>
> int x;
> int y;
> uintptr_t pj = (uintptr_t)&y;
>
> if (&x + 1 == &y) {
>
>int* p = (int*)pj; // can be one-after pointer of 'x'
>p[-1] = 1; // well defined?
> }
>
> is undefined but when I add a no-op
>
> (uintptr_t)&x;
>
> it is well-defined is undesirable. Can this no-op
> stmt appear in another function? Or even in
> another translation unit (if x and y are global variables)?
> And does such stmt have to be present (in another
> TU) to make the example valid in this case?
yes to all that - again, in the variant in which
roundtrips of a one-past pointer are supported.
> To me all this makes requiring exposal through a cast
> to a non-pointer (or accessing its representation) not
> in any way more "useful" for an optimizing compiler than
> modeling exposal through address-taking.
interesting, thanks
best,
Peter
> Richard.
>
> > Richard.
> >
> > > Best,
> > > Martin
On Thu, 18 Apr 2019 at 14:54, Uecker, Martin
wrote:
>
> Am Donnerstag, den 18.04.2019, 07:42 -0600 schrieb Jeff Law:
> > On 4/18/19 6:20 AM, Uecker, Martin wrote:
> > > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
> > > > On Thu, 18
d objects are
> involved.
A possible compromise position might be to make it implementation-defined
whether round-trip casts of a one-past pointer into integer and back preserve
provenance. I don't know whether that corner case crops up in real code...
best,
Peter
On 19/04/2019, Jens Gustedt wrote:
> Hello Peter,
>
> On Fri, 19 Apr 2019 10:11:43 +0100 Peter Sewell
> wrote:
>
>> On 19/04/2019, Jakub Jelinek wrote:
>> > On Fri, Apr 19, 2019 at 10:19:28AM +0200, Jens Gustedt wrote:
>> [...]
>
>> > That pen
On 24/04/2019, Jeff Law wrote:
> On 4/24/19 4:19 AM, Richard Biener wrote:
>> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
>>>
>>> On 4/18/19 6:20 AM, Uecker, Martin wrote:
>>>> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell:
>>>
On 25/04/2019, Richard Biener wrote:
> On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell
> wrote:
>>
>> On 24/04/2019, Jeff Law wrote:
>> > On 4/24/19 4:19 AM, Richard Biener wrote:
>> >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote:
>> >&g
On 25/04/2019, Richard Biener wrote:
> On Thu, Apr 25, 2019 at 3:03 PM Peter Sewell
> wrote:
>>
>> On 25/04/2019, Richard Biener wrote:
>> > On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell
>> >
>> > wrote:
>> >>
>> >> On 24
//gcc.gnu.org/ml/gcc-patches/2019-09/msg01256.html
Peter
Hi
You could have the last payment in your personal account. You need to address
this instantly or it will be deleted.
Go Here To Verify Your Payment Data Is Correct.
Customer email: g...@gnu.org
User ID: TQNLMFJOC9
Enjoy & please let me know how you do.
Thank you!
Cortez
E Market
essing I'm not the only one who would like this info, so maybe
someone can add this to our wiki?
Peter
te.html a few days ago now also removed svn.html.
The rsync.html page can be removed too, since that was a way to download
the entire svn repo. With git clone, you get the entire repo, so rsync
isn't needed anymore.
Peter
e releases/gcc-9" into our branch and I'm not
seeing any From-SVN: in any of the commit messages. Where/how are
you seeing those?
Peter
On 1/23/20 12:09 PM, Peter Bergner wrote:
> On 1/23/20 4:29 AM, Jakub Jelinek wrote:
>> so it is not a fast forward merge and we have the requirement that
>> From-SVN: shouldn't appear in commit logs of new commits.
>
> So I just did "git merge releases/gcc-9"
On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote:
> Its fine to focus on userspace first, but the kernel is far more simple.
>
> Looking at that presentation, the only thing missing for kernel is the
> notrack thunks, in the unlikely case that such code would be tolerated
> (Frankly,
grind was going to use all of the time,
because actually implementing the HTM instructions was too hard.
Peter
On 2/14/17 6:06 PM, Alan Modra wrote:
Since we've been talking about obsoleting cpu support, how about
getting rid of -many in ASM_CPU_SPEC for gcc-8?
+1
Peter
by businesses in your market sector.
Once adapted by us to suit the needs of your Company, our Terms and Conditions
will provide comprehensive coverage for all of your business activities.
Please let me know if you would like further details.
Kind regards,
Peter Brown
Click this
.
I was very grateful that Preston was more than willing to answer all my many
questions regarding his allocator and the many many details he couldn't
mention in his Ph.D. thesis, let alone a short paper.
Peter
1 - 100 of 819 matches
Mail list logo
