On Feb 8, 2018, Richard Biener wrote:
> Add a 'defered' keyword?
Done:
deferred:
This bug was deemed too risky to attempt to fix during stabilization
stages. Deferred to a development stage of a subsequent release.
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
Hello Gerald,
We added missing cronjob to update it. It should be updated in less than
6 hours.
Regards
Martin
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
Torvald, I think this discussion, indeed, gets pointless. Some of your
responses clearly take my comments out of larger picture and context of the
discussion.
One thing is clear that either implementation is fine with the standard
(formally speaking) simply because the standard allows too much l
On Tue, 2018-02-27 at 19:32 +, Ruslan Nikolaev wrote:
>
> > But we're not talking about that special case of 128b types here. The
> > majority of synchronization doesn't need more than machine word size.
> Then why do you worry about read-only access for 128b types? (it is a special
> case a
On 27/02/18 13:53, Yao Qi wrote:
> Hi Paulo,
> I noticed that GDB buildbot pending build queue on aarch64-linux
> becomes longer and longer,
> https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-m64
> as it takes longer to finish each build and test.
>
> Looks that you deployed aarch64-linux bu
Hi,
I would like to know if you are interested in acquiring Network Software Users
List.
Information fields we provide for each contact in the list: MYVRMS, Volanté
Systems, TravelNet Solutions, Givex, InnQuest Software, TurfCare Supply Corp,
Software Developers Inc, and Software Develop
> But we're not talking about that special case of 128b types here. The
> majority of synchronization doesn't need more than machine word size.
Then why do you worry about read-only access for 128b types? (it is a special
case anyway).
> No, such a program would have a bug anyway. It wouldn't
On Tue, 2018-02-27 at 17:29 +, Ruslan Nikolaev wrote:
>
>
> > Consider a producer-consumer relationship between two processes where
> > the producer doesn't want to wait for the consumer. For example, the
> > producer could be an application that's being traced, and the consumer
> > is a tra
On 27 Feb 2018, at 17:07, Torvald Riegel wrote:
>
> On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote:
>> On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote:
>>>
>>> And all this mess to accommodate almost non-existent case when someone
>>> wants to use atomic_load on read-only memory
> Consider a producer-consumer relationship between two processes where
> the producer doesn't want to wait for the consumer. For example, the
> producer could be an application that's being traced, and the consumer
> is a trace aggregation tool. The producer can provide a read-only
> mapping
On Tue, 2018-02-27 at 16:40 +, Simon Wright wrote:
> On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote:
> >
> > And all this mess to accommodate almost non-existent case when someone
> > wants to use atomic_load on read-only memory for wide types, in which no
> > good solution exists
Torvald, thank you for your output, but I think, this discussion gets a little
pointless. There is nothing else I can add since gcc folks are reluctant to
this change anyway. In my opinion, there is no compelling reason against such
an implementation (it is perfectly fine with the standard, read
On 02/27/2018 05:40 PM, Simon Wright wrote:
Sorry to butt in, but - if it's ROM why would you need atomic load anyway? (of
course, if it's just a constant view of the object, reason is obvious)
On many systems, the read-only nature of a memory region is a
thread-local or process-local attribu
On 27 Feb 2018, at 12:56, Ruslan Nikolaev via gcc wrote:
>
> And all this mess to accommodate almost non-existent case when someone wants
> to use atomic_load on read-only memory for wide types, in which no good
> solution exists anyway
Sorry to butt in, but - if it's ROM why would you need at
On Tue, 2018-02-27 at 13:16 +, Ruslan Nikolaev via gcc wrote:
> > 3) Torvald pointed out further considerations such as users expecting
> > lock-free atomic loads to be faster than stores.
>
> Is it even true? Is it faster to use some global lock (implemented through
> RMW) than a single RMW
On Tue, 2018-02-27 at 13:04 +, Szabolcs Nagy wrote:
> the solutions is to add a language extension
I think this only needs a library interface, at least when we're just
considering the __atomic builtins. On the C/C++ level, it might amount
to just another atomic type, which only has a CAS how
On Tue, 2018-02-27 at 12:56 +, Ruslan Nikolaev via gcc wrote:
> But, of course, it is kind of annoying that double-width types (and that also
> includes potentially 64-bit on some 32-bit processors, e.g. i586 also has
> cmpxchg8b and no official way to read atomically otherwise) need special
On Sun, Feb 25, 2018 at 10:46 AM, Martin Jambor wrote:
> Hello Hrishikesh,
>
> I apologize for replying to you this late, this has been a busy week
> and now I am traveling.
>
> On Mon, Feb 19 2018, Hrishikesh Kulkarni wrote:
>> Hi,
>>
>> I am Hrishikesh Kulkarni currently studying as an undergrad
On Mon, Feb 26, 2018 at 9:04 PM, Jeff Law wrote:
> 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
>>
> 1) your proposal would make gcc non-conforming to iso c unless it changes how
> static const objects are emitted.
I do not think, ISO C requires to put const objects to .rodata. And it is
easily solved by not placing it there for _Atomic objects that cannot be safely
loaded from read-only m
On Mon, Feb 26, 2018 at 5:35 PM, Dushyant Pratap Singh
wrote:
> 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 o
On 27/02/18 12:56, Ruslan Nikolaev wrote:
Formally speaking, either implementation satisfies C11 because the standard
allows much leeway in the interpretation here.
no,
1) your proposal would make gcc non-conforming to iso c unless it changes how
static const objects are emitted.
2) the two
Formally speaking, either implementation satisfies C11 because the standard
allows much leeway in the interpretation here. But, of course, it is kind of
annoying that double-width types (and that also includes potentially 64-bit on
some 32-bit processors, e.g. i586 also has cmpxchg8b and no offi
Hi Paulo,
I noticed that GDB buildbot pending build queue on aarch64-linux
becomes longer and longer,
https://gdb-build.sergiodj.net/builders/Ubuntu-AArch64-m64
as it takes longer to finish each build and test.
Looks that you deployed aarch64-linux buildslave for GCC buildbot
on gcc114 as well, th
Ok, thank you.
Alexander
-Ursprüngliche Nachricht-
Von: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] Im Auftrag von Martin
Liška
Gesendet: Dienstag, 27. Februar 2018 13:39
An: Alexander Fichtinger ; gcc@gcc.gnu.org
Betreff: Re: AW: AW: AW: AW: Problem using gcov
On 02/27/2018 09
On 02/27/2018 09:13 AM, Alexander Fichtinger wrote:
> Ok, thanks for the information.
>
> Do we get all coverage-related problems when we monitor the Bugs with the
> Component "gcov-profile"?
> Or are there other components concerning coverage?
Yes, I mark all gcov bugs with this component.
>
On Mon, 2018-02-26 at 22:45 +, Ruslan Nikolaev via gcc wrote:
> 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
On Tue, 2018-02-27 at 10:22 +, Ramana Radhakrishnan wrote:
> The way to fix this in AArch64 if there is a
> guarantee from the standard that there are no problems with read-only
> locations is to implement the change in libatomic.
Even though the standard doesn't specify read-only memory, I t
On Mon, 2018-02-26 at 19:39 +, Ruslan Nikolaev via gcc wrote:
> 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
> cmpxc
On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc
wrote:
> 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
On 02/26/2018 07:36 PM, Janne Blomqvist wrote:
There is no such architectural guarantee. At least on some
micro-architecture (AMD Opteron "Istanbul") it's possible to construct
a test which fails, proving that at least on that micro-arch SSE2
load/store isn't guaranteed to be atomic.
Looks like
I think it would be a nice addition to the toolchain if it were possible
to programatically initialize data in the RELRO section. We do this in
glibc, but I don't think this is currently supported for general use.
One important application is to allocate a memory region with mmap, on
which pr
Ok, thanks for the information.
Do we get all coverage-related problems when we monitor the Bugs with the
Component "gcov-profile"?
Or are there other components concerning coverage?
We are using gcov in our Testframework (used for Automotive software) in order
to determine the Code-Coverage,
On 02/26/2018 03:41 PM, Alexander Fichtinger wrote:
> 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 for understanding. I would just note that there's couple of similar
issues
you probably want to be
34 matches
Mail list logo
