On Mon, 26 Feb 2018, Ruslan Nikolaev via gcc wrote:
> Well, if libatomic is already doing it when corresponding CPU feature is
> available (i.e., effectively implementing operations using cmpxchg16b), I do
> not see any problem here. mcx16 implies that you *have* cmpxchg16b, therefore
> other code
> I'd say the main issue is that libatomic is not guaranteed to work like that.
> Today it relies on IFUNC for redirection, so you may (and not "will") get the
> desired behavior on Glibc (implying Linux), not on other OSes, and neither on
> Linux with non-GNU libc (nor on bare metal, for that ma
Hello,
What exactly is the -Warray-bounds option to the GCC compiler supposed to
warn about?
My g++ --version: g++ (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
Regards,
Mustafa
On Wed, Feb 21, 2018 at 9:19 PM, Jeff Law wrote:
> On 02/21/2018 03:20 PM, Mustafa i. wrote:
> > Hi,
> >
> > I have a qu
Hi!
On Mon, 26 Feb 2018 07:58:17 +0100, Siegmar Gross
wrote:
> ../gcc-8.0.0/configure --prefix=/usr/local/gcc-8.0.0 \
>--target=nvptx-none \
>--enable-as-accelerator-for=x86_64-pc-linux-gnu \
>[...]
> checking for C compiler default output file name...
> configure: error: in
> `/ex
On Fri, Feb 16, 2018 at 8:07 PM, Martin Sebor wrote:
> On 02/16/2018 04:22 AM, Richard Biener wrote:
>>
>> On Thu, Feb 15, 2018 at 6:28 PM, Martin Sebor wrote:
>>>
>>> There are APIs to determine the base object and an offset
>>> into it from all sorts of expressions, including ARRAY_REF,
>>> COM
On 26/02/18 04:00, Ruslan Nikolaev via gcc wrote:
1. Not consistent with clang/llvm which completely supports double-width
atomics for arm32, arm64, x86 and x86-64 making it possible to write portable
code (w/o specific extensions or assembly code) across all these architectures
(which is fina
On 02/26/2018 11:30 AM, Alexander Fichtinger wrote:
> Hi Martin,
>
> sorry that it took me so long to create the standalone sample, but I was very
> busy the last few days.
>
>
> We can reproduce the strange behavior in a standalone scenario.
>
> I've provided it in the attachments.
> In the Z
On Mon, 26 Feb 2018, Szabolcs Nagy wrote:
>
> rmw load is only valid if the implementation can
> guarantee that atomic objects are never read-only.
OK, but that sounds like a matter of not emitting atomic
objects into .rodata, which shouldn't be a big problem,
if not for backwards compatibility c
Thanks Martin!
I've seen that the target milestone for this bug is 8.0.
When is 8.0 going to be released?
Thanks and kind regards,
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Gesendet: Montag, 26. Februar 201
On 26 February 2018 at 14:02, Alexander Fichtinger wrote:
> Thanks Martin!
>
> I've seen that the target milestone for this bug is 8.0.
>
> When is 8.0 going to be released?
The version number 8.0 is used for snapshots from trunk in version
control, the actual release will be 8.1, see
https://gcc.
On 02/26/2018 03:02 PM, Alexander Fichtinger wrote:
> Thanks Martin!
>
> I've seen that the target milestone for this bug is 8.0.
I did, but as described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84572#c1
I'm not planning to fix it in the next releases. It's just a minor issue in GCOV
infra
Ok, thanks for the info.
I just saw the description in the bug-report.
When we document this for our customers, it's ok, I think.
Thanks and kind regards,
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Gesendet:
On 26/02/18 13:56, Alexander Monakov wrote:
On Mon, 26 Feb 2018, Szabolcs Nagy wrote:
rmw load is only valid if the implementation can
guarantee that atomic objects are never read-only.
OK, but that sounds like a matter of not emitting atomic
objects into .rodata, which shouldn't be a big pro
Thank you for more comments, my response is below.
On Mon, 26 Feb 2018, Szabolcs Nagy wrote:>
> rmw load is only valid if the implementation can
> guarantee that atomic objects are never read-only.
But per response from WG14 regarding DR 459 which I quoted, the standard does
not seem to define
On 02/26/2018 05:08 AM, Richard Biener wrote:
On Fri, Feb 16, 2018 at 8:07 PM, Martin Sebor wrote:
On 02/16/2018 04:22 AM, Richard Biener wrote:
On Thu, Feb 15, 2018 at 6:28 PM, Martin Sebor wrote:
There are APIs to determine the base object and an offset
into it from all sorts of expressi
On 02/26/2018 02:41 AM, Mustafa i. wrote:
> Hello,
>
> What exactly is the -Warray-bounds option to the GCC compiler supposed
> to warn about?
It's meant to warn for out of bounds array access.
For example, if you have a 10 element array, but try to access the 11th
element you should get a warnin
Hi Thomas,
I cloned nvptx* again and now I was able to build everything.
The new compiler works for my small accelerator programs.
Thank you very much for your help
Siegmar
Am 26.02.2018 um 10:57 schrieb Thomas Schwinge:
Hi!
On Mon, 26 Feb 2018 07:58:17 +0100, Siegmar Gross
wrote:
../gcc
Hello GCC community,
My name is Dushyant and I am interested in Gsoc at GCC .I am pursuing
Integrated B.Tech (Computer Science) and M.Tech (software engineering) from
Gautam Buddha University, India. Currently I am in 4th year of the
programme.
I have experience in Competitive Programming (primary
On 02/26/2018 05:00 AM, Ruslan Nikolaev via gcc wrote:
If I understand correctly, the redirection to libatomic was made for 2 reasons:
1. cmpxchg16b is not available on early amd64 processors. (However, mcx16 flag
already specifies that you use CPUs that have this instruction, so it should
not
On Monday, February 26, 2018 1:15 PM, Florian Weimer wrote:
> I think x86-64 should be able to do atomic load and store via SSE2
> registers, but perhaps if the memory is suitably aligned (which is the
> other problem—the libatomic code will work irrespective of alignment, as
> far as I und
On Mon, 2018-02-26 at 14:53 +, Ruslan Nikolaev via gcc wrote:
> Thank you for more comments, my response is below.
>
>
>
> On Mon, 26 Feb 2018, Szabolcs Nagy wrote:>
> > rmw load is only valid if the implementation can
> > guarantee that atomic objects are never read-only.
> But per respons
On Mon, Feb 26, 2018 at 8:15 PM, Florian Weimer wrote:
> On 02/26/2018 05:00 AM, Ruslan Nikolaev via gcc wrote:
>>
>> If I understand correctly, the redirection to libatomic was made for 2
>> reasons:
>> 1. cmpxchg16b is not available on early amd64 processors. (However, mcx16
>> flag already spec
On Mon, 2018-02-26 at 08:50 +0300, Alexander Monakov wrote:
> > For these reasons, it may be a good idea if GCC folks reconsider past
> > decision. And just to clarify: if mcx16 (x86-64) is not specified during
> > compilation, it is totally OK to redirect to libatomic, and there make the
> > final
Torvald, thank you for your output. See my response below.
On Monday, February 26, 2018 1:35 PM, Torvald Riegel
wrote:
> ... does not imply this latter statement. The statement you cited is
> about what the standard itself requires, not what makes sense for a
> particular implementation.
On Mon, 2018-02-26 at 07:24 +, Ruslan Nikolaev via gcc wrote:
> Alexander,
> Thank you for your comments. Please see my response below. I definitely do
> not want to fight for or against this change in gcc, but there are definitely
> legitimate concerns to consider. I think, it would really
On Mon, 2018-02-26 at 18:55 +, Ruslan Nikolaev via gcc wrote:
> Torvald, thank you for your output. See my response below.
>
> On Monday, February 26, 2018 1:35 PM, Torvald Riegel
> wrote:
>
> > ... does not imply this latter statement. The statement you cited is
> > about what the st
Torvald, I definitely do not want to insist on this design choice, but it makes
sense to at least seriuously consider it given the concerns I described. And
especially because IFFUNC in libatomic already redirects to cmpxchg16b, so it
just adds extra cost and indirection. Quite frankly, I do not
On 02/26/2018 05:08 AM, Richard Biener wrote:
> On Fri, Feb 16, 2018 at 8:07 PM, Martin Sebor wrote:
>> Say I have a struct like this:
>>
>> struct A {
>> char a[4], b[5];
>> };
>>
>> then in
>>
>> extern struct A *a;
>>
>> memset (&a[0].a[0] + 14, 0, 3); // invalid
>>
>> memset (
On 02/26/2018 08:44 AM, Martin Sebor wrote:
>
> Folding things to MEM_REF (or rather, folding them too early)
> makes all kinds of analysis harder: not just warnings but even
> optimization. I've raised a whole slew of bugs for the strlen
> pass alone where folding string functions to MEM_REF def
Hi Martin,
On Mon, 6 Nov 2017, KoDDoS Mirror wrote:
> The mirror is setup. Here is a patch as I do not have write access to
> push it.
I was just going to commit the following patch (sorry for the
delay), alas noticed your mirror does not seem to, umm, mirror?
The expectation is that you'll mir
Thanks, everyone, for the output, it is very useful. I am just proposing to
consider the change unless there are clear roadblocks. (Either design choice is
probably OK with respect to the standard formally speaking, but there are some
clear advantages also.) I wrote a summary of pros & cons (whi
On Thu, Feb 22, 2018 at 8:44 AM, R0b0t1 wrote:
> Would any other information be helpful? All results called for the
> installation of binary packages, which is not possible (I don't use
> apt).
>
>
> ../../source/${dname}/configure \
> --target=${TARGET} \
> --prefix=`realpath
> If the scope of GCC still intimidates you (but we all struggle with it
> sometimes, trust me), consider reaching out to Andi Kleen and discuss
> his fuzzer project idea with him (he may tell you what to check out and
> experiment with to get the feeling about the task at hand).
The fuzzer projec
33 matches
Mail list logo
