On Fri, Apr 1, 2016 at 1:14 PM, Martin Liška wrote:
> On 03/31/2016 05:48 PM, Maxim Ostapenko wrote:
>>
>> Yes, but please note, that this page describes differences between two
>> particular revisions. For current trunk (and release) GCC and LLVM versions
>> the situation might be different.
>>
On Tue, Jul 12, 2016 at 9:48 AM, Maxim Ostapenko
wrote:
> On 11/07/16 19:28, Jeff Law wrote:
>>
>> On 07/11/2016 10:08 AM, Maxim Ostapenko wrote:
>>>
>>> On 11/07/16 18:05, Jakub Jelinek wrote:
On Tue, Jul 05, 2016 at 10:31:31AM +0300, Maxim Ostapenko wrote:
>
> CC'ing Jakub, Mar
On Tue, Jul 12, 2016 at 10:34 AM, Jakub Jelinek wrote:
> On Tue, Jul 12, 2016 at 10:20:55AM +0100, Yuri Gribov wrote:
>> There are people who would tolerate FPs if the tool indeed helps to
>> find vulnerabilities. Especially if there is easy way to suppress
>> checks in set o
Cc John.
On Tue, Jul 12, 2016 at 10:49 AM, Maxim Ostapenko
wrote:
> On 12/07/16 12:20, Yuri Gribov wrote:
>>
>> On Tue, Jul 12, 2016 at 9:48 AM, Maxim Ostapenko
>> wrote:
>>>
>>> On 11/07/16 19:28, Jeff Law wrote:
>>>>
>>>> On 07/1
Hi all,
I've recently revisited an ancient patch from Paolo
(https://gcc.gnu.org/ml/gcc-patches/2004-04/msg00551.html) which uses
asserts as optimization hints. I've rewritten the patch to be more
stable under expressions with side-effects and did some basic
investigation of it's efficacy.
Optimi
Hi all,
I've recently revisited an ancient patch from Paolo
(https://gcc.gnu.org/ml/gcc-patches/2004-04/msg00551.html) which uses
asserts as optimization hints. I've rewritten the patch to be more
stable under expressions with side-effects and did some basic
investigation of it's efficacy.
Optimi
On Wed, Nov 23, 2016 at 11:31 AM, Richard Biener
wrote:
> On Tue, Nov 22, 2016 at 6:52 PM, Yuri Gribov wrote:
>> Hi all,
>>
>> I've recently revisited an ancient patch from Paolo
>> (https://gcc.gnu.org/ml/gcc-patches/2004-04/msg00551.html) which uses
>&g
On Mon, Nov 28, 2016 at 4:03 PM, Vincent Lefevre wrote:
> On 2016-11-23 16:03:44 +0000, Yuri Gribov wrote:
>> Definitely, aggressively abusing assertions like this should be a
>> per-project decision. E.g. I've seen code which parallels assertions
>> with error ch
On Thu, Jan 12, 2017 at 5:06 AM, Paul Smith wrote:
> TL;DR:
> I have an issue where if I have a .so linked with -static-lib* making
> all STL symbols private, and if I throw an exception out of that .so to
> be caught by the caller, then I get a SIGABRT from a gcc_assert() down
> in the guts of th
Hi all,
It seems that info at
https://gcc.gnu.org/wiki/CompileFarm#How_to_Get_Involved.3F is
out-dated: Laurent's mail is not responsive and one's supposed to use
application form at https://cfarm.tetaneutral.net/users/new/ (which
provides all the necessary guidance).
Could someone update the wik
Hi all,
What do I need to do to close an old bug which does not repro with
modern GCC and reporter does not care anymore (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40528)? Also, is there
some general policy about closing old bugs?
-Y
On Wed, Jul 5, 2017 at 12:14 PM, Jonathan Wakely wrote:
> On 5 July 2017 at 10:13, Oleg Endo wrote:
>> Hi,
>>
>> On Wed, 2017-07-05 at 02:02 +0200, Geza Herman wrote:
>>>
>>> Here's what happens: in callInitA(), an Object put onto the stack (which
>>> has a const member variable, initialized to 0)
On Sat, Jul 8, 2017 at 12:30 AM, Michael Clark wrote:
> Hi,
>
> Curious about this codegen:
>
> - https://godbolt.org/g/5XxP5S
>
> Why does gcc branch on _Bool, but emits a conditional move for an integer?
> can it emit cmovne instead of branching? also curious where one would change
> this to l
On Thu, Jul 13, 2017 at 4:56 AM, Klaus Kruse Pedersen (Klaus)
wrote:
> On Wed, 2017-07-12 at 08:57 -0600, Sandra Loosemore wrote:
>> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>> > I have seen reproducible builds being discussed here, but what is
>> > the
>> > position on inter c-
On Thu, Jul 13, 2017 at 4:56 AM, Klaus Kruse Pedersen (Klaus)
wrote:
> On Wed, 2017-07-12 at 08:57 -0600, Sandra Loosemore wrote:
>> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>> > I have seen reproducible builds being discussed here, but what is
>> > the
>> > position on inter c-
On Fri, Jul 14, 2017 at 8:45 AM, Yuri Gribov wrote:
> FWIW I've done a quick analysis of recent gcc source code using
> https://github.com/yugr/sortcheck and found lots of comparison
> functions which can return 0 for different objects.
>
> All these may cause arrays to be s
On Sat, Jul 15, 2017 at 10:01 PM, Alexander Monakov wrote:
> On Fri, 14 Jul 2017, Yuri Gribov wrote:
>> I've also detect transitiveness violation compare_assert_loc
>> (tree-vrp.c), will send fix once tests are done.
>
> There are more issues still, see the
Hi Mikhail,
On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev wrote:
> Hi. Yes, bug maintenance is appreciated. See this message and replies
> to it: https://gcc.gnu.org/ml/gcc/2016-04/msg00258.html .
Replies in your link suggest to leave a final comment in bugs with
explanatory suggestion to clos
On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote:
> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>
>> Hi Mikhail,
>>
>> On Sun, Jul 2, 2017 at 6:39 PM, Mikhail Maltsev
>> wrote:
>>>
>>> Hi. Yes, bug maintenance is appreciated. See this messag
On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote:
> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>
>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote:
>>>
>>> On 07/17/2017 02:14 AM, Yuri Gribov wrote:
>>>>
>>>>
>>>>
On Wed, Jul 19, 2017 at 7:15 PM, Eric Gallager wrote:
> On 7/18/17, Yuri Gribov wrote:
>> On Tue, Jul 18, 2017 at 3:54 PM, Martin Sebor wrote:
>>> On 07/17/2017 02:25 PM, Yuri Gribov wrote:
>>>>
>>>> On Mon, Jul 17, 2017 at 4:23 PM, Martin Sebor wrote
On Wed, Aug 9, 2017 at 2:49 PM, Andrew Haley wrote:
> On 09/08/17 14:05, Andrew Roberts wrote:
>> 2) It would be nice to see some sort of out of memory error, rather than
>> just an ICE.
>
> There's nothing we can do: the kernel killed us. We can't emit any
> message before we die. (killed) tell
On Wed, Aug 9, 2017 at 3:14 PM, Andreas Schwab wrote:
> On Aug 09 2017, Yuri Gribov wrote:
>
>> On Wed, Aug 9, 2017 at 2:49 PM, Andrew Haley wrote:
>>> On 09/08/17 14:05, Andrew Roberts wrote:
>>>> 2) It would be nice to see some sort of out of memory er
On Mon, Mar 19, 2018 at 10:17 AM, Vincent Lefevre
wrote:
> Hi,
>
> Any news about the ASAN compatibility with glibc 2.27 on x86?
> Will this be fixed soon? This is important as this is a blocker.
>
> FYI, I had reported:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
Asan runtime librar
Hi all,
This is my first post to the list so do not be too harsh)
I have expected all c-torture tests to be highly portable but I have
recently ran into test which relies on int being 32-bit
(execute/980526-2.c).
The test runs to_kdev_t(0x12345678) (see below) and verifies that
result equals 0x1
> Yes, it's possible that 64-bit ints are not supported by the testsuite.
> Changes to fix that are welcome.
I am not a gcc developer. Could someone verify and commit this patch
for testsuite/gcc.c-torture/execute/980526-2.c?
Best regards,
Yuri
980526-2.patch
Description: Binary data
> Done. But if you have more cases, please report them.
Not yet. Thx!
--
Best regards,
Yuri
> asm volatile + memory clobber should be the last resort barrier, if you skip
> this out of the compiler or change its semantics (pinned by the current
> documentation) at will, it's not unlikely you break existing code in favour
> or saving some poor instructions.
Problem is that there is no cur
28 matches
Mail list logo
