Re: [RFC] PR61300 K&R incoming args

[Richard Biener]

On June 2, 2014 11:30:20 PM CEST, "Joseph S. Myers"  
wrote:
>On Mon, 2 Jun 2014, Florian Weimer wrote:
>
>> On 05/31/2014 08:56 AM, Alan Modra wrote:
>> 
>> > > It's fine to change ABI when compiling an old-style function
>> > > definition for which a prototype exists (relative to the
>> > > non-prototype case).  It happens on i386, too.
>> > 
>> > That might be so, but when compiling the function body you must
>assume
>> > the worst case, whatever that might be, at the call site.  For K&R
>> > code, our error was to assume the call was unprototyped (which
>> > paradoxically is the best case) when compiling the function body.
>> 
>> Is this really a supported use case?  I think I remember tracking
>down a bug
>> which was related to a lack of float -> double promotion because the
>call was
>> prototyped, and the old-style function definition wasn't.  This would
>have
>> been on, ugh, SPARC.  I think this happened only in certain cases
>(float
>> arguments, probably).
>
>ISO C (right back to C90) requires a prototype in scope if a variadic 
>function, or a function whose definition has prototyped argument types 
>changed by the default argument promotions (such as float and short),
>is 
>called.
>
>It probably makes sense by now to enable
>-Wimplicit-function-declaration 
>by default, though that won't catch cases where the file with the 
>unprototyped call has a non-prototype declaration such as "int foo();".

There is an old patch of mine warning for this case...  Google for 
-Wunprototyped-calls

Richard.

Re: [GSoC] How to get started with the isl code generation

[Tobias Grosser]

On 01/06/2014 01:21, Roman Gareev wrote:

Hi Tobias,


Allright. It seems you understood the tree traversel. For the actual
patch that we want to commit, let's leave it out for now.  Instead,
let's try to get a minimal patch that only adds the flag and the new
file for the isl_ast stuff. In case the isl is choosen as code
generation option, the cloog pass is disabled (they would otherwise get
into their way later) and we dump the ast. We also need a simple test case
that checks that the dump is generated.


What do you mean by simple test case that checks that the dump is
generated? Is it checking of the dump_flags?


I mean that we verify that the dump that is created contains a printed
AST that matches the one we expect.

for (int c1 = 0; c1 < n - 1; c1 += 1)
  for (int c3 = 0; c3 < n; c3 += 1)
S_5(c1, c3);


Instead of adding this functionality to gloog() I would create a
semilar function that provides the functionality gloog has for the isl
codegen counterpart. -fgraphite-code-generator switches then between
these two functions. To start with the isl counterpart is almost empty.
It just contains the parts of this patch needed for printing. When we
add more functionality and we encounter reuse opportunities, we can move
parts of graphite-clast-to-gimple.c into a generic codegen file.

What do you think?


I think that it's good. It would help to begin removing of CLooG
dependency and make the file with generation of ISL AST easier to
maintain. I implemented it in the patch, which can be found below. You
can also find my post about my second task of the proposal at the
following link http://romangareev.blogspot.com/2014/05/gsoc-report-ii.html


Nice post.


diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e74bb67..39cb7bd 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1250,6 +1250,7 @@ OBJS = \
graphite.o \
graphite-blocking.o \
graphite-clast-to-gimple.o \
+   graphite-isl-ast-to-gimple.o \
graphite-dependences.o \
graphite-interchange.o \
graphite-optimize-isl.o \
diff --git a/gcc/common.opt b/gcc/common.opt
index 5c3f834..731aaf5 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1250,6 +1250,19 @@ fgraphite-identity
 Common Report Var(flag_graphite_identity) Optimization
 Enable Graphite Identity transformation

+fgraphite-code-generator=
+Common Report RejectNegative Joined Optimization Enum(fgraphite_generator) 
Var(flag_graphite_code_gen) Init(FGRAPHITE_CODE_GEN_CLOOG)
+Choose code generator of Graphite
+
+Enum
+Name(fgraphite_generator) Type(enum fgraphite_generator) UnknownError(unknown 
code generator of graphite %qs)
+
+EnumValue
+Enum(fgraphite_generator) String(isl) Value(FGRAPHITE_CODE_GEN_ISL)
+
+EnumValue
+Enum(fgraphite_generator) String(cloog) Value(FGRAPHITE_CODE_GEN_CLOOG)


Nice.


+#include "config.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "system.h"
+#include "coretypes.h"
+#include "diagnostic-core.h"
+#include "tree.h"
+#include "basic-block.h"
+#include "tree-ssa-alias.h"
+#include "internal-fn.h"
+#include "gimple-expr.h"
+#include "is-a.h"
+#include "gimple.h"
+#include "gimple-iterator.h"
+#include "gimplify-me.h"
+#include "gimple-ssa.h"
+#include "tree-ssa-loop-manip.h"
+#include "tree-ssa-loop.h"
+#include "tree-into-ssa.h"
+#include "tree-pass.h"
+#include "cfgloop.h"
+#include "tree-chrec.h"
+#include "tree-data-ref.h"
+#include "tree-scalar-evolution.h"
+#include "sese.h"
+
+#include "graphite-poly.h"
+#include "graphite-isl-ast-to-gimple.h"
+#include "graphite-htab.h"


Are these the minimal includes necessary?


+
+/* This flag is set when an error occurred during the translation of
+   ISL AST to Gimple.  */
+
+static bool isl_gloog_error;
+
+/* Prints NODE to FILE.  */
+
+void
+print_isl_ast_node (FILE *file, __isl_keep isl_ast_node *node,
+   __isl_keep isl_ctx *ctx)
+{
+  isl_printer *prn = isl_printer_to_file (ctx, file);
+  prn = isl_printer_set_output_format (prn, ISL_FORMAT_C);
+  prn = isl_printer_print_ast_node (prn, node);
+  prn = isl_printer_print_str (prn, "\n");
+  isl_printer_free (prn);
+}
+
+/* Generates a build, which specifies the constraints on the parameters. */
+
+static isl_ast_build *
+generate_isl_context (scop_p scop)
+{
+  isl_set * context_isl = isl_set_params (isl_set_copy (scop->context));
+  return isl_ast_build_from_context (context_isl);
+}
+
+/* Generates a schedule, which specifies an order used to
+   visit elements in a domain. */
+
+static isl_union_map *
+generate_isl_schedule (scop_p scop)
+{
+  int i;
+  poly_bb_p pbb;
+  isl_union_map *schedule_isl =
+isl_union_map_empty (isl_set_get_space (scop->context));
+
+  FOR_EACH_VEC_ELT (SCOP_BBS (scop), i, pbb)
+{
+  /* Dead code elimination: when the domain of a PBB is empty,
+don't generate code for the PBB.  */
+  if (isl_set_is_empty (pbb->domain))
+   continue;
+
+  isl_map *bb_schedule = isl_map_

Re: FloatingPointMath and transformations

[Jonathan Wakely]

On 3 June 2014 01:47, Vincent Lefevre wrote:
> On 2014-06-02 10:33:37 -0400, Geert Bosch wrote:
>> It should, or it would be a bug. Please feel free to add/correct
>> anything on this page.
>
> I am not a member of EditorGroup.

That's easy to fix, email me your username.

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

[Matthias Klose]

Am 02.06.2014 22:30, schrieb Eric Botcazou:
>> I have successfully built without the switch, but I am not sure of the
>> effects at runtime.
> 
> For sure libitm cannot work, there is a 'flushw' in config/sparc/sjlj.S.
> 
>> If V9 is indeed required, is there a way to build without those libs? Or
>> has pre V9 support been dropped at some point?
> 
> No, V8 is still supported, but nobody has ported the libraries to it.
> 
>> IMHO an efficiency enhancement should not prevent running less
>> efficiently on a supported architecture. If target triple is
>> sparcv9-*-*, the next case will match and will add the "-mcpu=v9" to
>> XCFLAGS, but adding it for non-v9 sparc-*-* targets is at least weird.
> 
> Well, V9 is about 20 years old now so defaulting to it is not unreasonable, 
> especially for all the native OSes.  But patches are of course welcome.

V9 is currently bound to 64bit, you can't build a sparc-linux-gnu compiler
defaulting to V9 without patches.  But anyway, Debian did drop the sparc port
two months ago anyway.

  Matthias

Re: Cross-testing libsanitizer

[Christophe Lyon]

On 3 June 2014 08:39, Yury Gribov  wrote:
> Christophe,
>
>
>> Indeed, when testing on my laptop, execution tests fail because
>> libsanitizer wants to allocated 8GB of memory (I am using qemu as
>> execution engine).
>
> Is this 8G of RAM? If yes - I'd be curious to know which part of
> libsanitizer needs so much memory.
>
> -Y

Here is what I have in gcc.log:
==12356==ERROR: AddressSanitizer failed to allocate 0x21000
(8589938688) bytes at address ff000 (errno: 12)^M
==12356==ReserveShadowMemoryRange failed while trying to map
0x21000 bytes. Perhaps you're using ulimit -v^M
qemu: uncaught target signal 6 (Aborted) - core dumped^M
proot info: pid 12356: terminated with signal 6^M
FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test

and ulimit -a says:
virtual memory  (kbytes, -v) unlimited

Christophe

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

[Eric Botcazou]

> V9 is currently bound to 64bit, you can't build a sparc-linux-gnu compiler
> defaulting to V9 without patches.

libitm was tested on SPARC/Linux though.

-- 
Eric Botcazou

Re: Cross-testing libsanitizer

[Yury Gribov]

Is this 8G of RAM? If yes - I'd be curious to know which part of
libsanitizer needs so much memory.


Here is what I have in gcc.log:
==12356==ERROR: AddressSanitizer failed to allocate 0x21000
(8589938688) bytes at address ff000 (errno: 12)^M
==12356==ReserveShadowMemoryRange failed while trying to map
0x21000 bytes. Perhaps you're using ulimit -v^M


Interesting. AFAIK Asan maps shadow memory with NORESERVE flag so it 
should not consume any RAM at all...


-Y

Re: lib{atomic, itm}/configure.tgt uses -mcpu=v9 as default for sparc

[Carlos Sánchez de La Lama]

>> IMHO an efficiency enhancement should not prevent running less
>> efficiently on a supported architecture. If target triple is
>> sparcv9-*-*, the next case will match and will add the "-mcpu=v9" to
>> XCFLAGS, but adding it for non-v9 sparc-*-* targets is at least weird.
>
> Well, V9 is about 20 years old now so defaulting to it is not unreasonable, 
> especially for all the native OSes.  But patches are of course
> welcome.

You might be right. My point was if target was not v9, configure should
take care of whatever is needed to build a working compiler (and target
libraries) without passing extra switches (probably setting UNSUPPORTED
in sparc-*-* cases of configure.tgt).

However, I have got the latest config.guess from git and now I see
sparc-*-* is not enough to ensure v7 or v8, but it is also a valid
triple for v9 targets, so there is no way to configure script to know if
it can use v9 or not, and just avoiding v9 optimizationes in all SPARC
compilers is clearly wrong. So I agree defaulting to v9 is correct.

I will build with the suggested disable switches. Thank you!

Carlos

Re: Cross-testing libsanitizer

[Florian Weimer]

On 06/03/2014 12:16 PM, Yury Gribov wrote:

Is this 8G of RAM? If yes - I'd be curious to know which part of
libsanitizer needs so much memory.


Here is what I have in gcc.log:
==12356==ERROR: AddressSanitizer failed to allocate 0x21000
(8589938688) bytes at address ff000 (errno: 12)^M
==12356==ReserveShadowMemoryRange failed while trying to map
0x21000 bytes. Perhaps you're using ulimit -v^M


Interesting. AFAIK Asan maps shadow memory with NORESERVE flag so it
should not consume any RAM at all...


Even NORESERVE mappings count towards the commit limit.  You'd need to 
map with PROT_NONE in order to avoid that.


At present, it is necessary to run with vm.overcommit_memory=0 (or 1), 
with vm.overcommit_memory=2, there will be test suite failures.  I 
suspect that there is a possibility to hit this on loaded systems even 
with vm.overcommit_memory=0.


--
Florian Weimer / Red Hat Product Security Team

Re: Cross-testing libsanitizer

[Christophe Lyon]

On 3 June 2014 12:16, Yury Gribov  wrote:
>>> Is this 8G of RAM? If yes - I'd be curious to know which part of
>>> libsanitizer needs so much memory.
>>
>>
>> Here is what I have in gcc.log:
>> ==12356==ERROR: AddressSanitizer failed to allocate 0x21000
>> (8589938688) bytes at address ff000 (errno: 12)^M
>> ==12356==ReserveShadowMemoryRange failed while trying to map
>> 0x21000 bytes. Perhaps you're using ulimit -v^M
>
>
> Interesting. AFAIK Asan maps shadow memory with NORESERVE flag so it should
> not consume any RAM at all...
>

Thanks for the reminder in fact I posted a qemu patch in February
http://lists.gnu.org/archive/html/qemu-devel/2014-02/msg00319.html
I thought it was applied, but it's not yet in trunk

I used to use a patched qemu, but when I upgraded to 2.0 I forgot
about this patch.
I am going to re-check with a patched qemu, and ping them.

Re: How can I generate a new function at compile time?

[Benedikt Huber]

I have not found out why the assertion is violated, yet.
However I noticed that the original function disappears somehow between
the passes pass_ipa_comdats and pass_fixup_cfg.
By that I mean that the function appears from the dump files.
These passes run several passes after the outlining pass.
Between the outlining pass and pass_ipa_comdats both functions
(the generated and the original with the call to the generated) are printed.
I do not know whether this has anything to do with the assertion but it
seems strange.
Do you have any guess why this happens?

Thank you,
Benedikt

On 28 May 2014, at 15:50, Richard Biener  wrote:

> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
>  wrote:
>> I ported the pass to the fsf trunk. It is built with —enable-checking.
>> The patch applied with no changes and also the behaviour is the same.
>> So I probably mess up the cfg somehow.
>> Can you suggest any strategy for finding the problem that I could use?
>> 
>> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
>> -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
>> -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
>> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
>> purge_dead_edges, at cfgrtl.c:3179
>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>> ^
>> 0x681195 purge_dead_edges(basic_block_def*)
>>../../src/gcc/cfgrtl.c:3179
>> 0xe64d8a find_bb_boundaries
>>../../src/gcc/cfgbuild.c:522
>> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
>>../../src/gcc/cfgbuild.c:604
>> 0x66e689 execute
>>../../src/gcc/cfgexpand.c:5905
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
> 
> Well, look at the CFG and see if it makes sense and why it expects
> a single successor and why there is none.  Basically, work back
> from the ICE ...
> 
> Richard.
> 
>> Best regards,
>> Benedikt
>> 
>> On 27 May 2014, at 17:35, Benedikt Huber 
>>  wrote:
>> 
>>> 
>>> On 27 May 2014, at 17:25, Richard Biener  wrote:
>>> 
 On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
  wrote:
> 
> On 27 May 2014, at 17:09, Richard Biener  
> wrote:
> 
>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>>  wrote:
>>> (Sorry for the duplicate.)
>>> 
>>> I managed to pass the needed parameters to the generated function.
>>> However I cannot pin down the reason why the compilation fails.
>>> It seems that the cfg is somehow broken, but I cannot tell how.
>>> Do you have any debugging hints?
>>> 
>>> As far as I can tell, the cfg is changed during the generation of the 
>>> preheader
>>> (I do this to find the entry block easily.)
>>> and in the function move_sese_region_to_fn.
>>> 
>>> I noticed that after pass 058t.copyrename2 the original function bar 
>>> disappears
>>> and the new function is replaced by _GLOBAL__N_bar.constprop, could 
>>> this have
>>> anything to do with the problem?
>> 
>> Unlikely.  You can disable that by using -fno-ipa-cp.
>> 
>>> The pass runs just after the construction of cfg,  outline.c.011t.cfg.
>>> 
>>> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src -c 
>>> -fdump-tree-all-details -fdump-ipa-all-details -fdump-rtl-all-details 
>>> -funinline-innermost-loops -Wall -Wextra 
>>> /home/bhuber/sandbox/try/outline.c
>>> /home/bhuber/sandbox/try/outline.c: In function 
>>> '_GLOBAL__N_bar.constprop':
>>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
>>> purge_dead_edges, at cfgrtl.c:3183
>> 
>> the line doesn't match anything that would ICE on current trunk, but I 
>> suppose
>> it's the single_succ_p assert that triggers?
> Yes, that is right, it is
> 
> gcc_assert (single_succ_p (bb));
> 
>> 
>> Either you really got until RTL generation or somehow cfgrtl cfg hooks 
>> are
>> still active while you are working in your pass.
> 
> The pass that fails, according to the dump files is outline.c.174r.expand
> So it already tries to generate RTL.
> My problem is that there are so many passes in
> between, that I do not know where to start looking.
> Any idea?
 
 What code-base are you developing on?  Do you build with checking
 enabled (--enable-checking, the default on trunk but not on release 
 branches).
>>> 
>>> It is a linaro branch, but I am going to port the pass to the fsf trunk and 
>>> see
>>> whether the behaviour changes.
>>> 
>>> Best regards,
>>> Benedikt
>>> 
 
 Richard.
 
>> 
>> Richard.
>> 
>>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>>

Re: How can I generate a new function at compile time?

[Richard Biener]

On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
 wrote:
>
> I have not found out why the assertion is violated, yet.
> However I noticed that the original function disappears somehow between
> the passes pass_ipa_comdats and pass_fixup_cfg.
> By that I mean that the function appears from the dump files.
> These passes run several passes after the outlining pass.
> Between the outlining pass and pass_ipa_comdats both functions
> (the generated and the original with the call to the generated) are printed.
> I do not know whether this has anything to do with the assertion but it
> seems strange.
> Do you have any guess why this happens?

It probably vanishes because this is the function you ICE for?

> Thank you,
> Benedikt
>
> On 28 May 2014, at 15:50, Richard Biener  wrote:
>
>> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
>>  wrote:
>>> I ported the pass to the fsf trunk. It is built with —enable-checking.
>>> The patch applied with no changes and also the behaviour is the same.
>>> So I probably mess up the cfg somehow.
>>> Can you suggest any strategy for finding the problem that I could use?
>>>
>>> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
>>> -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
>>> -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
>>> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
>>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
>>> purge_dead_edges, at cfgrtl.c:3179
>>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>>> ^
>>> 0x681195 purge_dead_edges(basic_block_def*)
>>>../../src/gcc/cfgrtl.c:3179
>>> 0xe64d8a find_bb_boundaries
>>>../../src/gcc/cfgbuild.c:522
>>> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
>>>../../src/gcc/cfgbuild.c:604
>>> 0x66e689 execute
>>>../../src/gcc/cfgexpand.c:5905
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> Please include the complete backtrace with any bug report.
>>> See  for instructions.
>>
>> Well, look at the CFG and see if it makes sense and why it expects
>> a single successor and why there is none.  Basically, work back
>> from the ICE ...
>>
>> Richard.
>>
>>> Best regards,
>>> Benedikt
>>>
>>> On 27 May 2014, at 17:35, Benedikt Huber 
>>>  wrote:
>>>

 On 27 May 2014, at 17:25, Richard Biener  
 wrote:

> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>  wrote:
>>
>> On 27 May 2014, at 17:09, Richard Biener  
>> wrote:
>>
>>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>>>  wrote:
 (Sorry for the duplicate.)

 I managed to pass the needed parameters to the generated function.
 However I cannot pin down the reason why the compilation fails.
 It seems that the cfg is somehow broken, but I cannot tell how.
 Do you have any debugging hints?

 As far as I can tell, the cfg is changed during the generation of the 
 preheader
 (I do this to find the entry block easily.)
 and in the function move_sese_region_to_fn.

 I noticed that after pass 058t.copyrename2 the original function bar 
 disappears
 and the new function is replaced by _GLOBAL__N_bar.constprop, could 
 this have
 anything to do with the problem?
>>>
>>> Unlikely.  You can disable that by using -fno-ipa-cp.
>>>
 The pass runs just after the construction of cfg,  outline.c.011t.cfg.

 /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src 
 -c -fdump-tree-all-details -fdump-ipa-all-details 
 -fdump-rtl-all-details -funinline-innermost-loops -Wall -Wextra 
 /home/bhuber/sandbox/try/outline.c
 /home/bhuber/sandbox/try/outline.c: In function 
 '_GLOBAL__N_bar.constprop':
 /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
 purge_dead_edges, at cfgrtl.c:3183
>>>
>>> the line doesn't match anything that would ICE on current trunk, but I 
>>> suppose
>>> it's the single_succ_p assert that triggers?
>> Yes, that is right, it is
>>
>> gcc_assert (single_succ_p (bb));
>>
>>>
>>> Either you really got until RTL generation or somehow cfgrtl cfg hooks 
>>> are
>>> still active while you are working in your pass.
>>
>> The pass that fails, according to the dump files is outline.c.174r.expand
>> So it already tries to generate RTL.
>> My problem is that there are so many passes in
>> between, that I do not know where to start looking.
>> Any idea?
>
> What code-base are you developing on?  Do you build with checking
> enabled (--enable-checking, the default on trunk but not on release 
> branches).

 It is a linaro branch, but I am going to port the pass to

Re: How can I generate a new function at compile time?

[Benedikt Huber]

According to the output the ICE is in the newly generated function 
(_GLOBAL__N_bar)
which is the one that remains.
Further more the compilation continues until the
expand pass (outline.c.180r.expand), where the error happens.
The original function (bar) is last seen in outline.c.056i.comdats.
I am a little confused by that, since comdats does not change anything.
But maybe there is no connection between the violated assertion and the 
vanishing function.

On 03 Jun 2014, at 15:14, Richard Biener  wrote:

> On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
>  wrote:
>> 
>> I have not found out why the assertion is violated, yet.
>> However I noticed that the original function disappears somehow between
>> the passes pass_ipa_comdats and pass_fixup_cfg.
>> By that I mean that the function appears from the dump files.
>> These passes run several passes after the outlining pass.
>> Between the outlining pass and pass_ipa_comdats both functions
>> (the generated and the original with the call to the generated) are printed.
>> I do not know whether this has anything to do with the assertion but it
>> seems strange.
>> Do you have any guess why this happens?
> 
> It probably vanishes because this is the function you ICE for?
> 
>> Thank you,
>> Benedikt
>> 
>> On 28 May 2014, at 15:50, Richard Biener  wrote:
>> 
>>> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
>>>  wrote:
 I ported the pass to the fsf trunk. It is built with —enable-checking.
 The patch applied with no changes and also the behaviour is the same.
 So I probably mess up the cfg somehow.
 Can you suggest any strategy for finding the problem that I could use?
 
 /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
 -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
 -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
 /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
 /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
 purge_dead_edges, at cfgrtl.c:3179
 bar (int s, int r, unsigned * t, int * k, int * p, int * l)
 ^
 0x681195 purge_dead_edges(basic_block_def*)
   ../../src/gcc/cfgrtl.c:3179
 0xe64d8a find_bb_boundaries
   ../../src/gcc/cfgbuild.c:522
 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
   ../../src/gcc/cfgbuild.c:604
 0x66e689 execute
   ../../src/gcc/cfgexpand.c:5905
 Please submit a full bug report,
 with preprocessed source if appropriate.
 Please include the complete backtrace with any bug report.
 See  for instructions.
>>> 
>>> Well, look at the CFG and see if it makes sense and why it expects
>>> a single successor and why there is none.  Basically, work back
>>> from the ICE ...
>>> 
>>> Richard.
>>> 
 Best regards,
 Benedikt
 
 On 27 May 2014, at 17:35, Benedikt Huber 
  wrote:
 
> 
> On 27 May 2014, at 17:25, Richard Biener  
> wrote:
> 
>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>>  wrote:
>>> 
>>> On 27 May 2014, at 17:09, Richard Biener  
>>> wrote:
>>> 
 On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
  wrote:
> (Sorry for the duplicate.)
> 
> I managed to pass the needed parameters to the generated function.
> However I cannot pin down the reason why the compilation fails.
> It seems that the cfg is somehow broken, but I cannot tell how.
> Do you have any debugging hints?
> 
> As far as I can tell, the cfg is changed during the generation of the 
> preheader
> (I do this to find the entry block easily.)
> and in the function move_sese_region_to_fn.
> 
> I noticed that after pass 058t.copyrename2 the original function bar 
> disappears
> and the new function is replaced by _GLOBAL__N_bar.constprop, could 
> this have
> anything to do with the problem?
 
 Unlikely.  You can disable that by using -fno-ipa-cp.
 
> The pass runs just after the construction of cfg,  outline.c.011t.cfg.
> 
> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src 
> -c -fdump-tree-all-details -fdump-ipa-all-details 
> -fdump-rtl-all-details -funinline-innermost-loops -Wall -Wextra 
> /home/bhuber/sandbox/try/outline.c
> /home/bhuber/sandbox/try/outline.c: In function 
> '_GLOBAL__N_bar.constprop':
> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
> purge_dead_edges, at cfgrtl.c:3183
 
 the line doesn't match anything that would ICE on current trunk, but I 
 suppose
 it's the single_succ_p assert that triggers?
>>> Yes, that is right, it is
>>> 
>>> gcc_assert (single_succ_p (bb));
>>> 
 

Re: How can I generate a new function at compile time?

[Richard Biener]

On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber
 wrote:
>
> According to the output the ICE is in the newly generated function 
> (_GLOBAL__N_bar)
> which is the one that remains.
> Further more the compilation continues until the
> expand pass (outline.c.180r.expand), where the error happens.
> The original function (bar) is last seen in outline.c.056i.comdats.
> I am a little confused by that, since comdats does not change anything.
> But maybe there is no connection between the violated assertion and the 
> vanishing function.

Well, if it ICEs in _GLOBAL__N_bar then compilation stops - passes after IPA
are executed for one function all to the end, so this just means the
original bar
wasn't processed yet.

Richard.

> On 03 Jun 2014, at 15:14, Richard Biener  wrote:
>
>> On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
>>  wrote:
>>>
>>> I have not found out why the assertion is violated, yet.
>>> However I noticed that the original function disappears somehow between
>>> the passes pass_ipa_comdats and pass_fixup_cfg.
>>> By that I mean that the function appears from the dump files.
>>> These passes run several passes after the outlining pass.
>>> Between the outlining pass and pass_ipa_comdats both functions
>>> (the generated and the original with the call to the generated) are printed.
>>> I do not know whether this has anything to do with the assertion but it
>>> seems strange.
>>> Do you have any guess why this happens?
>>
>> It probably vanishes because this is the function you ICE for?
>>
>>> Thank you,
>>> Benedikt
>>>
>>> On 28 May 2014, at 15:50, Richard Biener  wrote:
>>>
 On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
  wrote:
> I ported the pass to the fsf trunk. It is built with —enable-checking.
> The patch applied with no changes and also the behaviour is the same.
> So I probably mess up the cfg somehow.
> Can you suggest any strategy for finding the problem that I could use?
>
> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
> -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
> -funinline-innermost-loops -Wall -Wextra 
> /home/bhuber/sandbox/try/outline.c
> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
> purge_dead_edges, at cfgrtl.c:3179
> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
> ^
> 0x681195 purge_dead_edges(basic_block_def*)
>   ../../src/gcc/cfgrtl.c:3179
> 0xe64d8a find_bb_boundaries
>   ../../src/gcc/cfgbuild.c:522
> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
>   ../../src/gcc/cfgbuild.c:604
> 0x66e689 execute
>   ../../src/gcc/cfgexpand.c:5905
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

 Well, look at the CFG and see if it makes sense and why it expects
 a single successor and why there is none.  Basically, work back
 from the ICE ...

 Richard.

> Best regards,
> Benedikt
>
> On 27 May 2014, at 17:35, Benedikt Huber 
>  wrote:
>
>>
>> On 27 May 2014, at 17:25, Richard Biener  
>> wrote:
>>
>>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>>>  wrote:

 On 27 May 2014, at 17:09, Richard Biener  
 wrote:

> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>  wrote:
>> (Sorry for the duplicate.)
>>
>> I managed to pass the needed parameters to the generated function.
>> However I cannot pin down the reason why the compilation fails.
>> It seems that the cfg is somehow broken, but I cannot tell how.
>> Do you have any debugging hints?
>>
>> As far as I can tell, the cfg is changed during the generation of 
>> the preheader
>> (I do this to find the entry block easily.)
>> and in the function move_sese_region_to_fn.
>>
>> I noticed that after pass 058t.copyrename2 the original function bar 
>> disappears
>> and the new function is replaced by _GLOBAL__N_bar.constprop, could 
>> this have
>> anything to do with the problem?
>
> Unlikely.  You can disable that by using -fno-ipa-cp.
>
>> The pass runs just after the construction of cfg,  
>> outline.c.011t.cfg.
>>
>> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src 
>> -c -fdump-tree-all-details -fdump-ipa-all-details 
>> -fdump-rtl-all-details -funinline-innermost-loops -Wall -Wextra 
>> /home/bhuber/sandbox/try/outline.c
>> /home/bhuber/sandbox/try/outline.c: In function 
>> '_GLOBAL__N_bar.constprop':
>> /home/bhub

Re: How can I generate a new function at compile time?

[Benedikt Huber]

Ah, now I get it.
So the reason is that comdats is the last ipa pass that is run.

I continue to look for the problem in purge_dead_edges.
Thank you for the explanation.

Best regards,
Benedikt

On 03 Jun 2014, at 16:10, Richard Biener  wrote:

> On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber
>  wrote:
>> 
>> According to the output the ICE is in the newly generated function 
>> (_GLOBAL__N_bar)
>> which is the one that remains.
>> Further more the compilation continues until the
>> expand pass (outline.c.180r.expand), where the error happens.
>> The original function (bar) is last seen in outline.c.056i.comdats.
>> I am a little confused by that, since comdats does not change anything.
>> But maybe there is no connection between the violated assertion and the 
>> vanishing function.
> 
> Well, if it ICEs in _GLOBAL__N_bar then compilation stops - passes after IPA
> are executed for one function all to the end, so this just means the
> original bar
> wasn't processed yet.
> 
> Richard.
> 
>> On 03 Jun 2014, at 15:14, Richard Biener  wrote:
>> 
>>> On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
>>>  wrote:
 
 I have not found out why the assertion is violated, yet.
 However I noticed that the original function disappears somehow between
 the passes pass_ipa_comdats and pass_fixup_cfg.
 By that I mean that the function appears from the dump files.
 These passes run several passes after the outlining pass.
 Between the outlining pass and pass_ipa_comdats both functions
 (the generated and the original with the call to the generated) are 
 printed.
 I do not know whether this has anything to do with the assertion but it
 seems strange.
 Do you have any guess why this happens?
>>> 
>>> It probably vanishes because this is the function you ICE for?
>>> 
 Thank you,
 Benedikt
 
 On 28 May 2014, at 15:50, Richard Biener  
 wrote:
 
> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
>  wrote:
>> I ported the pass to the fsf trunk. It is built with —enable-checking.
>> The patch applied with no changes and also the behaviour is the same.
>> So I probably mess up the cfg somehow.
>> Can you suggest any strategy for finding the problem that I could use?
>> 
>> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details 
>> -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass 
>> -funinline-innermost-loops -Wall -Wextra 
>> /home/bhuber/sandbox/try/outline.c
>> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in 
>> purge_dead_edges, at cfgrtl.c:3179
>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>> ^
>> 0x681195 purge_dead_edges(basic_block_def*)
>>  ../../src/gcc/cfgrtl.c:3179
>> 0xe64d8a find_bb_boundaries
>>  ../../src/gcc/cfgbuild.c:522
>> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
>>  ../../src/gcc/cfgbuild.c:604
>> 0x66e689 execute
>>  ../../src/gcc/cfgexpand.c:5905
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
> 
> Well, look at the CFG and see if it makes sense and why it expects
> a single successor and why there is none.  Basically, work back
> from the ICE ...
> 
> Richard.
> 
>> Best regards,
>> Benedikt
>> 
>> On 27 May 2014, at 17:35, Benedikt Huber 
>>  wrote:
>> 
>>> 
>>> On 27 May 2014, at 17:25, Richard Biener  
>>> wrote:
>>> 
 On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
  wrote:
> 
> On 27 May 2014, at 17:09, Richard Biener  
> wrote:
> 
>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>>  wrote:
>>> (Sorry for the duplicate.)
>>> 
>>> I managed to pass the needed parameters to the generated function.
>>> However I cannot pin down the reason why the compilation fails.
>>> It seems that the cfg is somehow broken, but I cannot tell how.
>>> Do you have any debugging hints?
>>> 
>>> As far as I can tell, the cfg is changed during the generation of 
>>> the preheader
>>> (I do this to find the entry block easily.)
>>> and in the function move_sese_region_to_fn.
>>> 
>>> I noticed that after pass 058t.copyrename2 the original function 
>>> bar disappears
>>> and the new function is replaced by _GLOBAL__N_bar.constprop, could 
>>> this have
>>> anything to do with the problem?
>> 
>> Unlikely.  You can disable that by using -fno-ipa-cp.
>> 
>>> The pass runs just after the construction of cfg,  
>>> outline.c.011

GNU Tools Cauldron 2014 - Presentation abstracts

[Diego Novillo]

I have posted the presentation abstracts at

https://gcc.gnu.org/wiki/cauldron2014

Presenters, please make sure that I have not butchered
the abstract that you sent when you registered your talk.


Thanks. Diego.

Re: PowerPC IEEE 128-bit floating point: Internal GCC types

[Joseph S. Myers]

On Tue, 3 Jun 2014, Vincent Lefevre wrote:

> On 2014-06-02 21:20:57 +, Joseph S. Myers wrote:
> > ([...] Conversion from __float128 to __ibm128 would presumably be
> > done in the usual way of converting to double, and, if the result is
> > finite, subtracting the double from the __float128 value, converting
> > the remainder, and renormalizing in case the low part you get that
> > way is exactly 0.5ulp of the high part and the high part has its low
> > bit set.)
> 
> This is not as simple, depending on how you decide to handle the
> largest values. This is important if FP-model related data are
> provided, such as LDBL_MANT_DIG (the precision) and LDBL_MAX_EXP
> (the maximum exponent). The __ibm128 implementation as long double
> is currently buggy / inconsistent, and I've reported the following
> bug:

There are lots of bugs (some of which may get addressed through a 
configure option to enable slower but better behaved versions of the 
relevant libgcc functions, intended for uses such as running the glibc 
testsuite and not for distribution of binaries configured in that way).  
One reason I find attractive the approach of having separate glibc 
libraries, with any given glibc build only supporting one long double 
format (plus the case of long double = double, for old binaries using the 
old symbol versions or via libnldbl_nonshared.a) is that it allows for a 
deprecation path for the old long double format (i.e. saying that after a 
certain point glibc no longer supports builds for the old format and so 
all the complications relating to it can be removed) - although that would 
require a new ABI variant for 32-bit, not just for 64-bit, and may not be 
workable in practice with existing users.  (You also avoid other 
complications relating to the two versions coexisting in a single 
library.)

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

Re: RFA: [VAX] SUBREG of MEM with a mode dependent address

[Matt Thomas]

On May 30, 2014, at 10:39 AM, Jeff Law  wrote:

> On 05/25/14 18:19, Matt Thomas wrote:
>> 
>> But even if  movhi is a define_expand, as far as I can tell there's
>> isn't enough info to know whether that is possible.  At that time,
>> how can I tell that operands[0] will be a hard reg or operands[1]
>> will be subreg of a mode dependent memory access?
> At that time, you can't know those things.  Not even close ;-)  You certainly 
> don't want to try and rewrite the insn to just use SImode. This is all an 
> indication something has gone wrong elsewhere and this would just paper over 
> the problem.
> 
>> 
>> I've tried using secondary_reload and it called called with
>> 
>> (subreg:HI (reg:SI 113 [ MEM[base: _154, offset: 0B] ]) 0)
>> 
>> but it dies in change_address_1 before invoking the code returned in
>> sri.
> I suspect if you dig deep enough, you can make a secondary reload do what you 
> want.  It's just amazingly painful.
> 
> You want to allocate an SImode temporary, do the load of the SI memory 
> location into that SImode temporary, then (subreg:SI (tempreg:SI)). Your best 
> bet is going to be to look at how some other ports handle their secondary 
> reloads.  But I warn you, it's going to be painful.

Doesn't work because the assert fires before the secondary reload takes place.

In expr.c:convert_mode there is code that would seem to prevent this:

  /* For truncation, usually we can just refer to FROM in a narrower mode.  */
  if (GET_MODE_BITSIZE (to_mode) < GET_MODE_BITSIZE (from_mode)
  && TRULY_NOOP_TRUNCATION_MODES_P (to_mode, from_mode))
{
  if (!((MEM_P (from)
 && ! MEM_VOLATILE_P (from)
 && direct_load[(int) to_mode]
 && ! mode_dependent_address_p (XEXP (from, 0),
MEM_ADDR_SPACE (from)))
|| REG_P (from)
|| GET_CODE (from) == SUBREG))
from = force_reg (from_mode, from);
  if (REG_P (from) && REGNO (from) < FIRST_PSEUDO_REGISTER
  && ! HARD_REGNO_MODE_OK (REGNO (from), to_mode))
from = copy_to_reg (from);
  emit_move_insn (to, gen_lowpart (to_mode, from));
  return;
}

but from at that point is just

(mem:SI (reg:SI 112 [ D.118399 ]) [4 MEM[base: _154, offset: 0B]+0 S4 A32])

So there is not enough information for mode_dependent_address_p to return true.

>> 
>> I've tracked this down to reload replacing (reg:SI 113) with
>> reg_equiv_mem (133) in the rtx.  However, it doesn't verify the rtx
>> is actually valid.  I added a gcc_assert to trap this and got:
> Right.  reload will make that replacement and it's not going to do any 
> verification at that point.  Verification would have happened earlier.

See above.  If anywhere, that is where it would have been done.

> You have to look at the beginning of the main reload loop and poke at that 
> for a while:
> 
> /* For each pseudo register that has an equivalent location defined,
> try to eliminate any eliminable registers (such as the frame pointer)
> assuming initial offsets for the replacement register, which
> is the normal case.
> 
> If the resulting location is directly addressable, substitute
> the MEM we just got directly for the old REG.
> 
> If it is not addressable but is a constant or the sum of a hard reg
> and constant, it is probably not addressable because the constant is
> out of range, in that case record the address; we will generate
> hairy code to compute the address in a register each time it is
> needed.  Similarly if it is a hard register, but one that is not
> valid as an address register.
> 
> If the location is not addressable, but does not have one of the
> above forms, assign a stack slot.  We have to do this to avoid the
> potential of producing lots of reloads if, e.g., a location involves
> a pseudo that didn't get a hard register and has an equivalent memory
> location that also involves a pseudo that didn't get a hard register.
> 
> Perhaps at some point we will improve reload_when_needed handling
> so this problem goes away.  But that's very hairy.  */

I found a simplier solution.  It seemed to me that reload_inner_reg_of_subreg
was the right place to make this happen.  The following diff (to gcc 4.8.3)
fixes the problem:

diff -u -p -r1.3 reload.c
--- gcc/reload.c1 Mar 2014 08:58:29 -   1.3
+++ gcc/reload.c3 Jun 2014 17:24:27 -
@@ -846,6 +846,7 @@ static bool
 reload_inner_reg_of_subreg (rtx x, enum machine_mode mode, bool output)
 {
   rtx inner;
+  int regno;
 
   /* Only SUBREGs are problematical.  */
   if (GET_CODE (x) != SUBREG)
@@ -857,10 +858,20 @@ reload_inner_reg_of_subreg (rtx x, enum 
   if (CONSTANT_P (inner) || GET_CODE (inner) == PLUS)
 return true;
 
-  /* If INNER is not a hard register, then INNER will not need reloading.  */
-  if (!(REG_P (inner)