On 12/05/2016 11:52 AM, Martin Sebor wrote:
What's the concern with using std::abs?
My concern, when I wrote the reply n Friday, was that not all C++98
implementations may get std::abs right, declare it in the right header,
avoid defining the abs macro, or put it in namespace std. (IIRC,
the s
On 12/05/2016 11:25 AM, Jeff Law wrote:
On 12/05/2016 08:50 AM, Martin Sebor wrote:
On 12/02/2016 08:52 AM, Martin Sebor wrote:
On 12/02/2016 01:31 AM, Rainer Orth wrote:
Hi Martin,
PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
thing (i.e., the -Wformat-length and -fpr
On Mon, Dec 05, 2016 at 11:37:23AM -0700, Jeff Law wrote:
> On 12/05/2016 11:30 AM, Marek Polacek wrote:
> >On Mon, Dec 05, 2016 at 11:25:02AM -0700, Jeff Law wrote:
> >>We're already using std::min std::max, std::swap and others.
> >
> >Note we're not using std::min nor std::max. I gave this a sh
On 12/05/2016 11:30 AM, Marek Polacek wrote:
On Mon, Dec 05, 2016 at 11:25:02AM -0700, Jeff Law wrote:
We're already using std::min std::max, std::swap and others.
Note we're not using std::min nor std::max. I gave this a shot a while ago,
but it didn't pan out:
https://gcc.gnu.org/ml/gcc-pat
On Mon, Dec 05, 2016 at 11:25:02AM -0700, Jeff Law wrote:
> >>
> >>Thanks for the heads up! I just looked at that code yesterday while
> >>analyzing bug 78608, wondering if it was safe. Now I know it isn't.
> >>I think it might be best to simply hand code the expression instead
> >>of taking a ch
On Mon, Dec 05, 2016 at 11:25:02AM -0700, Jeff Law wrote:
> We're already using std::min std::max, std::swap and others.
Note we're not using std::min nor std::max. I gave this a shot a while ago,
but it didn't pan out:
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00886.html
Marek
On 12/05/2016 08:50 AM, Martin Sebor wrote:
On 12/02/2016 08:52 AM, Martin Sebor wrote:
On 12/02/2016 01:31 AM, Rainer Orth wrote:
Hi Martin,
PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
thing (i.e., the -Wformat-length and -fprintf-return-value options
behave incorrec
On Mon, Dec 05, 2016 at 08:50:08AM -0700, Martin Sebor wrote:
> I posted a bigger patch to fix this and other related problems on
> Friday (https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00262.html).
> In hindsight, I should have probably committed the fix for this
> on its own. Please let me know
On 12/02/2016 08:52 AM, Martin Sebor wrote:
On 12/02/2016 01:31 AM, Rainer Orth wrote:
Hi Martin,
PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
thing (i.e., the -Wformat-length and -fprintf-return-value options
behave incorrectly) when a conversion specification includes
On 12/02/2016 01:31 AM, Rainer Orth wrote:
Hi Martin,
PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
thing (i.e., the -Wformat-length and -fprintf-return-value options
behave incorrectly) when a conversion specification includes a width
or precision with a non-constant val
Hi Martin,
> PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
> thing (i.e., the -Wformat-length and -fprintf-return-value options
> behave incorrectly) when a conversion specification includes a width
> or precision with a non-constant value. The code treats such cases
> as i
On 11/29/2016 01:04 AM, Christophe Lyon wrote:
On 29 November 2016 at 03:59, Martin Sebor wrote:
On 11/28/2016 06:35 PM, David Edelsohn wrote:
Martin,
I am seeing a number of new failures with the testcases on AIX.
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
Exc
On 11/29/2016 09:56 AM, Martin Sebor wrote:
On 11/28/2016 05:42 PM, Joseph Myers wrote:
On Sun, 27 Nov 2016, Martin Sebor wrote:
Finally, the patch also tightens up the constraint on the upper bound
of bounded functions like snprintf to be INT_MAX. The functions cannot
produce output in exces
On 11/28/2016 05:42 PM, Joseph Myers wrote:
On Sun, 27 Nov 2016, Martin Sebor wrote:
Finally, the patch also tightens up the constraint on the upper bound
of bounded functions like snprintf to be INT_MAX. The functions cannot
produce output in excess of INT_MAX + 1 bytes and some implementatio
On 29 November 2016 at 03:59, Martin Sebor wrote:
> On 11/28/2016 06:35 PM, David Edelsohn wrote:
>>
>> Martin,
>>
>> I am seeing a number of new failures with the testcases on AIX.
>>
>> FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
>>
>> Excess errors:
>>
>> /nasfarm/ed
On 11/28/2016 06:35 PM, David Edelsohn wrote:
Martin,
I am seeing a number of new failures with the testcases on AIX.
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1485:3:
Martin,
I am seeing a number of new failures with the testcases on AIX.
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
Excess errors:
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1485:3:
warning: specified destination size 2147483647 i
On Sun, 27 Nov 2016, Martin Sebor wrote:
> Finally, the patch also tightens up the constraint on the upper bound
> of bounded functions like snprintf to be INT_MAX. The functions cannot
> produce output in excess of INT_MAX + 1 bytes and some implementations
> (e.g., Solaris) fail with EINVAL whe
On 11/27/2016 08:34 PM, Martin Sebor wrote:
PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
thing (i.e., the -Wformat-length and -fprintf-return-value options
behave incorrectly) when a conversion specification includes a width
or precision with a non-constant value. The cod
PR 78521 notes that the gimple-ssa-sprintf pass doesn't do the right
thing (i.e., the -Wformat-length and -fprintf-return-value options
behave incorrectly) when a conversion specification includes a width
or precision with a non-constant value. The code treats such cases
as if they were not provi
20 matches
Mail list logo
