(no subject)

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

At the moment, for a match_dup in a define_cond_exec, you'd have to
give the number in the
resulting pattern(s) rather than in the substitute pattern.  That's
not only wrong, but can also
be impossible when the pattern should apply to multiple patterns with
different operand numbers.

The attached patch fixes this.

Bootstrapped on x86_64-pc-linux-gnu.

[-- Attachment #2: define_cond_exec_patch.txt --]
[-- Type: text/plain, Size: 527 bytes --]

2020-12-12  Joern Rennecke  <joern.rennecke@embecosm.com>

	Fix match_dup bug of define_cond_exec.
	* gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP.

diff --git a/gcc/gensupport.c b/gcc/gensupport.c
index e1ca06dbc1e..92275358078 100644
--- a/gcc/gensupport.c
+++ b/gcc/gensupport.c
@@ -1230,6 +1230,7 @@ alter_predicate_for_insn (rtx pattern, int alt, int max_op,
     case MATCH_OPERATOR:
     case MATCH_SCRATCH:
     case MATCH_PARALLEL:
+    case MATCH_DUP:
       XINT (pattern, 0) += max_op;
       break;
 

RFA: Fix match_dup numbering bug in define_cond_exec

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

(Sorry about re-sending - I accidentally forgot to add a subject in
the last post, which would make it hard to have a meaningful thread.)

At the moment, for a match_dup in a define_cond_exec, you'd have to
give the number in the
resulting pattern(s) rather than in the substitute pattern.  That's
not only wrong, but can also
be impossible when the pattern should apply to multiple patterns with
different operand numbers.

The attached patch fixes this.

Bootstrapped on x86_64-pc-linux-gnu.

[-- Attachment #2: define_cond_exec_patch.txt --]
[-- Type: text/plain, Size: 527 bytes --]

2020-12-12  Joern Rennecke  <joern.rennecke@embecosm.com>

	Fix match_dup bug of define_cond_exec.
	* gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP.

diff --git a/gcc/gensupport.c b/gcc/gensupport.c
index e1ca06dbc1e..92275358078 100644
--- a/gcc/gensupport.c
+++ b/gcc/gensupport.c
@@ -1230,6 +1230,7 @@ alter_predicate_for_insn (rtx pattern, int alt, int max_op,
     case MATCH_OPERATOR:
     case MATCH_SCRATCH:
     case MATCH_PARALLEL:
+    case MATCH_DUP:
       XINT (pattern, 0) += max_op;
       break;
 

Re: none

[Richard Sandiford]

Joern Rennecke <joern.rennecke@embecosm.com> writes:
> At the moment, for a match_dup in a define_cond_exec, you'd have to
> give the number in the
> resulting pattern(s) rather than in the substitute pattern.  That's
> not only wrong, but can also
> be impossible when the pattern should apply to multiple patterns with
> different operand numbers.
>
> The attached patch fixes this.
>
> Bootstrapped on x86_64-pc-linux-gnu.
>
> 2020-12-12  Joern Rennecke  <joern.rennecke@embecosm.com>
>
> 	Fix match_dup bug of define_cond_exec.
> 	* gensupport.c (alter_predicate_for_insn): Handle MATCH_DUP.

The “Fix match_dup …” should come before the changelog in the commit message.

OK otherwise, thanks.

Richard

> diff --git a/gcc/gensupport.c b/gcc/gensupport.c
> index e1ca06dbc1e..92275358078 100644
> --- a/gcc/gensupport.c
> +++ b/gcc/gensupport.c
> @@ -1230,6 +1230,7 @@ alter_predicate_for_insn (rtx pattern, int alt, int max_op,
>      case MATCH_OPERATOR:
>      case MATCH_SCRATCH:
>      case MATCH_PARALLEL:
> +    case MATCH_DUP:
>        XINT (pattern, 0) += max_op;
>        break;
>  

Re: none

[Gabriel Dos Reis]

"Doug Gregor" <doug.gregor@gmail.com> writes:

Am I the only one to receive Doug's recent messages with empty body?

-- Gaby

Re: none

[Jan Hubicka]

>   > In that case we have a latent bug.  I build the testsuite on x86
>   > without problems (but have store motion disabled).
> I suspect we have a latent bug too.
It should be fixed by patch I sent to "bad jump threading change" thread.
Hope to see the other MIPS problem resolved now (I am no more seeing the
misscomparison on file I seen before, but the bootstrap run out of disc
space and daemon has killed my tree from /tmp... uh oh.

Honza
> 
> jeff

Re: none

[law]

  > In that case we have a latent bug.  I build the testsuite on x86
  > without problems (but have store motion disabled).
I suspect we have a latent bug too.

jeff

Re: none

[Andreas Jaeger]

law@redhat.com writes:

> Your recent patch to toplev.c is causing regressions on the x86.  
> Specifically the compiler is hanging in c-torture on 
> compile/941014-3.c -fomit-frame-pointer -funroll-all-loops -finline-functions
>
> Please investigate and fix:
>
> 2002-01-04  H.J. Lu <hjl@gnu.org>
>
>         * toplev.c (rest_of_compilation): Fix a typo when calling
>         cleanup_cfg.

In that case we have a latent bug.  I build the testsuite on x86
without problems (but have store motion disabled).

I'm appending the patch again, it's really obvious IMO and I expect
the problem to be somewhere else.

Honza, do you have any idea?

Andreas


Index: toplev.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/toplev.c,v
retrieving revision 1.564
retrieving revision 1.565
diff -u -r1.564 -r1.565
--- toplev.c	2001/12/27 17:22:00	1.564
+++ toplev.c	2002/01/04 05:41:24	1.565
@@ -1,6 +1,6 @@
 /* Top level of GNU C compiler
    Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-   1999, 2000, 2001 Free Software Foundation, Inc.
+   1999, 2000, 2001, 2002 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -2941,7 +2941,7 @@
   open_dump_file (DFI_cfg, decl);
 
   find_basic_blocks (insns, max_reg_num (), rtl_dump_file);
-  cleanup_cfg (optimize ? CLEANUP_EXPENSIVE : 0
+  cleanup_cfg ((optimize ? CLEANUP_EXPENSIVE : 0)
 	       | (flag_thread_jumps ? CLEANUP_THREADING : 0));
   check_function_return_warnings ();
 


-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: none

[Alexandre Oliva]

On Dec  3, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On 2 Dec 2001, Alexandre Oliva wrote:
>>> (For the web pages also MIME attachments are fine with me.)
>> I'd rather go with a uniform set of rules.  Would you *prefer* to get
>> patches as MIME attachments, or are the guidelines below ok with you?

> I'm pragmatic, so let's go with a uniform set of rules. ;-)

Thanks

>> Ok to install?

> Could we have two sentences, as in "This and this and this is fine.
> This and this and this is not fine" instead of "This is fine  (while
> this is not fine) and this is fine (while this is not fine)"?

> I believe it's easier to read and understand what we want that way
> -- and the patch is fine with this change.

Thanks, I'm checking this in:

Index: contribute.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.42
diff -u -p -c -r1.42 contribute.html
cvs server: conflicting specifications of output style
*** contribute.html	2001/12/10 10:27:44	1.42
--- contribute.html	2002/01/02 02:40:31
*************** changes easier but do not change GCC's b
*** 120,128 ****
  the changes that actually make use of the new code and change GCC's
  behavior.)</p>
  
! <p>We accept patches as plain text (preferred for the compilers
! themselves), MIME attachments (preferred for the web pages), or as
! uuencoded gzipped text.</p>
  
  <p>When you have all these pieces, bundle them up in a mail message
  and send it to <a
--- 120,137 ----
  the changes that actually make use of the new code and change GCC's
  behavior.)</p>
  
! <p>We prefer patches posted as plain text or as MIME parts of type
! <code>text/x-patch</code> or <code>text/plain</code>, disposition
! <code>inline</code>, encoded as <code>7bit</code> or
! <code>8bit</code>.  If the patch is too big or too mechanical, posting
! it gzipped or bzip2ed and uuencoded or encoded as a
! <code>base64</code> MIME part is acceptable, as long as the ChangeLog
! is still posted as plain text.  Other than that, it is strongly
! discouraged to post patches as MIME parts of type
! <code>application/</code><i>whatever</i>, disposition
! <code>attachment</code> and/or encoded as <code>base64</code> or
! <code>quoted-printable</code>.  Avoid MIME large-message splitting
! (<code>message/partial</code>) at all costs.</p>
  
  <p>When you have all these pieces, bundle them up in a mail message
  and send it to <a


>> ! Avoid MIME large-message splitting (<code>message/partial</code> at
>> ! all costs.</p>

> I have not seen message/partial in the wild yet, so I think we could
> omit this, but if you tell me that you worry about it, I will believe
> you. :-)

I do.  I've seen it before, and it's often annoying to read it even
if your mail reader supports message/partial.  Not to mention the
disruptive effect to the archives.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: none

[Daniel Berlin]

On 1 Feb 2001, Gabriel Dos Reis wrote:

> Mark Kettenis <kettenis@wins.uva.nl> writes:
>
> [...]
>
> | I don't have any checkin priviliges.  Besides, my patch did delete the
> | Cygwin specific code because I believed that it wasn't necessary
> | anymore, but nobody verified this.  And Daniel Berlin was looking at
> | BeOS and said he would submit a patch, and I more or less assumed that
> | would include the sigsetjmp() stuff too since he said it did solve
> | some BeOS-specific problems too.

I keep meaning to, i'm just busy.
--Dan

Re: none

[Gabriel Dos Reis]

Mark Kettenis <kettenis@wins.uva.nl> writes:

[...]

| I don't have any checkin priviliges.  Besides, my patch did delete the
| Cygwin specific code because I believed that it wasn't necessary
| anymore, but nobody verified this.  And Daniel Berlin was looking at
| BeOS and said he would submit a patch, and I more or less assumed that
| would include the sigsetjmp() stuff too since he said it did solve
| some BeOS-specific problems too.
| 
| Anyway, Alexandres patch looks good to me, and even addresses the
| possibility that sigsetjmp is absent.  So I'm all for it to apply his
| patch instead.

Thanks for the detailed explanation.

Alexandre Oliva <aoliva@redhat.com> writes:

[...]

| Tested on sparc-unknown-linux-gnu, with and without -DHAVE_SIGSETJMP.
| The latter compiled, but would never complete, as before.  Ok to
| install?

Alexandre, can't it be possible to detect HAVE_SIGSETJUMP through
autoconf?  I would prefer an autocoonf-based solution.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: none

[Alexandre Oliva]

On Sep  6, 2000, Alexandre Oliva <aoliva@redhat.com> wrote:

> Until his patch propagates to all trees in which I checked my patch
> in, I'm checking this one.

I feel dumb!  This is the second time I fail to attach a patch in the
same day! :-(

But this time I have an excuse: cvsdiff had completed, but some
network problem had caused it to produce no output.  Here's the actual
patch:

Re: none

[Alexandre Oliva]

On Sep  6, 2000, Nick Clifton <nickc@redhat.com> wrote:

>   This patch...

> 2000-09-05  Alexandre Oliva  <aoliva@redhat.com>

> 	* Makefile.in (all-bootstrap): Added all-texinfo and all-zlib.
> 	(bootstrap*): Depend on all-bootstrap.

>   is breaking my bootstraps because the make target 'all-zlib' does
>   not exist.  Did you forget to add this target to the makefile ?

Nope, it wasn't supposed to have been installed before Anthony Green's
patch that zlib in the top-level, but I blindly assumed he had checked
it in everywhere, just like I did :-(

Until his patch propagates to all trees in which I checked my patch
in, I'm checking this one.  Sorry about the breakage, folks.