Re: C as intermediate language, signed integer overflow and -ftrapv

[Thomas Mertes]

On Thu, Jul 24 at 10:36 PM, Richard Biener  wrote:
> Fact is that if somebody is interested in
> -ftrapv he/she is welcome to contribute patches.  Especially testing
> coverage is poor.

As I said I have test programs for integer overflow (not written
in C). Now I have converted one test program to C. This program
checks if an int64_t overflow raises SIGABRT or SIGILL. The name of
the program is chkovf64.c and I have uploaded it to

  http://sourceforge.net/projects/seed7/files/

It is licenced with GPL. You can use it to improve the testing
coverage of gcc. When I compile it with:

  gcc -ftrapv chkovf64.c -o chkovf64

it writes a lot of warnings about "integer overflow in expression".
Running chkovf64 shows that -ftrapv does not work correct.
It seems that gcc thinks that writing a warning is enough and
raising a signal at runtime is not necessary. For human
programmers this makes sense, since they read the warnings and
correct the code. But for generated C programs this is not the
right strategy. There are different needs when C is used as
intermediate language.

Maybe all -ftrapv problems uncovered by chkovf64.c are because
of this. Unfortunately there are also other test cases where
a signal is not raised although a signed integer overflow occurred.
This happens in a much bigger program and until now I was not
able to create a simple test case from it.

I used clang version 3.4-1 to proof that chkovf64.c works correct.
When I compile it with:

  clang -ftrapv chkovf64.c -o chkovf64

and start chkovf64 afterwards it writes:

Overflow checking of negation works correct.
Overflow checking of addition works correct.
Overflow checking of addition assignment works correct.
Overflow checking of subtraction works correct.
Overflow checking of subtraction assignment works correct.
Overflow checking of incr works correct.
Overflow checking of decr works correct.
Overflow checking of multiplication works correct.
Overflow checking of multiplication assignment works correct.

Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Ludovic Courtès]

"Joseph S. Myers"  skribis:

> In accordance with GNU principles we should be making the videos available 
> without depending on non-free JavaScript as well (I don't know if Google+ 
> makes videos readily available without JS or with only free JS).

Agreed.  I would recommend making them available from
 (people behind webmas...@gnu.org
should be able to help.)

Thanks,
Ludo’.

Re: GCC version bikeshedding

[Richard Biener]

On Thu, Jul 24, 2014 at 5:38 PM, Jeff Law  wrote:
> On 07/23/14 10:20, Ian Lance Taylor wrote:
>>
>> I am also fine with it.
>>
>> I think that if anybody has strong objections, now is the time to make
>> them.  Otherwise I think we should go with this plan.
>>
>> To me, the basic summary of the idea is that there is no clear reason
>> to ever change the GCC major version number.  There were real
>> objections to changing it when we went from 3 to 4.  There will be
>> real objections for any future change from 4 to 5.  At the same time,
>> we face the fact that going from 4.9 to 4.10 will break some people's
>> existing scripts, as is also true of any other decision we can make.
>>
>> Given that there is no clear reason to ever change the major version
>> number, making that change will not convey any useful information to
>> our users.  So let's just drop the major version number.  Once we've
>> made that decision, then the next release (in 2015) naturally becomes
>> 5.0, the release after that (in 2016) becomes 6.0, etc.
>
> Agreed.   It's not 100% perfect, but, IMHO, it's significantly better than
> what we're doing now and better than the various alternatives that have been
> proposed.

If a native speaker can cook something up for the head of gcc-5/changes.html
about this change that would be nice.  (yes, gcc-5/, not gcc-5.0/ ...)

Richard.

> Jeff

Re: Symtab node table introduction and GGC issues

[Richard Biener]

On Thu, Jul 24, 2014 at 7:21 PM, Martin Liška  wrote:
>
> On 07/24/2014 05:53 PM, David Malcolm wrote:
>>
>> On Thu, 2014-07-24 at 16:23 +0100, Martin Liška wrote:
>>>
>>> Hello,
>>>  I would like to encapsulate all symtab_nodes to a class called
>>> 'symtab'.
>>
>> Thanks!
>>
>>>   To respect gcc:context, I would like to add the class to global
>>> context (gcc::context) and I have troubles with GTY and GGC.
>>>
>>> design:
>>>
>>> class GTY(()) symtab
>>> {
>>> public:
>>> symtab_node* GTY(()) nodes;
>>> };
>>>
>>> class GTY(()) context
>>> {
>>> public:
>>> context () {}
>>> void init ();
>>>
>>> /* Pass-management.  */
>>> pass_manager *get_passes () { gcc_assert (m_passes); return m_passes;
>>> }
>>>
>>> /* Handling dump files.  */
>>> dump_manager *get_dumps () {gcc_assert (m_dumps); return m_dumps; }
>>>
>>> /* Symbol table.  */
>>> symtab *get_symtab () { gcc_assert (symbol_table); return
>>> symbol_table; }
>>>
>>> /* Symbol table.  */
>>> symtab * GTY(()) symbol_table;
>>>
>>> private:
>>> /* Pass-management.  */
>>> pass_manager * GTY((skip)) m_passes;
>>>
>>> /* Dump files.  */
>>> dump_manager * GTY((skip)) m_dumps;
>>> }; // class context
>>>
>>> } // namespace gcc
>>>
>>> /* The global singleton context aka "g".
>>>  (the name is chosen to be easy to type in a debugger).  */
>>> extern GTY(()) gcc::context *g;
>>>
>>>
>>>
>>> gcc:context in created by g = ggc_cleared_alloc (); and
>>> g->symbol_table too.
>>> My problem is that during pg_pch_restore:
>>> #3  0x00850043 in gt_pch_restore (f=0x1ac9100) at
>>> ../../gcc/ggc-common.c:691
>>>
>>> When I add watch to *(&g), gcc::context *g is restored ^ and
>>> gcc:context::m_passes and gcc:context::m_dumps are set to an inaccessible
>>> address.
>>>
>>> Is my GGC construct correct?
>>
>> Back when we introduced the context and the pass_manager (called the
>> "pipeline" in the initial patch submissions), those two classes were
>> GTY-marked, but I reverted the change in r201887 (aka
>> 5d068519b66a37ab391c427d0aac13f66a9b5c4e):
>>
>>  Revert my last two changes, r201865 and r201864
>>   2013-08-20  David Malcolm  
>>   Revert my last two changes, r201865 and r201864:
>>   Revert r201865:
>>  2013-08-20  David Malcolm  
>>   Make opt_pass and gcc::pass_manager be GC-managed, so that
>> pass
>>  instances can own GC refs.
>>   * Makefile.in (GTFILES): Add pass_manager.h and tree-pass.h.
>>  * context.c (gcc::context::gt_ggc_mx): Traverse passes_.
>>  (gcc::context::gt_pch_nx): Likewise.
>>  (gcc::context::gt_pch_nx):  Likewise.
>>  * ggc.h (gt_ggc_mx ): New.
>>  (gt_pch_nx_with_op ): New.
>>  (gt_pch_nx ): New.
>>  * passes.c (opt_pass::gt_ggc_mx): New.
>>  (opt_pass::gt_pch_nx): New.
>>  (opt_pass::gt_pch_nx_with_op): New.
>>  (pass_manager::gt_ggc_mx): New.
>>  (pass_manager::gt_pch_nx): New.
>>  (pass_manager::gt_pch_nx_with_op): New.
>>  (pass_manager::operator new): Use
>>  ggc_internal_cleared_alloc_stat rather than xcalloc.
>>  * pass_manager.h (class pass_manager): Add GTY((user)) marking.
>>  (pass_manager::gt_ggc_mx): New.
>>  (pass_manager::gt_pch_nx): New.
>>  (pass_manager::gt_pch_nx_with_op): New.
>>  * tree-pass.h (class opt_pass): Add GTY((user)) marking.
>>  (opt_pass::operator new): New.
>>  (opt_pass::gt_ggc_mx): New.
>>  (opt_pass::gt_pch_nx): New.
>>  (opt_pass::gt_pch_nx_with_op): New.
>>   Revert r201864:
>>  2013-08-20  David Malcolm  
>>   * Makefile.in (GTFILES): Add context.h.
>>  * context.c (gcc::context::operator new): New.
>>  (gcc::context::gt_ggc_mx): New.
>>  (gcc::context::gt_pch_nx): New.
>>  (gcc::context::gt_pch_nx): New.
>>  * context.h (gcc::context): Add GTY((user)) marking.
>>  (gcc::context::operator new): New.
>>  (gcc::context::gt_ggc_mx): New.
>>  (gcc::context::gt_pch_nx): New.
>>  (gcc::context::gt_pch_nx): New.
>>  (g): Add GTY marking.
>>  (gt_ggc_mx (gcc::context *)): New.
>>  (gt_pch_nx (gcc::context *)): New.
>>  (gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
>>  void *cookie)): New.
>>  * gengtype.c (open_base_files) : Add context.h.
>>
>> Looking over the list archives, I found this reason for the revert:
>> https://gcc.gnu.org/ml/gcc/2013-08/msg00214.html
>> the integration of GTY into context and pass_manager wasn't fully-baked,
>> and was causing PCH crashes.  Looks like I didn't go back and fully
>> debug the issue; sorry.
>>
>> As for the issue you're seeing... I'm guessing you've put the "skip"
>> clauses on m_passes and m_dumps as a workaround for the issue from last
>> year, but they don't seem in th

Re: Symtab node table introduction and GGC issues

[Richard Biener]

On Fri, Jul 25, 2014 at 12:24 PM, Richard Biener
 wrote:
> On Thu, Jul 24, 2014 at 7:21 PM, Martin Liška  wrote:
>>
>> On 07/24/2014 05:53 PM, David Malcolm wrote:
>>>
>>> On Thu, 2014-07-24 at 16:23 +0100, Martin Liška wrote:

 Hello,
  I would like to encapsulate all symtab_nodes to a class called
 'symtab'.
>>>
>>> Thanks!
>>>
   To respect gcc:context, I would like to add the class to global
 context (gcc::context) and I have troubles with GTY and GGC.

 design:

 class GTY(()) symtab
 {
 public:
 symtab_node* GTY(()) nodes;
 };

 class GTY(()) context
 {
 public:
 context () {}
 void init ();

 /* Pass-management.  */
 pass_manager *get_passes () { gcc_assert (m_passes); return m_passes;
 }

 /* Handling dump files.  */
 dump_manager *get_dumps () {gcc_assert (m_dumps); return m_dumps; }

 /* Symbol table.  */
 symtab *get_symtab () { gcc_assert (symbol_table); return
 symbol_table; }

 /* Symbol table.  */
 symtab * GTY(()) symbol_table;

 private:
 /* Pass-management.  */
 pass_manager * GTY((skip)) m_passes;

 /* Dump files.  */
 dump_manager * GTY((skip)) m_dumps;
 }; // class context

 } // namespace gcc

 /* The global singleton context aka "g".
  (the name is chosen to be easy to type in a debugger).  */
 extern GTY(()) gcc::context *g;



 gcc:context in created by g = ggc_cleared_alloc (); and
 g->symbol_table too.
 My problem is that during pg_pch_restore:
 #3  0x00850043 in gt_pch_restore (f=0x1ac9100) at
 ../../gcc/ggc-common.c:691

 When I add watch to *(&g), gcc::context *g is restored ^ and
 gcc:context::m_passes and gcc:context::m_dumps are set to an inaccessible
 address.

 Is my GGC construct correct?
>>>
>>> Back when we introduced the context and the pass_manager (called the
>>> "pipeline" in the initial patch submissions), those two classes were
>>> GTY-marked, but I reverted the change in r201887 (aka
>>> 5d068519b66a37ab391c427d0aac13f66a9b5c4e):
>>>
>>>  Revert my last two changes, r201865 and r201864
>>>   2013-08-20  David Malcolm  
>>>   Revert my last two changes, r201865 and r201864:
>>>   Revert r201865:
>>>  2013-08-20  David Malcolm  
>>>   Make opt_pass and gcc::pass_manager be GC-managed, so that
>>> pass
>>>  instances can own GC refs.
>>>   * Makefile.in (GTFILES): Add pass_manager.h and tree-pass.h.
>>>  * context.c (gcc::context::gt_ggc_mx): Traverse passes_.
>>>  (gcc::context::gt_pch_nx): Likewise.
>>>  (gcc::context::gt_pch_nx):  Likewise.
>>>  * ggc.h (gt_ggc_mx ): New.
>>>  (gt_pch_nx_with_op ): New.
>>>  (gt_pch_nx ): New.
>>>  * passes.c (opt_pass::gt_ggc_mx): New.
>>>  (opt_pass::gt_pch_nx): New.
>>>  (opt_pass::gt_pch_nx_with_op): New.
>>>  (pass_manager::gt_ggc_mx): New.
>>>  (pass_manager::gt_pch_nx): New.
>>>  (pass_manager::gt_pch_nx_with_op): New.
>>>  (pass_manager::operator new): Use
>>>  ggc_internal_cleared_alloc_stat rather than xcalloc.
>>>  * pass_manager.h (class pass_manager): Add GTY((user)) marking.
>>>  (pass_manager::gt_ggc_mx): New.
>>>  (pass_manager::gt_pch_nx): New.
>>>  (pass_manager::gt_pch_nx_with_op): New.
>>>  * tree-pass.h (class opt_pass): Add GTY((user)) marking.
>>>  (opt_pass::operator new): New.
>>>  (opt_pass::gt_ggc_mx): New.
>>>  (opt_pass::gt_pch_nx): New.
>>>  (opt_pass::gt_pch_nx_with_op): New.
>>>   Revert r201864:
>>>  2013-08-20  David Malcolm  
>>>   * Makefile.in (GTFILES): Add context.h.
>>>  * context.c (gcc::context::operator new): New.
>>>  (gcc::context::gt_ggc_mx): New.
>>>  (gcc::context::gt_pch_nx): New.
>>>  (gcc::context::gt_pch_nx): New.
>>>  * context.h (gcc::context): Add GTY((user)) marking.
>>>  (gcc::context::operator new): New.
>>>  (gcc::context::gt_ggc_mx): New.
>>>  (gcc::context::gt_pch_nx): New.
>>>  (gcc::context::gt_pch_nx): New.
>>>  (g): Add GTY marking.
>>>  (gt_ggc_mx (gcc::context *)): New.
>>>  (gt_pch_nx (gcc::context *)): New.
>>>  (gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
>>>  void *cookie)): New.
>>>  * gengtype.c (open_base_files) : Add context.h.
>>>
>>> Looking over the list archives, I found this reason for the revert:
>>> https://gcc.gnu.org/ml/gcc/2013-08/msg00214.html
>>> the integration of GTY into context and pass_manager wasn't fully-baked,
>>> and was causing PCH crashes.  Looks like I didn't go back and fully
>>> debug the issue; s

Re: C as intermediate language, signed integer overflow and -ftrapv

[Richard Biener]

On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes  wrote:
> On Thu, Jul 24 at 10:36 PM, Richard Biener  wrote:
>> Fact is that if somebody is interested in
>> -ftrapv he/she is welcome to contribute patches.  Especially testing
>> coverage is poor.
>
> As I said I have test programs for integer overflow (not written
> in C). Now I have converted one test program to C. This program
> checks if an int64_t overflow raises SIGABRT or SIGILL. The name of
> the program is chkovf64.c and I have uploaded it to
>
>   http://sourceforge.net/projects/seed7/files/
>
> It is licenced with GPL. You can use it to improve the testing
> coverage of gcc. When I compile it with:
>
>   gcc -ftrapv chkovf64.c -o chkovf64
>
> it writes a lot of warnings about "integer overflow in expression".
> Running chkovf64 shows that -ftrapv does not work correct.

That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893 - basically
as soon as we can constant-fold we lose the trap.  Which is probably
not important for practical purposes, but you have a point here.

Note the slight complication with static initializers that _do_ have
to simplify to something (well, maybe not with -ftrapv ...).  Joseph,
I can easily make fold fail if you don't explicitely use a constant
folding API (int_const_binop) and -ftrapv is set.  Is it valid to
reject

static int x = __INT_MAX__ + 1;

with an initializer-not-constant error?

Index: fold-const.c
===
--- fold-const.c(revision 212388)
+++ fold-const.c(working copy)
@@ -1121,7 +1121,12 @@
   STRIP_NOPS (arg2);

   if (TREE_CODE (arg1) == INTEGER_CST)
-return int_const_binop (code, arg1, arg2);
+{
+  tree res = int_const_binop (code, arg1, arg2);
+  if (res && TYPE_OVERFLOW_TRAPS (TREE_TYPE (arg1)) && TREE_OVERFLOW (res))
+return NULL_TREE;
+  return res;
+}

   if (TREE_CODE (arg1) == REAL_CST)
 {


> It seems that gcc thinks that writing a warning is enough and
> raising a signal at runtime is not necessary. For human
> programmers this makes sense, since they read the warnings and
> correct the code. But for generated C programs this is not the
> right strategy. There are different needs when C is used as
> intermediate language.
>
> Maybe all -ftrapv problems uncovered by chkovf64.c are because
> of this. Unfortunately there are also other test cases where
> a signal is not raised although a signed integer overflow occurred.
> This happens in a much bigger program and until now I was not
> able to create a simple test case from it.

Yes, not all optimizations may be aware of -ftrapv.

Richard.

> I used clang version 3.4-1 to proof that chkovf64.c works correct.
> When I compile it with:
>
>   clang -ftrapv chkovf64.c -o chkovf64
>
> and start chkovf64 afterwards it writes:
>
> Overflow checking of negation works correct.
> Overflow checking of addition works correct.
> Overflow checking of addition assignment works correct.
> Overflow checking of subtraction works correct.
> Overflow checking of subtraction assignment works correct.
> Overflow checking of incr works correct.
> Overflow checking of decr works correct.
> Overflow checking of multiplication works correct.
> Overflow checking of multiplication assignment works correct.
>
> Greetings Thomas Mertes
>
> --
> Seed7 Homepage:  http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.

Re: C as intermediate language, signed integer overflow and -ftrapv

[Richard Biener]

On Fri, Jul 25, 2014 at 12:35 PM, Richard Biener
 wrote:
> On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes  wrote:
>> On Thu, Jul 24 at 10:36 PM, Richard Biener  
>> wrote:
>>> Fact is that if somebody is interested in
>>> -ftrapv he/she is welcome to contribute patches.  Especially testing
>>> coverage is poor.
>>
>> As I said I have test programs for integer overflow (not written
>> in C). Now I have converted one test program to C. This program
>> checks if an int64_t overflow raises SIGABRT or SIGILL. The name of
>> the program is chkovf64.c and I have uploaded it to
>>
>>   http://sourceforge.net/projects/seed7/files/
>>
>> It is licenced with GPL. You can use it to improve the testing
>> coverage of gcc. When I compile it with:
>>
>>   gcc -ftrapv chkovf64.c -o chkovf64
>>
>> it writes a lot of warnings about "integer overflow in expression".
>> Running chkovf64 shows that -ftrapv does not work correct.
>
> That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893 - basically
> as soon as we can constant-fold we lose the trap.  Which is probably
> not important for practical purposes, but you have a point here.
>
> Note the slight complication with static initializers that _do_ have
> to simplify to something (well, maybe not with -ftrapv ...).  Joseph,
> I can easily make fold fail if you don't explicitely use a constant
> folding API (int_const_binop) and -ftrapv is set.  Is it valid to
> reject
>
> static int x = __INT_MAX__ + 1;
>
> with an initializer-not-constant error?
>
> Index: fold-const.c
> ===
> --- fold-const.c(revision 212388)
> +++ fold-const.c(working copy)
> @@ -1121,7 +1121,12 @@
>STRIP_NOPS (arg2);
>
>if (TREE_CODE (arg1) == INTEGER_CST)
> -return int_const_binop (code, arg1, arg2);
> +{
> +  tree res = int_const_binop (code, arg1, arg2);
> +  if (res && TYPE_OVERFLOW_TRAPS (TREE_TYPE (arg1)) && TREE_OVERFLOW 
> (res))
> +return NULL_TREE;
> +  return res;
> +}
>
>if (TREE_CODE (arg1) == REAL_CST)
>  {

Just checked and for

static int x = __INT_MAX__ + 1;
int main()
{
  return __INT_MAX__ + 1;
}

we still fold the initializer (and warn) but no longer warn about the overflow
in main() but generate a properly trapping call to __addvsi (at -O0, with
optimization CCP manages to constant fold this).

Richard.

>
>> It seems that gcc thinks that writing a warning is enough and
>> raising a signal at runtime is not necessary. For human
>> programmers this makes sense, since they read the warnings and
>> correct the code. But for generated C programs this is not the
>> right strategy. There are different needs when C is used as
>> intermediate language.
>>
>> Maybe all -ftrapv problems uncovered by chkovf64.c are because
>> of this. Unfortunately there are also other test cases where
>> a signal is not raised although a signed integer overflow occurred.
>> This happens in a much bigger program and until now I was not
>> able to create a simple test case from it.
>
> Yes, not all optimizations may be aware of -ftrapv.
>
> Richard.
>
>> I used clang version 3.4-1 to proof that chkovf64.c works correct.
>> When I compile it with:
>>
>>   clang -ftrapv chkovf64.c -o chkovf64
>>
>> and start chkovf64 afterwards it writes:
>>
>> Overflow checking of negation works correct.
>> Overflow checking of addition works correct.
>> Overflow checking of addition assignment works correct.
>> Overflow checking of subtraction works correct.
>> Overflow checking of subtraction assignment works correct.
>> Overflow checking of incr works correct.
>> Overflow checking of decr works correct.
>> Overflow checking of multiplication works correct.
>> Overflow checking of multiplication assignment works correct.
>>
>> Greetings Thomas Mertes
>>
>> --
>> Seed7 Homepage:  http://seed7.sourceforge.net
>> Seed7 - The extensible programming language: User defined statements
>> and operators, abstract data types, templates without special
>> syntax, OO with interfaces and multiple dispatch, statically typed,
>> interpreted or compiled, portable, runs under linux/unix/windows.

Re: C as intermediate language, signed integer overflow and -ftrapv

[Richard Biener]

On Fri, Jul 25, 2014 at 12:41 PM, Richard Biener
 wrote:
> On Fri, Jul 25, 2014 at 12:35 PM, Richard Biener
>  wrote:
>> On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes  wrote:
>>> On Thu, Jul 24 at 10:36 PM, Richard Biener  
>>> wrote:
 Fact is that if somebody is interested in
 -ftrapv he/she is welcome to contribute patches.  Especially testing
 coverage is poor.
>>>
>>> As I said I have test programs for integer overflow (not written
>>> in C). Now I have converted one test program to C. This program
>>> checks if an int64_t overflow raises SIGABRT or SIGILL. The name of
>>> the program is chkovf64.c and I have uploaded it to
>>>
>>>   http://sourceforge.net/projects/seed7/files/
>>>
>>> It is licenced with GPL. You can use it to improve the testing
>>> coverage of gcc. When I compile it with:
>>>
>>>   gcc -ftrapv chkovf64.c -o chkovf64
>>>
>>> it writes a lot of warnings about "integer overflow in expression".
>>> Running chkovf64 shows that -ftrapv does not work correct.
>>
>> That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893 - basically
>> as soon as we can constant-fold we lose the trap.  Which is probably
>> not important for practical purposes, but you have a point here.
>>
>> Note the slight complication with static initializers that _do_ have
>> to simplify to something (well, maybe not with -ftrapv ...).  Joseph,
>> I can easily make fold fail if you don't explicitely use a constant
>> folding API (int_const_binop) and -ftrapv is set.  Is it valid to
>> reject
>>
>> static int x = __INT_MAX__ + 1;
>>
>> with an initializer-not-constant error?
>>
>> Index: fold-const.c
>> ===
>> --- fold-const.c(revision 212388)
>> +++ fold-const.c(working copy)
>> @@ -1121,7 +1121,12 @@
>>STRIP_NOPS (arg2);
>>
>>if (TREE_CODE (arg1) == INTEGER_CST)
>> -return int_const_binop (code, arg1, arg2);
>> +{
>> +  tree res = int_const_binop (code, arg1, arg2);
>> +  if (res && TYPE_OVERFLOW_TRAPS (TREE_TYPE (arg1)) && TREE_OVERFLOW 
>> (res))
>> +return NULL_TREE;
>> +  return res;
>> +}
>>
>>if (TREE_CODE (arg1) == REAL_CST)
>>  {
>
> Just checked and for
>
> static int x = __INT_MAX__ + 1;
> int main()
> {
>   return __INT_MAX__ + 1;
> }
>
> we still fold the initializer (and warn) but no longer warn about the overflow
> in main() but generate a properly trapping call to __addvsi (at -O0, with
> optimization CCP manages to constant fold this).

Fixing that reveals

(insn 5 4 6 (set (reg:SI 4 si)
(const_int 1 [0x1])) t.c:7 -1
 (nil))

(insn 6 5 7 (set (reg:SI 5 di)
(const_int 2147483647 [0x7fff])) t.c:7 -1
 (nil))

(call_insn/u 7 6 8 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("__addvsi3") [flags 0x41]) [0  S1 A8])
(const_int 0 [0]))) t.c:7 -1
 (expr_list:REG_EH_REGION (const_int -2147483648 [0x8000])
(nil))
(expr_list (use (reg:SI 4 si))
(expr_list (use (reg:SI 5 di))
(nil

(insn 8 7 9 (set (reg:SI 86 [ D.1753 ])
(reg:SI 0 ax)) t.c:7 -1
 (expr_list:REG_EQUAL (plus:SI (const_int 2147483647 [0x7fff])
(const_int 1 [0x1]))
(nil)))

(note the REG_EQUAL note which CSE happily consumes).  We can just
omit the REG_EQUAL notes here which results in a working testcase.

Richard.

> Richard.
>
>>
>>> It seems that gcc thinks that writing a warning is enough and
>>> raising a signal at runtime is not necessary. For human
>>> programmers this makes sense, since they read the warnings and
>>> correct the code. But for generated C programs this is not the
>>> right strategy. There are different needs when C is used as
>>> intermediate language.
>>>
>>> Maybe all -ftrapv problems uncovered by chkovf64.c are because
>>> of this. Unfortunately there are also other test cases where
>>> a signal is not raised although a signed integer overflow occurred.
>>> This happens in a much bigger program and until now I was not
>>> able to create a simple test case from it.
>>
>> Yes, not all optimizations may be aware of -ftrapv.
>>
>> Richard.
>>
>>> I used clang version 3.4-1 to proof that chkovf64.c works correct.
>>> When I compile it with:
>>>
>>>   clang -ftrapv chkovf64.c -o chkovf64
>>>
>>> and start chkovf64 afterwards it writes:
>>>
>>> Overflow checking of negation works correct.
>>> Overflow checking of addition works correct.
>>> Overflow checking of addition assignment works correct.
>>> Overflow checking of subtraction works correct.
>>> Overflow checking of subtraction assignment works correct.
>>> Overflow checking of incr works correct.
>>> Overflow checking of decr works correct.
>>> Overflow checking of multiplication works correct.
>>> Overflow checking of multiplication assignment works correct.
>>>
>>> Greetings Thomas Mertes
>>>
>>> --
>>> Seed7 Homepage:  http://seed7.sourceforge.net
>>> Seed7 - The extensible programming language: Use

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Diego Novillo]

On Fri, Jul 25, 2014 at 5:42 AM, Ludovic Courtès
 wrote:
>
> "Joseph S. Myers"  skribis:
>
> > In accordance with GNU principles we should be making the videos available
> > without depending on non-free JavaScript as well (I don't know if Google+
> > makes videos readily available without JS or with only free JS).
>
> Agreed.  I would recommend making them available from
>  (people behind webmas...@gnu.org
> should be able to help.)

I think we all agree. As soon as Joseph finds me room for me to rsync
the 2013 videos, I'll start uploading. Once I publish the 2014 videos
on the GNU Tools page, I'll also upload the raw videos for him to
convert and publish on the FSF site.

Joseph, the 2013 videos have extension .MTS.


Diego.

Re: C as intermediate language, signed integer overflow and -ftrapv

[Joseph S. Myers]

On Fri, 25 Jul 2014, Richard Biener wrote:

> Note the slight complication with static initializers that _do_ have
> to simplify to something (well, maybe not with -ftrapv ...).  Joseph,
> I can easily make fold fail if you don't explicitely use a constant
> folding API (int_const_binop) and -ftrapv is set.  Is it valid to
> reject
> 
> static int x = __INT_MAX__ + 1;
> 
> with an initializer-not-constant error?

Yes - -pedantic-errors already gives an error there, as it should.  Of 
course

static int x = 1 ? 0 : __INT_MAX__ + 1;

must not give an error, whereas one is OK (and required with 
-pedantic-errors) for

static int x = 0 * (__INT_MAX__ + 1);

(one of the cases where the answer you get is the same as if C integers 
had an infinite range, where some people are less concerned about ensuring 
runtime errors occur - like e.g. x * 2 / 2 - I think the starting point 
should be generating such errors whenever overflow occurs in the 
abstract machine and then possibly having options to omit some such 
errors).

(I tend to the view that -ftrapv should map to 
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error so 
we only have the one implementation of these checks to get right and to 
optimize as much as possible.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Symtab node table introduction and GGC issues

[Jan Hubicka]

> > Hello,
> >thank you for you advice. It really looks that I face the same issue as
> > you seen. As you suggested, I will start with a global pointer to symtab and
> > we'll see further integration into context class (where it should reside
> > according to me).
> 
> Note that I would suggest an explicit marking function for this singleton
> (thus GTY((user))).  Most pointers of the symtab stuff doesn't need following
> but everything is held together by the single array/map?

symtab is streamed to PCH, sadly, so you need to have enough of anotation to get
pointers fixed up at stream in.

honza
> 
> Richard.
> 
> > Thanks,
> > Martin
> >
> >
> >>
> >> Hope this is helpful
> >> Dave
> >>
> >

Re: GNU Tools Cauldron 2014 - Slides for presentations

[Jason Self]

Ludovic Courtès said:
> Agreed.  I would recommend making them available from
>  (people behind webmas...@gnu.org
> should be able to help.)
>
> Thanks,
> Ludo’.

Actually, audio-vi...@gnu.org. :)


signature.asc
Description: PGP signature