Re: [GSoC] writing test-case

[Richard Biener]

On Sun, May 11, 2014 at 5:00 PM, Prathamesh Kulkarni
 wrote:
> On Sun, May 11, 2014 at 8:10 PM, Andreas Schwab  wrote:
>> Prathamesh Kulkarni  writes:
>>
>>> a) I am not able to follow why 3 slashes are required here
>>> in x_.\\\(D\\\) ? Why does x_.\(D\) not work ?
>>
>> Two of the three backslashes are eaten by the tcl parser.  But actually
>> only two backslashes are needed, since the parens are not special to tcl
>> (but are special to the regexp engine, so you want a single backslash
>> surviving the tcl parser).
>>
>>> b) The expression after folding would be of the form:
>>> t2_ = x_(D) - y_(D)
>>> I have used the operator "." in the pattern to match digit.
>>> While that works in the above case, I think a better
>>> idea would be to match using [0-9].
>>> I tried the following but it does not work:
>>> t_[0-9] = x_[0-9]\\\(D\\\) - y_[0-9]\\\(D\\\)
>>> Neither does \\\[ and \\\] work.
>>
>> Brackets are special in tcl (including inside double quotes), so they
>> need to be quoted.  But you want the brackets to appear unquoted to the
>> regexp engine, so a single backslash will do the Right Thing.
>>
>> See tcl(n) for the tcl parsing rules.
>>
> Thanks. Now I get it, the double backslash \\ is an escape sequence
> for \, and special characters like (, [
> retain their meaning in quotes, so to match input text: (D), the
> pattern has to be written as: "\\(D\\)".
> I believe "\(D\)" would only match D in the input ?
> I have modified the test-case. Is this version correct ?

I usually verify that by running the testcase in isolation on a GCC version
that should FAIL it and on one that should PASS it (tcl quoting is also
try-and-error for me most of the time...).

Thus I do

gcc/> make check-gcc RUNTESTFLAGS="tree-ssa.exp=match-2.c"


gcc/> make cc1
... compiles cc1 ...
gcc/> make check-gcc RUNTESTFLAGS="tree-ssa.exp=match-2.c"


A more complete matching for an SSA name would be (allowing
for SSA name versions > 9) _\\d\+ with \\(D\\) appended if
suitable (that's usually known from the testcase).  \\d\+ should match
at least one decimal digit.

Richard.

> Thanks and Regards,
> Prathamesh
>
>
>> Andreas.
>>
>> --
>> Andreas Schwab, sch...@linux-m68k.org
>> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
>> "And now for something completely different."

Is there any reason to use vfork() ?

[niXman]

Hi,

I use GCC to some restricted environment.
When I run gcc, it freezes up on this line[1]. When I replace the 
'vfork()' on the 'fork()' the compilation succeeds. I haven't found any 
other adverse events.


I'm curious whether there is reason to use 'vfork()' rather than 
'fork()'?


Thanks.


[1] 
https://gcc.gnu.org/viewcvs/gcc/trunk/libiberty/pex-unix.c?view=markup#l613



manpages:
http://linux.die.net/man/2/fork
http://linux.die.net/man/3/vfork

--
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___
Another online IDE: http://liveworkspace.org/

Live range shrinkage in pre-reload scheduling

[Kyrill Tkachov]

Hi all,

In haifa-sched.c (in rank_for_schedule) I notice that live range shrinkage is 
not performed when SCHED_PRESSURE_MODEL is used and the comment mentions that it 
results in much worse code.


Could anyone elaborate on this? Was it just empirically noticed on x86_64?

Thanks,
Kyrill

Re: Resurrecting -Wunreachable-code

[Florian Weimer]

On 05/08/2014 11:18 AM, Richard Biener wrote:


I plan to follow the Java rules, with necessary adjustments due to language
differences:



They are based on syntax (except for the infinite loop case), so they are
much more predictable from a developer perspective.

There are other warnings which benefit greatly from information collected
during optimization, but unreachable code doesn't.


Then I suggest to implement this warning in the frontends - as surely
you'll have differently modified "Java rules" for different frontends.


Go, Java (through ECJ) and possibly Ada already have such diagnostics 
anyway.



At the time a frontend calls cgraph_finalize_function () its AST is
supposed to be in GENERIC (+ FE extensions to GENERIC) form
(so for Fortran it's already lowered too much I guess).  So that could
be a (kind-of) common point to implement this for C/C++ at least.


It turns out that in C, all conditional control flow is lowered to 
COND_EXPR and gotos, too, so I had to hack a prototype into the parser. 
 With hindsight, C++ would have been the better starting point (despite 
the much more complex language) because the pre-GENERIC trees seem to 
preserve more control flow statements.


I'm attaching the patch I've been playing with, but I feel that it takes 
us into the wrong direction, towards more parser hacks and global state.


The patch implements a single-pass analysis over source code constructs, 
implementing the following rules:


  * Code after an if statement is unreachable if neither branch
completes normally.  (Compile-time constants are not evaluated, just
as in Java.)
  * Code after an infinite loop (with a constant condition and no break
statements) is unreachable.
  * Code after a return statement is unreachable.
  * Code after an Objective-C try/catch/finally statement is unreachable
if the try and catch branches do not complete normally.
  * Function starts and (case) labels are always unreachable.
  * Loop starts are reachable if the loop contains a label or case
label.

I compiled some code with this patch and, in addition to real issues in 
the code being compiled, identified a couple of patterns that need 
recognizing and fixing for a production-quality implementation (the 
patch has failing test cases for many of these):


  * noreturn function calls and expressions need warnings (if there
value is used, but see below for an exception) and trigger
loss of reachability (if used as a statement expression).
  * Warn about an unreachable conditional expression in do-while,
with a special case for do-...-while (0).
  * An unreachable dummy return in functions not returning void to
suppress warnings from other compilers should not receive a warning.
(A dummy return would have zero constant or null pointer constant
as argument.  More involved expressions would still trigger
a warning, and so would returns which aren't the last statement
in a function.)
  * A return statement containing a call expression targeting a
noreturn function should not receive a warning (again suppression
of compiler warnings).
  * Warnings should not be generated for common assert()-style macros
in unreachable positions.

Expression-related warnings could be implemented on top of the existing 
trees, I think (but statement expressions might complicate matters).  I 
could add more state tracking for the assert() handling, but it would be 
so much easier to implement on ASTs with a strong relationship to source 
code.


I'm not sure how to proceed.  Are there plans to move the C and C++ 
front ends to more concrete ASTs?  Would we be willing to accept a 
slight performance hit from that?


--
Florian Weimer / Red Hat Product Security Team
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 7aa9e23..d10c3d0 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -777,6 +777,10 @@ Wunknown-pragmas
 C ObjC C++ ObjC++ Warning Var(warn_unknown_pragmas) LangEnabledBy(C ObjC C++ ObjC++,Wall, 1, 0)
 Warn about unrecognized pragmas
 
+Wunreachable-code
+C ObjC Warning Var(warn_unreachable_code) LangEnabledBy(C ObjC,Wall, 1, 0)
+Warn about unreachable code
+
 Wunsuffixed-float-constants
 C ObjC Var(warn_unsuffixed_float_constants) Warning
 Warn about unsuffixed float constants
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index 3abf6b9..907bdef 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -118,10 +118,6 @@ struct obstack parser_obstack;
 
 static GTY(()) struct stmt_tree_s c_stmt_tree;
 
-/* State saving variables.  */
-tree c_break_label;
-tree c_cont_label;
-
 /* A list of decls to be made automatically visible in each file scope.  */
 static GTY(()) tree visible_builtins;
 
@@ -7869,11 +7865,8 @@ start_function (struct c_declspecs *declspecs, struct c_declarator *declarator,
   current_function_returns_abnormally = 0;
   warn_about_return_type = 0;
   c_switch_stac

requisites for soft-fp support for a new target

[Sheheryar Zahoor Qazi]

Hi,
I am working on an 18-bit opensource soft-core processor at my
university. My task is to emulate floating point operation since there
is no hardware unit for float operations. I have the cross compiler
and binutils for my target. But upon calling atest program, it gives
the following error:

: In function `test':
(.text+0x0): undefined reference to `__floatsisf'
 In function `test':
: In function `test':
(.text+0x2c): undefined reference to `__mulsf3'
: In function `test':
(.text+0x2e): undefined reference to `__fixsfsi'

I realize there needs a machine dependent sfp-machine.h file and I
have it for my architecture modified. Can anyone explain me the
changes required to be make in the config.gcc file to link my target
to soft-fp libraries? and do I need any more changes in gcc build?

Thanks

Sheheryar

Re: Is there any reason to use vfork() ?

[pinskia]

> On May 13, 2014, at 3:12 AM, niXman  wrote:
> 
> 
> Hi,
> 
> I use GCC to some restricted environment.

Can you share more information about this env. It might be a bug not in gcc. 

> When I run gcc, it freezes up on this line[1]. When I replace the 'vfork()' 
> on the 'fork()' the compilation succeeds. I haven't found any other adverse 
> events.
> 
> I'm curious whether there is reason to use 'vfork()' rather than 'fork()'?

The difference is that right after vfork, the only thing valid to do is exec. 
Vfork in some (not most any more) Unix has less overhead than fork has. 

Thanks,
Andrew

> 
> Thanks.
> 
> 
> [1] 
> https://gcc.gnu.org/viewcvs/gcc/trunk/libiberty/pex-unix.c?view=markup#l613
> 
> 
> manpages:
> http://linux.die.net/man/2/fork
> http://linux.die.net/man/3/vfork
> 
> -- 
> Regards, niXman
> ___
> Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
> http://sourceforge.net/projects/mingw-w64/
> ___
> Another online IDE: http://liveworkspace.org/

Re: Is there any reason to use vfork() ?

[niXman]

pinskia 2014-05-13 18:47:

Can you share more information about this env.

This is specially built distributive used for micro-pc.


It might be a bug not in gcc.
I'm sure that the bug not in the GCC. After I wrote to this ML I made 
sure that freezes any program using 'vfork()'. I'll deal with it ...
I just wanted to understand the reasons to use 'vfork()' instead of 
'fork()'.



--
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___
Another online IDE: http://liveworkspace.org/

Re: Is there any reason to use vfork() ?

[Michael N. Moran]

On 05/13/2014 10:59 AM, niXman wrote:

pinskia 2014-05-13 18:47:

Can you share more information about this env.

This is specially built distributive used for micro-pc.


It might be a bug not in gcc.

I'm sure that the bug not in the GCC. After I wrote to this
ML I made sure that freezes any program using 'vfork()'.
I'll deal with it ...
I just wanted to understand the reasons to use 'vfork()'
instead of 'fork()'.


I cannot speak for GCC, but I work with embedded Linux
systems and we use vfork() to reduce the memory footprint
of child processes. When a process is created with
fork() it's memory footprint is the same as the parent
process (copied page tables). The same is not true with
vfork().

This is particularly important in the embedded systems
space with limited RAM.

Consider the system RAM requirements for a parent process
with a large RAM footprint that needs to spawn a child
process with an otherwise much smaller RAM footprint.


--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org

The Beatles were wrong: 1 & 1 & 1 is 1

Re: Live range shrinkage in pre-reload scheduling

[Maxim Kuvyrkov]

On May 13, 2014, at 10:27 PM, Kyrill Tkachov  wrote:

> Hi all,
> 
> In haifa-sched.c (in rank_for_schedule) I notice that live range shrinkage is 
> not performed when SCHED_PRESSURE_MODEL is used and the comment mentions that 
> it results in much worse code.
> 
> Could anyone elaborate on this? Was it just empirically noticed on x86_64?

+ Richard Sandiford who wrote SCHED_PRESSURE_MODEL

--
Maxim Kuvyrkov
www.linaro.org

Re: Is there any reason to use vfork() ?

[David Brown]

On 13/05/14 17:47, Michael N. Moran wrote:

On 05/13/2014 10:59 AM, niXman wrote:

pinskia 2014-05-13 18:47:

Can you share more information about this env.

This is specially built distributive used for micro-pc.


It might be a bug not in gcc.

I'm sure that the bug not in the GCC. After I wrote to this
ML I made sure that freezes any program using 'vfork()'.
I'll deal with it ...
I just wanted to understand the reasons to use 'vfork()'
instead of 'fork()'.


I cannot speak for GCC, but I work with embedded Linux
systems and we use vfork() to reduce the memory footprint
of child processes. When a process is created with
fork() it's memory footprint is the same as the parent
process (copied page tables). The same is not true with
vfork().

This is particularly important in the embedded systems
space with limited RAM.

Consider the system RAM requirements for a parent process
with a large RAM footprint that needs to spawn a child
process with an otherwise much smaller RAM footprint.




It can also make a big difference if the MMU is limited, or slow to work 
with (as can be the case in embedded Linux systems), since you don't 
need copy-on-write for vfork().  This is particularly true for ucLinux 
on embedded systems without an MMU, in which fork() does not exist and 
you have to use vfork().


Of course, you are not likely to run gcc on such systems.

However, I believe that vfork() is much more efficient than fork() on 
Windows, because Windows does not have a proper fork() equivalent.  If I 
am correct in this, then this would make a big difference to 
Windows-hosted gcc.

Re: Is there any reason to use vfork() ?

[David Brown]

On 13/05/14 17:47, Michael N. Moran wrote:

On 05/13/2014 10:59 AM, niXman wrote:

pinskia 2014-05-13 18:47:

Can you share more information about this env.

This is specially built distributive used for micro-pc.


It might be a bug not in gcc.

I'm sure that the bug not in the GCC. After I wrote to this
ML I made sure that freezes any program using 'vfork()'.
I'll deal with it ...
I just wanted to understand the reasons to use 'vfork()'
instead of 'fork()'.


I cannot speak for GCC, but I work with embedded Linux
systems and we use vfork() to reduce the memory footprint
of child processes. When a process is created with
fork() it's memory footprint is the same as the parent
process (copied page tables). The same is not true with
vfork().

This is particularly important in the embedded systems
space with limited RAM.

Consider the system RAM requirements for a parent process
with a large RAM footprint that needs to spawn a child
process with an otherwise much smaller RAM footprint.




It can also make a big difference if the MMU is limited, or slow to work 
with (as can be the case in embedded Linux systems), since you don't 
need copy-on-write for vfork().  This is particularly true for ucLinux 
on embedded systems without an MMU, in which fork() does not exist and 
you have to use vfork().


Of course, you are not likely to run gcc on such systems.

However, I believe that vfork() is much more efficient than fork() on 
Windows, because Windows does not have a proper fork() equivalent.  If I 
am correct in this, then this would make a big difference to 
Windows-hosted gcc.

Re: [GSoC] writing test-case

[Prathamesh Kulkarni]

On Tue, May 13, 2014 at 2:36 PM, Richard Biener
 wrote:
> On Sun, May 11, 2014 at 5:00 PM, Prathamesh Kulkarni
>  wrote:
>> On Sun, May 11, 2014 at 8:10 PM, Andreas Schwab  
>> wrote:
>>> Prathamesh Kulkarni  writes:
>>>
 a) I am not able to follow why 3 slashes are required here
 in x_.\\\(D\\\) ? Why does x_.\(D\) not work ?
>>>
>>> Two of the three backslashes are eaten by the tcl parser.  But actually
>>> only two backslashes are needed, since the parens are not special to tcl
>>> (but are special to the regexp engine, so you want a single backslash
>>> surviving the tcl parser).
>>>
 b) The expression after folding would be of the form:
 t2_ = x_(D) - y_(D)
 I have used the operator "." in the pattern to match digit.
 While that works in the above case, I think a better
 idea would be to match using [0-9].
 I tried the following but it does not work:
 t_[0-9] = x_[0-9]\\\(D\\\) - y_[0-9]\\\(D\\\)
 Neither does \\\[ and \\\] work.
>>>
>>> Brackets are special in tcl (including inside double quotes), so they
>>> need to be quoted.  But you want the brackets to appear unquoted to the
>>> regexp engine, so a single backslash will do the Right Thing.
>>>
>>> See tcl(n) for the tcl parsing rules.
>>>
>> Thanks. Now I get it, the double backslash \\ is an escape sequence
>> for \, and special characters like (, [
>> retain their meaning in quotes, so to match input text: (D), the
>> pattern has to be written as: "\\(D\\)".
>> I believe "\(D\)" would only match D in the input ?
>> I have modified the test-case. Is this version correct ?
>
> I usually verify that by running the testcase in isolation on a GCC version
> that should FAIL it and on one that should PASS it (tcl quoting is also
> try-and-error for me most of the time...).
>
> Thus I do
>
> gcc/> make check-gcc RUNTESTFLAGS="tree-ssa.exp=match-2.c"
> 
> 
> gcc/> make cc1
> ... compiles cc1 ...
> gcc/> make check-gcc RUNTESTFLAGS="tree-ssa.exp=match-2.c"
> 
>
> A more complete matching for an SSA name would be (allowing
> for SSA name versions > 9) _\\d\+ with \\(D\\) appended if
> suitable (that's usually known from the testcase).  \\d\+ should match
> at least one decimal digit.
I thought that SSA name version wouldn't exceed 9 for that test-case,
so I decided for matching only one digit. I will change it to match
one or more digits.

* I have written test-cases for patterns in match.pd (attached patch), which
result in PASS. Could you review them for me ?
I couldn't write for following ones:

1] Patterns involving COMPLEX_EXPR, REALPART_EXPR, IMAGPART_EXPR
(match_and_simplify
  (complex (realpart @0) (imagpart @0))
  @0)
(match_and_simplify
  (realpart (complex @0 @1))
  @0)
(match_and_simplify
  (imagpart (complex @0 @1))
  @1)

Sorry to be daft, but I couldn't understand what these patterns meant
(I know complex numbers).
Could you give an example that matches one of these patterns ?
Thanks.

2] Test-case for FMA_EXPR. I am not sure how to generate FMA_EXPR from C code.
(match_and_simplify
  (fma INTEGER_CST_P@0 INTEGER_CST_P@1 @3)
  (plus (mult @0 @1) @3))

3] Test-case for COND_EXPR
(match_and_simplify
  (cond (bit_not @0) @1 @2)
  (cond @0 @2 @1))

I believe cond corresponds to C's ternary operator ?
However c-expression of the form:
t2 = (x ? y : z)
gets translated to gimple as an if-else statement, with "x" being condition,
"y" being then-statement, and "z" being else-statement.
So I guess we need to handle this case specially in genmatch ?
Or am I mistaken ?

* I added few patterns from TODO list in match.pd. I am
not sure how to write pattern for the following transform:
(T) (P + A) - (T) P -> (T) A

* ICE for transform sqrt (x * x) -> x
The following pattern results in ICE (gimple-match-head.c:546)
(match_and_simplify
  (built_in_sqrt (mult @0 @0))
  @0)

I triggered the pattern with this test-case:
double foo(double x)
{
  double t1, t2;
  t1 = x * x;
  t2 = sqrt (t1);
  return t2;
}

This happens because the following assert fails in
bool gimple_match_and_simplify (gimple_stmt_iterator *gsi, tree
(*valueize)(tree)): line 546:
gcc_assert (gimple_seq_singleton_p (tail));

I guess that happens because for the above pattern
maybe_push_res_to_seq() returns ops[0], and tail remains NULL.

if (TREE_CODE_LENGTH ((tree_code) rcode) == 0
   && is_gimple_val (ops[0]))
 return ops[0];

Unfortunately, I couldn't find a fix.
I have a couple of questions regarding gimple-match-head.c

a) Why do we return if the above condition is true ?
I mean why don't we want gimple_build_assign_with_ops to be called
if that's true ?
Removing that condition in maybe_push_res_to_seq or calling
gimple_build_assign_with_ops (rcode, lhs, ops[0], NULL_TREE, NULL_TREE,
 NULL_TREE);
from gimple_match_and_simplify (if maybe_push_res_to_seq returns ops[0]),
resulted in verify_ssa failed: missing definition.

b) In
static bool
gimple_match_and_simplify (gimple stmt,