On 12/11/2016 05:21 PM, Martin Sebor wrote:
So I think the return value needs a bit of clarification here. Take
guidance from our discussion on this thread.
OK with that fixed.
jeff
The "strange test failures​" that I wrote about in a separate thread
late last week prompted me to re-review
On 12/07/2016 12:17 PM, Martin Sebor wrote:
OK. So is the hangup really a problem in how the return type is
documented? I parsed the comment as essentially saying we return true
if the range gets adjusted in any way -- thus a sign change in the first
block would qualify, but we returned false
So I think the return value needs a bit of clarification here. Take
guidance from our discussion on this thread.
OK with that fixed.
jeff
The "strange test failures​" that I wrote about in a separate thread
late last week prompted me to re-review the patch and add more test
cases. Those in
On 12/07/2016 11:43 AM, Jeff Law wrote:
On 12/02/2016 03:54 PM, Martin Sebor wrote:
Thanks for looking at this! I realize it's dense code and not easy
to make sense out of.
+
+ if (TREE_CODE (*argmin) == INTEGER_CST
+ && TREE_CODE (*argmax) == INTEGER_CST
+ && (dirprec >= argprec
+
On 12/05/2016 08:43 PM, Martin Sebor wrote:
Martin
$ cat b.c && /build/gcc-78622/gcc/xgcc -B /build/gcc-78622/gcc -O2 -S
-Wall -Wextra -Wpedantic b.c
char d[1];
void f (int i)
{
if (i < 1024 || 1033 < i) i = 1024;
__builtin_sprintf (d + 1, "%hhi", i);
}
void g (int i)
{
if (i < 1024
On 12/02/2016 03:54 PM, Martin Sebor wrote:
Thanks for looking at this! I realize it's dense code and not easy
to make sense out of.
+
+ if (TREE_CODE (*argmin) == INTEGER_CST
+ && TREE_CODE (*argmax) == INTEGER_CST
+ && (dirprec >= argprec
+ || integer_zerop (int_const_binop
On 12/05/2016 01:26 PM, Jakub Jelinek wrote:
Hi!
On Thu, Dec 01, 2016 at 07:31:18PM -0700, Martin Sebor wrote:
+static bool
+adjust_range_for_overflow (tree dirtype, tree *argmin, tree *argmax)
+{
+ if (TYPE_UNSIGNED (dirtype))
+{
+ *argmin = dirmin;
+ *argmax = dirmax;
+}
+
Hi!
On Thu, Dec 01, 2016 at 07:31:18PM -0700, Martin Sebor wrote:
> +static bool
> +adjust_range_for_overflow (tree dirtype, tree *argmin, tree *argmax)
> +{
> + if (TYPE_UNSIGNED (dirtype))
> +{
> + *argmin = dirmin;
> + *argmax = dirmax;
> +}
> + else
> +{
> +
Thanks for looking at this! I realize it's dense code and not easy
to make sense out of.
PR middle-end/78622 - [7 Regression]
-Wformat-length/-fprintf-return-value incorrect with overflow/wrapping
gcc/ChangeLog:
PR middle-end/78622
* gimple-ssa-sprintf.c (min_bytes_remaining): Use
On 12/01/2016 07:31 PM, Martin Sebor wrote:
On 12/01/2016 02:15 AM, Jakub Jelinek wrote:
On Thu, Dec 01, 2016 at 08:26:47AM +0100, Jakub Jelinek wrote:
Isn't this too simplistic? I mean, if you have say dirtype of signed
char
and argmin say 4096 + 32 and argmax say 4096 + 64, (signed char)
On 12/01/2016 02:15 AM, Jakub Jelinek wrote:
On Thu, Dec 01, 2016 at 08:26:47AM +0100, Jakub Jelinek wrote:
Isn't this too simplistic? I mean, if you have say dirtype of signed char
and argmin say 4096 + 32 and argmax say 4096 + 64, (signed char) arg
has range 32, 64, while I think your
On Thu, Dec 01, 2016 at 08:26:47AM +0100, Jakub Jelinek wrote:
> Isn't this too simplistic? I mean, if you have say dirtype of signed char
> and argmin say 4096 + 32 and argmax say 4096 + 64, (signed char) arg
> has range 32, 64, while I think your routine will yield -128, 127 (well,
> 0 as min
On Wed, Nov 30, 2016 at 08:26:04PM -0700, Martin Sebor wrote:
> @@ -795,6 +795,43 @@ get_width_and_precision (const conversion_spec ,
>*pprec = prec;
> }
>
> +/* With the range [*ARGMIN, *ARGMAX] of an integer directive's actual
> + argument, due to the conversion from either *ARGMIN or
In the gimple-ssa-sprintf pass I made the incorrect assumption that
a wider integer argument in some range [X, Y] to a narrower directive
(such as int to %hhi) results in the number of bytes corresponding to
the range bounded by the number of bytes resulting from formatting X
and Y converted to
14 matches
Mail list logo
