James Lemke codesourcery.com> writes:
> I have completed the binutils submission for VLE.
> I am working on the gcc submission. The test results are looking good
> now. Patches will be posted very soon.
Do you have any update on the work on VLE-support?
Thanks for any feed
On Fri, Jan 08, 2016 at 02:36:32PM +0900, AKASHI Takahiro wrote:
> On 01/07/2016 11:56 PM, Richard Earnshaw (lists) wrote:
> >On 07/01/16 14:22, Will Deacon wrote:
> >>On Thu, Dec 24, 2015 at 04:57:54PM +0900, AKASHI Takahiro wrote:
> >>>So I'd like to introd
On Tue, Jan 12, 2016 at 03:11:29PM +0900, AKASHI Takahiro wrote:
> Will,
>
> On 01/09/2016 12:53 AM, Will Deacon wrote:
> >On Fri, Jan 08, 2016 at 02:36:32PM +0900, AKASHI Takahiro wrote:
> >>On 01/07/2016 11:56 PM, Richard Earnshaw (lists) wrote:
> >>>
On Wed, Jan 13, 2016 at 05:13:29PM +0900, AKASHI Takahiro wrote:
> On 01/13/2016 03:04 AM, Will Deacon wrote:
> >On Tue, Jan 12, 2016 at 03:11:29PM +0900, AKASHI Takahiro wrote:
> >>On 01/09/2016 12:53 AM, Will Deacon wrote:
> >>>I still don't understand why
Hello everyone!
My name is Will Hawkins and I am a longtime user of gcc and admirer of
the project. I hope that this is the proper forum for the question I
am going to ask. If it isn't, please accept my apology and ignore me.
I am a real geek and I love the history behind open source pro
On Wed, Oct 26, 2016 at 9:07 AM, Ian Lance Taylor wrote:
> On Tue, Oct 25, 2016 at 10:53 PM, Will Hawkins wrote:
>>
>> My name is Will Hawkins and I am a longtime user of gcc and admirer of
>> the project. I hope that this is the proper forum for the question I
>> a
On Wed, Oct 26, 2016 at 11:55 AM, Jeff Law wrote:
> On 10/26/2016 07:07 AM, Ian Lance Taylor wrote:
>>
>> On Tue, Oct 25, 2016 at 10:53 PM, Will Hawkins wrote:
>>>
>>>
>>> My name is Will Hawkins and I am a longtime user of gcc and admirer of
>>>
elop.html#timeline
> For questions like who has added feature XYZ, the best source is just the
> source repository's history or ChangeLog files.
>
> Jakub
Jakub, Marek,
Great suggestions! In fact, I had just thought of the same thing!
Thanks for your response!
Will
On Wed, Oct 26, 2016 at 1:15 PM, Ian Lance Taylor wrote:
> On Wed, Oct 26, 2016 at 9:31 AM, Will Hawkins wrote:
>>
>> Thank you for your response! I don't think that there has to be
>> controversy to be interesting. Obviously that split/reunification was
>> i
omplete to provide commercial support for
> the Ada compiler. The members of that NYU project were the initial
> team at AdaCore.
Such great information, Richard! Thanks so much!
Will
On Wed, Oct 26, 2016 at 2:23 PM, Eric Gallager wrote:
> On 10/26/16, Ian Lance Taylor wrote:
>> On Wed, Oct 26, 2016 at 9:31 AM, Will Hawkins wrote:
>>>
>>> Thank you for your response! I don't think that there has to be
>>> controversy to be interestin
m to be natural.
>
> Works for me! I added the following bullet to the list of things
> that break dependencies:
>
> If a pointer is part of a dependency chain, and if the values
> added to or subtracted from that pointer cancel the pointer
> value so as to
On Wed, May 20, 2015 at 01:15:22PM +0100, Paul E. McKenney wrote:
> On Wed, May 20, 2015 at 12:47:45PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 03:41:48AM +0100, Paul E. McKenney wrote:
> > > If a pointer is part of a dependency chain, and if the values
&
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
> >
Hi Paul,
On Thu, May 21, 2015 at 09:02:12PM +0100, Paul E. McKenney wrote:
> 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 to #5:
> > >
> > > r1 = atomic_lo
d to closely follow
(GNU) C and C++ grammars... */
I'd appreciate any recommendations towards a proper fix,
or pointers for how to write unit tests for the fix.
Thanks, Will
'prototype' in mid 2003,
untouched since then, not for C++11 or C++17 enum updates.
I found this corner of the code base fairly easy to hack,
thanks perhaps to GDRs attempts to follow the grammar.
On Mon, Sep 24, 2018 at 3:53 PM Nathan Sidwell wrote:
> On 9/19/18 7:41 AM, will wray
#x27;d appreciate if someone would confirm the bug.
Thanks, Will
On Mon, Sep 24, 2018 at 5:23 PM will wray wrote:
> Thanks Nathan,
>
>
> In fact, after testing with enums nested in namespaces or structs,
>
> or function local, I realised nested specifiers should be printed
&
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 UNCONFIR
ogize if I just
needed to RTFM better.
Thanks in advance for any responses!
Will
On Tue, May 16, 2017 at 2:33 PM, Jeff Law wrote:
> On 05/16/2017 12:24 PM, Will Hawkins wrote:
>> Hello everyone!
>>
>> I apologize if this is not the right venue to ask this question and/or
>> this is a waste of your time.
>>
>> I was just wondering if ther
On Tue, May 16, 2017 at 2:45 PM, David Malcolm wrote:
> On Tue, 2017-05-16 at 14:24 -0400, Will Hawkins wrote:
>> Hello everyone!
>>
>> I apologize if this is not the right venue to ask this question
>> and/or
>> this is a waste of your time.
>>
>>
As I started looking into this, it seems like PLUGIN_FINISH is where
my plugin will go. Everything is great so far. However, when plugins
at that event are invoked, they get no data. That means I will have to
look into global structures for information regarding the compilation.
Are there pointers
On Wed, May 17, 2017 at 1:02 PM, Jeff Law wrote:
> On 05/17/2017 10:36 AM, Will Hawkins wrote:
>> As I started looking into this, it seems like PLUGIN_FINISH is where
>> my plugin will go. Everything is great so far. However, when plugins
>> at that event are invoked, they ge
On Wed, May 17, 2017 at 1:04 PM, Will Hawkins wrote:
> On Wed, May 17, 2017 at 1:02 PM, Jeff Law wrote:
>> On 05/17/2017 10:36 AM, Will Hawkins wrote:
>>> As I started looking into this, it seems like PLUGIN_FINISH is where
>>> my plugin will go. Everything is great so
On Wed, May 17, 2017 at 2:41 PM, Will Hawkins wrote:
> On Wed, May 17, 2017 at 1:04 PM, Will Hawkins wrote:
>> On Wed, May 17, 2017 at 1:02 PM, Jeff Law wrote:
>>> On 05/17/2017 10:36 AM, Will Hawkins wrote:
>>>> As I started looking into this, it seems like
On Wed, May 17, 2017 at 2:59 PM, Will Hawkins wrote:
> On Wed, May 17, 2017 at 2:41 PM, Will Hawkins wrote:
>> On Wed, May 17, 2017 at 1:04 PM, Will Hawkins wrote:
>>> On Wed, May 17, 2017 at 1:02 PM, Jeff Law wrote:
>>>> On 05/17/2017 10:36 AM, Will Hawkins wro
On Fri, May 19, 2017 at 4:40 PM, Jeff Law wrote:
> On 05/17/2017 08:22 PM, Will Hawkins wrote:
>> On Wed, May 17, 2017 at 2:59 PM, Will Hawkins wrote:
>>> On Wed, May 17, 2017 at 2:41 PM, Will Hawkins wrote:
>>>> On Wed, May 17, 2017 at 1:04 PM, Will Hawkins wro
source with information about how to build/run:
https://github.com/whh8b/bb_stats
If you are interested in more information, just send me an email.
Thanks again for everyone's help!
Will
On Sat, May 20, 2017 at 11:29 PM, Will Hawkins wrote:
> On Fri, May 19, 2017 at 4:40 PM, Jeff Law wrot
p://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoline-20171219
I'd love to hear what other people have heard!
Will
Thanks to your brand new Bugzilla account, you may now comment! :-)
You will receive instructions on how to reset your default default
password and access your account. Please let me know if you have any
questions or trouble gaining access.
I'd be happy to help in any way that I can!
T
can understand how to implement
efficiently behind an uncomplicated interface. I don't think that interface is
C11.
Just my thoughts on the matter...
Will
#x27;s
> a fairly weak memory model (unless you go for the "only seq-cst"
> beginners advice) and thus comes with a higher complexity, this model is
> what likely most people will be familiar with over time. Deviating from
> the "standard" model can have valid reasons,
On Fri, Feb 07, 2014 at 05:06:54PM +, Peter Zijlstra wrote:
> On Fri, Feb 07, 2014 at 04:55:48PM +0000, 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, Pe
7;t permit speculative stores
in the ARM architecture, so it seems counter-intuitive that GCC needs to
emit any additional instructions to prevent that from happening.
Stores can, of course, be observed out-of-order but that's a lot more
reasonable :)
Will
onsume, the long
> > and successful use of idioms based on the memory_order_consume pattern
> > notwithstanding [*]. ;-)
>
> Just tell them that because the hardware provides control dependencies
> we actually use and rely on them.
s/control/address/ ?
Will
On Mon, Feb 10, 2014 at 03:04:43PM +, Paul E. McKenney wrote:
> On Mon, Feb 10, 2014 at 11:49:29AM +0000, Will Deacon wrote:
> > On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote:
> > > On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
> > &
Further, instructions are issued as necessary to prevent the
processor from speculating loads across the operation and from queuing stores
after the operation.'
which is stronger than simply mapping them to memory_model_seq_cst, which
seems to be what the AArch64 compiler is doing (so you get acquire + release
instead of a full fence).
Will
ettimeofday.o = -O2 -mcmodel=tiny -fasynchronous-unwind-tables \
> + $(DISABLE_STACKLEAK_PLUGIN)
I can pick this one up via arm64, thanks. Are there any other plugins we
should be wary of? It looks like x86 filters out $(GCC_PLUGINS_CFLAGS)
when building the vDSO.
Will
On Tue, Jun 09, 2020 at 12:09:27PM -0700, Kees Cook wrote:
> On Thu, Jun 04, 2020 at 02:58:06PM +0100, Will Deacon wrote:
> > On Thu, Jun 04, 2020 at 04:49:57PM +0300, Alexander Popov wrote:
> > > Don't try instrumenting functions in
> > > arch/arm64/kernel/vdso/
REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS)
> $(GCC_PLUGINS_CFLAGS)
> KBUILD_CFLAGS+= $(DISABLE_LTO)
> KASAN_SANITIZE := n
> UBSAN_SANITIZE := n
> --
> 2.25.4
I'll pick this one up as a fix for 5.8, please let me know if that's a
problem.
Will
[...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: vdso: Don't use gcc plugins for building vgettimeofday.c
https://git.kernel.org/arm64/c/e56404e8e475
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
up.
>
> > Anyway, it won't work with array types at least,
> > int a[10];
> > typeof ((typeof (a)) (a)) b;
> > is an error (in both gcc and clang), while typeof (a) b; will work
> > (but not drop the qualifiers). Don't know if the kernel cares
On Tue, Nov 17, 2020 at 09:10:53PM +, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> > >
> > > It would need to be typeof( (typeof(type)) (type) ) to not be that
> &
erest or experience in array mechanics, C or C++,
I could do with a mentor / lifeline / phone-a-friend.
I've joined the gcc developer IRC as doodle.
At some point, ABI specifications for array return types will be needed.
Thanks, Will
t the codegen
tends to be worse iirc.
In any case, for this specific problem I think we either need a fixed
compiler or some kbuild magic to avoid using it / disable the new behaviour.
We rely on 'asm volatile' not being elided in other places too.
Will
d here:
http://www.nabble.com/gcc---General-f1157.html
Posts from the list are updated to the minute. The new posts will be almost
immediately searchable.
Nabble also have a combined gcc archive which combines all the lists from gcc -
this includes the gcc-fortran, gcc-help, gcc-java... Inst
ion. I just corrected the info on Nabble, and I quoted your
remarks in the description. The url is now:
http://www.nabble.com/gcc---Dev-f1157.html
Nabble will develop a feature that will allow a user like you to correct this
type of mistake by yourself. It will be kind of like wiki. But for n
lfish
interest in discussing this with you guys. Below is my view of the pros and
cons of different alternatives:
1. Google - Not free, has ads
But the real problem is that Google does not index all the posts, and we don't
know what are the criteria for indexing. One thing for sure, the recent p
49 matches
Mail list logo
