Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Bernd Schmidt]

Paul Eggert wrote:

That's great, but GCC has had many other hands stirring the pot.
I daresay a careful scan would come up with many other examples of
undefined behavior due to signed integer overflow.  (No doubt
you'll be appalled by them as well, but there they are.)


That's handwaving, not evidence.  Sorry, I'm unconvinced.


Bernd

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Bernd Schmidt]

Paul Eggert wrote:

(2) In the current SPEC, how many programs benefit from undefined overflow
semantics and how much does each benefit?


Those questions are more for the opponents of -fwrapv, so
I'll let them answer them.  But why are they relevant?


It's relevant in a "did my system just become 50% slower because of a 
change in autoconf defaults" sort of way.



(3) How many programs are known to rely on wrap semantics?  For each:
  (a) How hard was it to determine there was a problem with that assumption?


I'm not sure what you're asking for here.


Actual data, rather than handwaving.  Which programs are affected?  Show 
us all the broken code that you are actually aware of.  You are making 
this out to be a huge problem, so let's see why.



Bernd

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Bernd Schmidt]

Paul Eggert wrote:

"Richard Guenther" <[EMAIL PROTECTED]> writes:


Authors of the affected programs should adjust their makefiles


That is what the proposed patch is for.  It gives a way for
developers to adjust their makefiles.

A developer of portable software cannot simply put something
like this into a makefile:

  CFLAGS = -g -O2 -fwrapv

as -fwrapv won't work with most other compilers.  So the
developer needs some Autoconfish help anyway, to address the
problem.  The proposed help is only rudimentary, but it does
adjust makefiles to address the issue, and it's better than
nothing.  Further improvements would of course be welcome.


So rather than changing the default to -fwrapv for all programs, which I 
would find most unwelcome, how about adding a macro

  AC_THIS_PROGRAM_IS_BROKEN_AND_THE_MAINTAINER_DOESNT_CARE
which could add -fwrapv and maybe -fno-strict-aliasing if the compiler 
supports them?  Then anyone who knows their program is affected, or is 
just worried that it might be, could add that macro to their configure.in.



Bernd

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Bernd Schmidt]

Eric Blake wrote:


/* The maximum and minimum values for the integer type T.  These
   macros have undefined behavior if T is signed and has padding bits.
   If this is a problem for you, please let us know how to fix it for
   your host.  */
#define TYPE_MINIMUM(t) \
  ((t) (! TYPE_SIGNED (t) \
? (t) 0 \
: TYPE_SIGNED_MAGNITUDE (t) \
? ~ (t) 0 \
: ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
#define TYPE_MAXIMUM(t) \
  ((t) (! TYPE_SIGNED (t) \
? (t) -1 \
: ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1


I must admit I don't know what an integer with padding bits would look 
like.  Can someone check what the C standard has to say about the 
bit-not operator?  According to what GCC currently does, there is no 
integer overflow anywhere in this code: bit-not expressions never 
overflow, and a integer shift of -1 by (sizeof - 1) bits does not change 
the sign, and therefore doesn't overflow.


Even with -Woverflow, GCC does not warn when these macros are used for 
type "int".



Bernd

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Bernd Schmidt]

Paul Eggert wrote:

But so far, benchmark scores are the only scores given by the people
who oppose having -O2 imply -fwrapv.


And you expect real-world results will be different because...?


You say you doubt it affects performance.  Based on what?  Facts
please, not guesses and hand-waiving...


The burden of proof ought to be on the guys proposing -O2
optimizations that break longstanding code, not on the skeptics.


IMHO the burden of proof should be on the people who are surprised that 
interesting things happen when they write in a language that isn't C and 
then try to pass it through a C compiler.


Has an example of code that actually breaks with a new gcc but not an 
old one been posted in this thread yet?  With -fstrict-aliasing we at 
least had examples of code that really broke with a new optimization 
before we disabled it (in the compiler, not in autoconf, mind you). 
Code got fixed, -fstrict-aliasing got enabled a release later, everyone 
moved on.



Bernd

Re: Mis-handled ColdFire submission?

[Bernd Schmidt]

Richard Sandiford wrote:

I know Andrew replied privately, but I hope he doesn't mind me raising
the issue on-list.  I just wanted to guage the general feeling as to
whether I'd screwed up, and whether I should have submitted the patches
in a different way.


I wish everyone did things this thoroughly.


Bernd

Testsuite no longer finding include files

[Bernd Schmidt]

While running the testsuite (for the first time in a few weeks), xgcc no 
longer seems to find the libc include files in /prefix for a bfin-elf 
target.  It appears that while building libraries, we're careful to pass 
"-isystem /opt/uClinux/bfin-elf/bfin-elf/include -isystem 
/opt/uClinux/bfin-elf/bfin-elf/sys-include" to the compiler, but that 
doesn't seem to happen during "make check".


With the extra -isystem flags passed to the compiler, I'm assuming that 
at least part of that behaviour is intentional - what needs to be done 
to get the testsuite back in working order?



Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough

REG_NO_CONFLICT vs lower-subreg

[Bernd Schmidt]

I've been converting the Blackfin port to take advantage of the new 
lower-subreg pass, which fortunately involves little more than deleting 
a few patterns.


One problem is that without an anddi3 expander, we generate poor initial 
RTL.  optabs knows it can do the operation piecewise, so it could 
generate the following sequence for an operation involving one memory 
operand:


 reg C = (mem:SI symbol+offset)
 reg A = reg B + reg C;
 reg Z = (mem:SI symbol+offset+4)
 reg X = reg Y + reg Z;

It then passes this to emit_no_conflict_block, which is supposed to wrap 
it in REG_NO_CONFLICT notes to help the register allocator.  This 
function pulls out any insns not contributing to the final result, and 
emits them first, leading to:


 reg C = (mem:SI symbol+offset)
 reg Z = (mem:SI symbol+offset+4)
 reg A = reg B + reg C;
 reg X = reg Y + reg Z;

which has higher register pressure (at least in the usual cases where C 
and Z are dead after their use) and causes more spills than the former 
sequence on certain testcases.  The sad thing is that all the 
REG_NO_CONFLICT notes later get removed by lower-subreg as they serve no 
purpose, but the suboptimal insn ordering survives until register 
allocation.


It would be nice to eliminate REG_NO_CONFLICT altogether, but a quick 
experiment with the i386 port showed that this idea is a non-starter for 
now (i386 still has insns operating on DImode, hence in some functions 
not all DImode registers get lowered, and lack of no_conflict blocks 
causes poor register allocation when that happens).


I suppose we could add a target macro to let individual ports turn off 
REG_NO_CONFLICT generation?  Any other ideas?



Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough

Re: GCC mini-summit

[Bernd Schmidt]

Vladimir N. Makarov wrote:


 And I am disagree that it is within compilation time guidelines set
by SC.  Ken fixed a big compilation time degradation a few days ago
and preliminary what I see now (comparison with the last merge point)
is

x86_64
SPECInt2000 5.7%
SPECFp200   8.7%

ppc64
SPECInt2000 6.5%
SPECFp2000  5.5%

Itanium
SPECInt2000 9%
SPECFp2000  10.9%

Besides as I understand correctly the SC criteria means that there is
no degradation on code quality.  There is code size degradation about
1% and some degradation on SPEC2000 (e.g. about 2% degradation on a
few tests on ia64).


I'll be away for a week, so I'll miss most of the big flamewar, but I'd 
just like to throw in my opinion that based on these numbers I don't see 
why we're even considering it for inclusion at this point.


I also agree with Vlad's point that it needs to be reviewed before being 
committed to mainline.



Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, Vincent Roche, Joseph E. McDonough

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

[Bernd Schmidt]

Zack Weinberg wrote:
I have worked out a tentative plan for replacing most of these macros
with ordinary target hooks, and eliminating REG_OK_STRICT.  I propose
to change GO_IF_LEGITIMATE_ADDRESS, GO_IF_MODE_DEPENDENT_ADDRESS,
LEGITIMIZE_ADDRESS, LEGITIMIZE_RELOAD_ADDRESS, REG_OK_FOR_BASE_P,
REG_MODE_OK_FOR_BASE_P, REG_MODE_OK_FOR_REG_BASE_P,
REG_OK_FOR_INDEX_P, CONSTANT_ADDRESS_P, FIND_BASE_TERM, and
LEGITIMATE_CONSTANT_P.  The other macros in this section are all
numeric constants and in at least one case are used to size static
arrays, so conversion to hooks doesn't make sense (yet).
Are you planning to keep the observed behaviour, or do you want to make 
any enhancements that would allow us to describe addressing modes 
better?  One of my plans for the medium term is to add a context 
argument to BASE_REG_CLASS etc. so that we could e.g. allow different 
register classes in a PLUS than in a POST_INC.

Bernd

Re: reload question

[Bernd Schmidt]

Miles Bader wrote:
Say I've got a mov instruction that only works via an accumulator A, and
a two-operand add instruction.  "r" regclass includes regs A,X,Y, and
"a" regclass only includes reg A.
So mov has constraints like:  0 = "g,a"   1 = "a,gi"
and add3 has constraints: 0 = "r" 1 = "0"2 = "i" (say)
Then if there's an insn before reload like:
   add3  X, Y, 1
Reload will notice this, and generate a reload to put Y into X, so
you'll end up with:
   mov   X, Y
   add3  X, X, 1

Now, what I _expected_ to happen is that reload would then be repeated
to handle the newly added mov insn, which would see that the mov insn's
constraint don't match, and would then generate an additional reload to
yield:
   mov   A, Y
   mov   X, A
   add3  X, X, 1
but in fact this final step doesn't seem to be happening -- it just
finishes reload without changing the bogus "mov X, Y" insn and goes on
to die with an "insn does not satisfy its constraints:" error in final.
Reload insns aren't themselves reloaded.  You should look at the 
SECONDARY_*_RELOAD_CLASS; they'll probably let you do what you want.

Bernd

reload-branch created (was: What to do with new-ra for GCC 4.0)

[Bernd Schmidt]

Jeffrey A Law wrote:
On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote:
Why not putting it on a branch? If you are going to finish and submit it for
4.1, it might be easier to use CVS.
It might also be easier for those of us who want to play with the code,
without having to find a suitable sync point between the patch and
mainline sources.
I have created a new branch, "reload-branch", on which I'm going to 
check in these changes.  Once I've done that, I'll commit the patch 
below to mention the branch in the documentation.

Bernd
Index: cvs.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v
retrieving revision 1.183
diff -c -p -r1.183 cvs.html
*** cvs.html14 Mar 2005 22:35:59 -  1.183
--- cvs.html18 Mar 2005 17:20:13 -
*** particular releases or snapshots or the 
*** 255,260 
--- 255,265 
routinely merged with mainline.  Patches should be marked with the
tag [dfp] in the subject line.
  
+   reload-branch
+   This branch contains a version of reload in which the tracking
+   of reload register lifetimes and the inheritance code has been
+   rewritten in an attempt to make it more maintainable.
+ 
  
  
  Architecture-specific

Re: reload-branch created

[Bernd Schmidt]

Giovanni Bajo wrote:
What is your plan for this branch? Is there more code refactoring/rewriting
planned, or are you just going to give it a wider testing and fix fallout bugs,
in preparation for a merge?
There's one known design flaw wrt. to enble_optional/disable_optional, 
and I think autoinc reloads also need some work.  That's going to take a 
bit of thought and probably some more code to fix.  Then, there's the 
matter of testing all sorts of targets (and adapting their 
LEGITIMIZE_RELOAD_ADDRESS macros).

I'm away for a week or so, so I'm unlikely to check in anything in the 
near future.

Bernd

Copyright question: libgcc GPL exceptions

[Bernd Schmidt]

I'm updating the copyrights in the Blackfin port, and I noticed that 
there appear to be two versions of the wording that allows more-or-less 
unlimited use of libgcc files.  One can be found e.g. in 
config/arm/crtn.asm:

  As a special exception, if you link this library with files
  compiled with GCC to produce an executable, this does not cause
  the resulting executable to be covered by the GNU General Public
  License.
  This exception does not however invalidate any other reasons why
  the executable file might be covered by the GNU General Public
  License.
the other in config/arm/lib1funcs.asm:
  In addition to the permissions in the GNU General Public License, the
  Free Software Foundation gives you unlimited permission to link the
  compiled version of this file into combinations with other programs,
  and to distribute those combinations without any restriction coming
  from the use of this file.  (The General Public License restrictions
  do apply in other respects; for example, they cover modification of
  the file, and distribution when not linked into a combine
  executable.)
Is there a particular reason to use one or the other, or are they 
equivalent?

Bernd

Re: reload-branch created

[Bernd Schmidt]

Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
  there is a code path in find_reloads that sets rld[].inc to a
  nonzero value even for a platform that doesn't actually *have*
  pre-/post-increment insns, leading to an ICE later on.
  The patch below simply avoids setting .inc unless it was already
  set to a nonzero value (by find_inc_amount).
This one I'm not sure about yet.
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg01112.html
  there are problems with reload ordering when optional reloads
  are disabled, leading to address reload insns being emitted after
  the main insn.
  The patch below is the same I suggested in that mail; it considers
  such address reloads to feed into both the optional reload and 
  the main insn in scan_rtx.
This problem will probably require more invasive surgery.
- Finally, there is still a (new) problem in the latest version of
  usable_for_inheritance: if an inherited register is chosen as
  override-in because it is not suitable as reload register due
  to HARD_REGNO_MODE_OK, it isn't even checked against the 
  *usable_regs array.

  The patch below adds back that check (using inmode, not mode).
This is OK.  Would you check it in?
Bernd

Re: ia64 bootstrap failure with the reload-branch

[Bernd Schmidt]

(slowly catching up with vacation backlog)
James E Wilson wrote:
Reload is using registers without setting regs_ever_live.  The IA-64 
prologue code needs a temp register to save/restore b0, and it uses 
regs_ever_live to find one.  Also, because we have variable size 
register windows, we need the regs_ever_live info to be accurate so we 
can set up the register windows properly.

The problem happens in inherit_one_chain, but it looks like there are 
other similar places that may have the same problem.  Ugly patch 
attached that gets me past this problem.  We should probably get Bernd's 
opinion on how he thinks this should be fixed.
Thanks for debugging this.  The patch isn't quite right, because setting 
additional bits in regs_ever_live may need to cause additional 
iterations of calculate_needs_all_insns.

Try the patch below - does it fix the problem?
Bernd
	* reload1.c (find_optional_reg, inherit_one_chain): Always use
	set_reload_reg to assign a register to a reload.

Index: reload1.c
===
RCS file: /cvs/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.463.2.3
diff -c -p -r1.463.2.3 reload1.c
*** reload1.c	7 Apr 2005 11:21:35 -	1.463.2.3
--- reload1.c	7 Apr 2005 11:30:48 -
*** static HARD_REG_SET *pseudo_previous_reg
*** 149,155 
  static HARD_REG_SET *pseudo_forbidden_regs;
  
  /* All hard regs that have been used as spill registers for any insn are
!marked in this set.  */
  static HARD_REG_SET used_spill_regs;
  
  /* Nonzero if indirect addressing is supported on the machine; this means
--- 149,156 
  static HARD_REG_SET *pseudo_forbidden_regs;
  
  /* All hard regs that have been used as spill registers for any insn are
!marked in this set.  This is used to update regs_ever_live in
!finish_spills.  */
  static HARD_REG_SET used_spill_regs;
  
  /* Nonzero if indirect addressing is supported on the machine; this means
*** find_optional_reg (struct reload *rl, HA
*** 2916,2926 
if (i == nregs)
  	{
  	  if (do_allocate)
! 	{
! 	  rl->nregs = nregs;
! 	  rl->reginfo.regno = suggested;
! 	  rl->reginfo.allocated = 1;
! 	}
  	  return 1;
  	}
  }
--- 2917,2923 
if (i == nregs)
  	{
  	  if (do_allocate)
! 	set_reload_reg (rl, suggested);
  	  return 1;
  	}
  }
*** find_optional_reg (struct reload *rl, HA
*** 2945,2955 
  return 0;
  
if (do_allocate)
! {
!   rl->nregs = HARD_REGNO_NREGS (best_reg, rl->mode);
!   rl->reginfo.regno = best_reg;
!   rl->reginfo.allocated = 1;
! }
return 1;
  }
  
--- 2942,2949 
  return 0;
  
if (do_allocate)
! set_reload_reg (rl, best_reg);
! 
return 1;
  }
  
*** inherit_one_chain (struct inherit_chain 
*** 3656,3664 
   as above.  */
  
/* Change the head reload to use the inheritance register.  */
!   head_rl->nregs = HARD_REGNO_NREGS (best_reg, head_rl->mode);
!   head_rl->reginfo.regno = best_reg;
!   head_rl->reginfo.allocated = 1;
  
/* Extend lifetime of original reload.  Set the LIVE_UNTIL_END flag so
   that following calls to compute_birth_death will preserve this
--- 3650,3656 
   as above.  */
  
/* Change the head reload to use the inheritance register.  */
!   set_reload_reg (head_rl, best_reg);
  
/* Extend lifetime of original reload.  Set the LIVE_UNTIL_END flag so
   that following calls to compute_birth_death will preserve this

Re: ia64 bootstrap failure with the reload-branch

[Bernd Schmidt]

Steven Bosscher wrote:
On Friday 08 April 2005 00:12, James E Wilson wrote:
On Thu, 2005-04-07 at 04:35, Bernd Schmidt wrote:
Try the patch below - does it fix the problem?
OK, I will try it.  This may take about 2 days.  My lone IA-64 machine
is busy doing other stuff at the moment.

With this patch, I can bootstrap the reload-branch (c,objc,c++,f95).
Woot.  I've checked it in.
Bernd
	* reload1.c (find_optional_reg, inherit_one_chain): Always use
	set_reload_reg to assign a register to a reload.

Index: reload1.c
===
RCS file: /cvs/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.463.2.3
diff -c -p -r1.463.2.3 reload1.c
*** reload1.c	7 Apr 2005 11:21:35 -	1.463.2.3
--- reload1.c	7 Apr 2005 11:30:48 -
*** static HARD_REG_SET *pseudo_previous_reg
*** 149,155 
  static HARD_REG_SET *pseudo_forbidden_regs;
  
  /* All hard regs that have been used as spill registers for any insn are
!marked in this set.  */
  static HARD_REG_SET used_spill_regs;
  
  /* Nonzero if indirect addressing is supported on the machine; this means
--- 149,156 
  static HARD_REG_SET *pseudo_forbidden_regs;
  
  /* All hard regs that have been used as spill registers for any insn are
!marked in this set.  This is used to update regs_ever_live in
!finish_spills.  */
  static HARD_REG_SET used_spill_regs;
  
  /* Nonzero if indirect addressing is supported on the machine; this means
*** find_optional_reg (struct reload *rl, HA
*** 2916,2926 
if (i == nregs)
  	{
  	  if (do_allocate)
! 	{
! 	  rl->nregs = nregs;
! 	  rl->reginfo.regno = suggested;
! 	  rl->reginfo.allocated = 1;
! 	}
  	  return 1;
  	}
  }
--- 2917,2923 
if (i == nregs)
  	{
  	  if (do_allocate)
! 	set_reload_reg (rl, suggested);
  	  return 1;
  	}
  }
*** find_optional_reg (struct reload *rl, HA
*** 2945,2955 
  return 0;
  
if (do_allocate)
! {
!   rl->nregs = HARD_REGNO_NREGS (best_reg, rl->mode);
!   rl->reginfo.regno = best_reg;
!   rl->reginfo.allocated = 1;
! }
return 1;
  }
  
--- 2942,2949 
  return 0;
  
if (do_allocate)
! set_reload_reg (rl, best_reg);
! 
return 1;
  }
  
*** inherit_one_chain (struct inherit_chain 
*** 3656,3664 
   as above.  */
  
/* Change the head reload to use the inheritance register.  */
!   head_rl->nregs = HARD_REGNO_NREGS (best_reg, head_rl->mode);
!   head_rl->reginfo.regno = best_reg;
!   head_rl->reginfo.allocated = 1;
  
/* Extend lifetime of original reload.  Set the LIVE_UNTIL_END flag so
   that following calls to compute_birth_death will preserve this
--- 3650,3656 
   as above.  */
  
/* Change the head reload to use the inheritance register.  */
!   set_reload_reg (head_rl, best_reg);
  
/* Extend lifetime of original reload.  Set the LIVE_UNTIL_END flag so
   that following calls to compute_birth_death will preserve this

Re: reload-branch created

[Bernd Schmidt]

Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
  there is a code path in find_reloads that sets rld[].inc to a
  nonzero value even for a platform that doesn't actually *have*
  pre-/post-increment insns, leading to an ICE later on.

Index: gcc/reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.1
diff -c -p -r1.268.6.1 reload.c
*** gcc/reload.c	18 Mar 2005 18:40:32 -	1.268.6.1
--- gcc/reload.c	18 Mar 2005 21:43:47 -
*** find_reloads (struct insn_chain *chain, 
*** 3215,3222 
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 	rld[operand_reloadnum[i]].inc
! 	  = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {
--- 3215,3224 
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 
! 	if (rld[operand_reloadnum[i]].inc)
! 	  rld[operand_reloadnum[i]].inc
! 	= GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {
This is wrong.  inc is unconditionally cleared in push_reload, so it 
can't be nonzero here.

I did a bit of research into how autoinc is currently dealt with by 
reload.  The obscure "out && ! out_reg" test is used at the last stage, 
but this condition is set up a bit earlier in choose_reload_regs with a 
much more sensible test for PRE_DEC codes etc.

I guess the best solution is to change the place you modified, but to 
use a test that checks for autoinc codes.  I'll come up with something.

Bernd

Re: reload-branch created

[Bernd Schmidt]

I guess the best solution is to change the place you modified, but to 
use a test that checks for autoinc codes.  I'll come up with something.
Try this.
Bernd
	* reload.c (find_reloads): Only set INC field if we know we have an
	autoinc reload.
	* reload.h (struct reload): Update comment to match.

Index: reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.2
diff -c -p -r1.268.6.2 reload.c
*** reload.c	7 Apr 2005 11:21:35 -	1.268.6.2
--- reload.c	11 Apr 2005 12:33:13 -
*** find_reloads (struct insn_chain *chain, 
*** 3203,3216 
  		 && goal_alternative_offmemok[i]
  		 && MEM_P (recog_data.operand[i]))
  	  {
  	operand_reloadnum[i]
  	  = push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
  			 &XEXP (recog_data.operand[i], 0), (rtx*) 0,
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 	rld[operand_reloadnum[i]].inc
! 	  = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {
--- 3203,3221 
  		 && goal_alternative_offmemok[i]
  		 && MEM_P (recog_data.operand[i]))
  	  {
+ 	struct reload *rl;
  	operand_reloadnum[i]
  	  = push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,
  			 &XEXP (recog_data.operand[i], 0), (rtx*) 0,
  			 MODE_BASE_REG_CLASS (VOIDmode),
  			 GET_MODE (XEXP (recog_data.operand[i], 0)),
  			 VOIDmode, 0, 0, i, RELOAD_FOR_NONE);
! 	rl = rld + operand_reloadnum[i];
! 	if (GET_CODE (rl->in_reg) == PRE_INC
! 		|| GET_CODE (rl->in_reg) == PRE_DEC
! 		|| GET_CODE (rl->in_reg) == POST_INC
! 		|| GET_CODE (rl->in_reg) == POST_DEC)
! 	  rl->inc = GET_MODE_SIZE (GET_MODE (recog_data.operand[i]));
  	  }
  	else if (goal_alternative_matched[i] == -1)
  	  {

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

[Bernd Schmidt]

Zack Weinberg wrote:
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up.
What's your status on this - would you mind very much if I made changes 
to those macros now?

Bernd

Re: Ada front-end depends on signed overflow

[Bernd Schmidt]

Paul Schlie wrote:

From: Robert Dewar <[EMAIL PROTECTED]>
You keep saying this over and over, but it does not make it true. Once
again, the whole idea of making certain constructs undefined, is to
ensure that efficient code can be generated for well defined constructs.



- Can you give an example of an operation which may yield an undefined
  non-deterministic result which is reliably useful for anything?


The simplest example is a shift operation, x << n, where the compiler 
may assume that the shift count is smaller than the width of the type. 
All sane machines agree on shift behaviour for 0 <= n < width, but there 
are differences between machines for n >= width.  Since this case is 
undefined by the language, it is ensured that shifts take only a single 
instruction on essentially all machines.



Bernd

Re: [RFH] - Less than optimal code compiling 252.eon -O2 for x86

[Bernd Schmidt]

Jeffrey A Law wrote:

I'd tend to agree.  I'd rather see the option go away than linger on
if the option is no longer useful.


I wouldn't mind that, but I'd also like to point out that there are 
Makefiles out there which hard-code things like -fforce-mem.  Do we want 
to keep the option as a stub to avoid breaking them?



Bernd

Re: Some notes on the Wiki

[Bernd Schmidt]

Steven Bosscher wrote:

I guess that, apart from the legal discussion of whether this enough,
such a statement would not apply to existing content.  It was certainly
not my intention to sign over the various Wiki contributions I have
made to the FSF.


This strikes me as shortsighted.  If we're getting into a situation 
where we can't freely move documentation from one place to another, 
we're shooting ourselves in the foot.



Bernd

Re: Some notes on the Wiki

[Bernd Schmidt]

Kurt Wall wrote:

On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write:


On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote:

Also, a web-browser is much slower than an info-browser, especially 
when doing searchs.


You must be close to the only user i've met who uses the info browser :)



We haven't met, but I use the info browser. :-) I used to hate it but
finally decided that since texi was the format that existed, I might
as well suck it up and learn to use it.


I learned how to use it more than a decade ago when I was playing with 
gcc-2.3.3 on my Amiga :-)  Can't say I really really like it, but at 
least you can quickly search through the whole file, which isn't so easy 
with most browsers when you have multiple pages of HTML documentation.



Bernd

Re: Problem with the special live analyzer in global alloc

[Bernd Schmidt]

Andreas Krebbel wrote:


Ok I understand that implementing the special lifeness analyzers in global alloc
using the df.c framework would ease reusing it somewhere else. But my question
was more basic.
So do you agree that using one lifeness analyzer for checking what
an optimizer step has done based on a second lifeness analyzers output
is wrong? If so what is the way to fix this? Going back to the normal analyzer 
to
be used in global alloc would make global alloc creating worse code. But on the 
other hand
using the global alloc lifeness analyzer everywhere else would be a change 
which nobody would agree with in the current development stage.


Jim Wilson once suggested we should just emit insns to make sure every 
register is initialized and be done with it - problem solved.  I had 
started to work on that, if people think it's a good idea I can dig that 
stuff out again.



Bernd

Re: Problem with the special live analyzer in global alloc

[Bernd Schmidt]

Daniel Berlin wrote:


If you make them all defined, then it's going to be live where it wasn't
before, even though it's not really *used* over those paths.


The idea is to put the initialization insns only on the paths where the 
register will be uninitialized.



Bernd

Re: Problem with the special live analyzer in global alloc

[Bernd Schmidt]

Steven Bosscher wrote:

On Tuesday 23 August 2005 17:06, Bernd Schmidt wrote:


The idea is to put the initialization insns only on the paths where the
register will be uninitialized.



int foo (int n)
{
  int a;

  while (--n)
a = n;

  return a;
}

Not knowing n, how can you be sure whether "a" is uninitialized for
the "return" statement or not?


In this case, assuming nothing interesting happens to the loop, you'll 
have to conservatively initialize "a" near the top of the function.  In 
many cases you can do better and either initialize just before the use, 
or initialize on an edge on which the register is uninitialized.  For 
register allocation purposes however, this should be as good as using 
Vlad's new liveness analysis.


As Jim points out, we may have to do that for IA64 anyway, so we could 
consider doing it on all targets.  Dan is correct that this can 
introduce new code that won't be eliminated.  One question is how often 
this is going to occur in practice.



Bernd

Re: reload-branch created

[Bernd Schmidt]

Daniel Jacobowitz wrote:

Hey Bernd,

Has there been any news or progress on reload-branch lately?  It
removes a lot of code that I'd dearly love to see gone...


Unfortunately not.  I just don't have the time to work on too many extra 
projects at the moment :-(  Of course, others could always volunteer to 
work on it...



Bernd

Re: A couple more subversion notes

[Bernd Schmidt]

Joe Buck wrote:


Are there any maintainers (folks in MAINTAINERS) who have objections or
concerns?


I haven't played with svn much, but from what I hear about the 
advantages I'm all for it.  cvs is so 20th century.



Bernd

Re: A couple more subversion notes

[Bernd Schmidt]

Lars Gullik Bjønnes wrote:

It seems that svn is unable to send all its requests to the svn
repo over one ssh connection. In one test I just did I had to enter
the ssh password five times.


man ssh-agent


Bernd

Java on uClinux (was: Null pointer check elimination)

[Bernd Schmidt]

David Daney wrote:
Perhaps not in general, but one unstated premise of this whole thread is 
that for some GCC targets (most Unix like operating systems) you *can* 
count on a SIGSEGV when you dereference a null pointer.  The java front 
end takes advantage of this fact to eliminate explicit checks for 
dereferencing of null pointers.


Oh.

Speaking of which, has anyone ported gcj to a MMU-less uClinux platform yet?


Bernd

Re: Java on uClinux

[Bernd Schmidt]

Andrew Haley wrote:

Bernd Schmidt writes:
 > David Daney wrote:
 > > Perhaps not in general, but one unstated premise of this whole thread is 
 > > that for some GCC targets (most Unix like operating systems) you *can* 
 > > count on a SIGSEGV when you dereference a null pointer.  The java front 
 > > end takes advantage of this fact to eliminate explicit checks for 
 > > dereferencing of null pointers.
 > 
 > Oh.
 > 
 > Speaking of which, has anyone ported gcj to a MMU-less uClinux platform yet?


It's impossible with the current config.  This is because some of
libgcj is written on C++, and the C++ compiler FE does not insert
checks for null pointer accesses.  I wrote a small patch to do this
but it was rejected.


Hmm, we can trap null pointer accesses, but I don't think we deliver 
reliable SIGSEGV signals yet or provide a means of getting the faulting 
address.  If that was fixed, is there anything obvious that stands in 
the way of a uClinux/uClibc port?



Bernd

Re: Link-time optimzation

[Bernd Schmidt]

Daniel Jacobowitz wrote:

On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:


I just tried a simple unoptimized compile.  -ftime-report said that
final took 5% of the time (obviously final does more than formatting),
and the assembler took 4% of the total user time, and system time took
16% of wall clock time.  Cutting those numbers in half makes 1% seem
not implausible to me, maybe even low.

I'm considering an unoptimized compile because that is where the
assembler makes the most difference--the compiler is faster and the
assembler output probably tends to be longer, and also an unoptimized
compile is when people care most about speed.  For an optimizing
compile, the assembler is obviously going to be less of a factor.



Also, please keep in mind that generating and then assembling debug
info takes a huge amount of I/O relative to code size.  I'd expect much
more than 1% saving the write-out and write-in on -g.


So, maybe a simpler strategy could be to make minor modifications to gas 
and gcc so that the former is linked in and the latter can pass strings 
to it?  Maybe that could get us a performance improvement without the 
need for a massive overhaul of all backends, and the need to duplicate 
object code generation.



Bernd

Re: Java on uClinux

[Bernd Schmidt]

Andrew Haley wrote:

Bernd Schmidt writes:


 > Hmm, we can trap null pointer accesses, but I don't think we deliver 
 > reliable SIGSEGV signals yet or provide a means of getting the faulting 
 > address.  If that was fixed, is there anything obvious that stands in 
 > the way of a uClinux/uClibc port?


I don't think so.  The only other dependency we have is POSIX threads.


Ok, thanks.  Assuming I get around to porting them, where do I submit 
libffi/boehm_gc changes?  Is there an upstream version to worry about?



Bernd

Re: Possible size-opt patch

[Bernd Schmidt]

Giovanni Bajo wrote:

Bernd,

I read you're interested in code-size optimizations. I'd like to point you
to this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00554.html

which was never finished nor committed (I don't know if RTH has a newer
version though). This is would be of great help for code size issues in AVR,
but I don't know if and how much it'd help for Blackfin.


Probably not too much, since we only use multi-word regs for DImode, 
which doesn't occur that frequently.



Bernd

Re: Huge compile time regressions

[Bernd Schmidt]

Daniel Berlin wrote:

On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote:


Hi,

Someone caused a >10% compile time regression yesterday for CSiBE, see
http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs


Gr.
Steven




This is very very bad.

Joern, i'd imagine this was your patch.


Seems to be.  I can reproduce a massive compile-time difference (up to a 
50% increase) between 108479 and 108480, but I'm having trouble figure 
out where exactly that time goes.


Joern, please revert the patch for now.  I'll be away for three weeks; 
if no one else works with you on this in the meantime I'll help once I'm 
back.



Bernd

Re: keeping branch up to date with mainline

[Bernd Schmidt]

Diego Novillo wrote:

On Tuesday 03 January 2006 12:17, [EMAIL PROTECTED] wrote:

how to keep my branch updated with the mainline?



The easiest way is using svnmerge.py (included in SVN's contrib directory).  
There's documentation in the GCC wiki:  http://gcc.gnu.org/wiki/SvnBranch


Just tried these instructions on the reload-branch, and it doesn't 
appear to be working as documented:


[EMAIL PROTECTED]:/local/src/egcs/reload-branch> svnmerge.py init
property 'svnmerge-integrated' set on '.'

[EMAIL PROTECTED]:/local/src/egcs/reload-branch> svn status
?  svnmerge-commit-message.txt
 M .
[EMAIL PROTECTED]:/local/src/egcs/reload-branch> cat 
svnmerge-commit-message.txt

Initialized merge tracking via "svnmerge" with revisions "1-96656" from
svn+ssh://gcc.gnu.org/svn/gcc/branches/CYGNUS/libjava/testsuite/libjava.lang/Invoke_1.out
[EMAIL PROTECTED]:/local/src/egcs/reload-branch> svn diff

Property changes on: .
___
Name: svnmerge-integrated
   + /branches/CYGNUS/libjava/testsuite/libjava.lang/Invoke_1.out:1-96656

[EMAIL PROTECTED]:/local/src/egcs/reload-branch> svn commit -F 
svnmerge-commit-message.txt

Sending.

Committed revision 109540.
[EMAIL PROTECTED]:/local/src/egcs/reload-branch> rm 
svnmerge-commit-message.txt

[EMAIL PROTECTED]:/local/src/egcs/reload-branch> cd ..
[EMAIL PROTECTED]:/local/src/egcs> cp -a reload-branch/ reload-branch-merged
[EMAIL PROTECTED]:/local/src/egcs> cd reload-branch-merged/
[EMAIL PROTECTED]:/local/src/egcs/reload-branch-merged> svnmerge.py  avail

[EMAIL PROTECTED]:/local/src/egcs/reload-branch-merged> svnmerge.py 
avail --diff

[EMAIL PROTECTED]:/local/src/egcs/reload-branch-merged>


Help?
(The "commit -F/rm" combination seems a bit arcane to me, what exactly 
am I doing there?)



Bernd

Re: keeping branch up to date with mainline

[Bernd Schmidt]

This was the correct command to do, assuming that you *never* merged your
branch since its original creation. I inspected the history of the branch
(through 'svn log') and it seems this assumption is correct.


Yes.


Anyway, I have fixed the bug in svnmerge and attached a new version for you
in this mail.


Thanks for the quick fix.  This seems to be working now ("svnmerge.py 
avail" gives me a rather enormous list of revision numbers).



For curiosity: you could have worked around this auto-detection problem by
manually specifying the head of the branch and the branch point: "svnmerge
init /trunk -r1-96656".


That complains about
  svnmerge: "/trunk" is not a valid URL or working directory

but no big deal since the other method works.



(The "commit -F/rm" combination seems a bit arcane to me, what exactly
am I doing there?)



Nothing special. The svnmerge tool *never* commits anything on your behalf:
it always modifies your working copy and lets you review what it did and do
the actual commit. To ease your work, it generates a simple commit message
in a text file. When you say "svn ci -F svnmerge-commit-message.txt", you're
just telling svn to grab the commit message from the text file that svnmerge
generated for you. Then, you can simply remove the file as it's useless.


Ah ok.  Somehow I got confused with my old CVS mindset of "no files 
changed, what am I committing", but I assume it's this property thing.



Feel free to mail me with other svnmerge problems, I'm happy to provide you
with support.


Thanks!


Bernd

Re: keeping branch up to date with mainline

[Bernd Schmidt]

One additional question, suppose I don't want to merge a huge number of 
revisions in one go, and I do

  svnmerge.py merge -r a-small-list-of-revisions
  svn diff ;; to verify everything is OK

Do I then have to commit the merge so far before running svnmerge.py 
again, or can it get all the information it needs from the local repository?



Bernd

Re: keeping branch up to date with mainline

[Bernd Schmidt]

Giovanni Bajo wrote:

Bernd Schmidt <[EMAIL PROTECTED]> wrote:



One additional question, suppose I don't want to merge a huge number of
revisions in one go, and I do
  svnmerge.py merge -r a-small-list-of-revisions
  svn diff ;; to verify everything is OK

Do I then have to commit the merge so far before running svnmerge.py
again, or can it get all the information it needs from the local


repository?

Also note that, theoretically, it's better to do it in one-go as you'd end
up with less conflicts.


Why is that - do you mean merge conflicts?

I imagine that most of the revisions from trunk will just apply cleanly 
since the files are unchanged on the branch.  For changes in reload*.*, 
I'd rather merge one revision at a time and make sure I update the 
affected files properly (I very much doubt any large change will apply 
cleanly in those files; they'll need manual intervention).  I assume 
it'll be easier to correct merge errors for every individual change 
rather than trying to piece them together after a monster merge.



Bernd

Re: keeping branch up to date with mainline

[Bernd Schmidt]

One more question (I'm experimenting... excuse the stupid questions but 
I'd rather not accidentally mess up the branch).  What I did now was, first,


  ~/svnmerge.py merge  -r 96659-96679

just to get started, then

  ~/svnmerge.py merge -F -r 96681,,9

with the list of numbers cut&pasted from the output of "~/svnmerge.py 
avail".  (That second command took a rather long time).  What should be 
the contents of the svnmerge-integrated property after that?  svn diff 
gives me:



Property changes on: .
___
Name: svnmerge-integrated
   - /trunk:1-96656
   + /trunk:1-10,,103808-103809,1

i.e. it seems to contain exactly the revision numbers I didn't want to 
merge yet.  Is this expected?



Bernd

Re: merges

[Bernd Schmidt]

Daniel Berlin wrote:

On Wed, 11 Jan 2006, Bernd Schmidt wrote:
The merge script relies only on the svnmerge-integrated property, not 
on the commit messages?



Right.

It's just trying to generate a nice message for you, but in our world, 
the messages are so huge as to be useless.


I've fixed the wiki page to mention that.  Sorry about the mess.


Bernd

Re: merges

[Bernd Schmidt]

Daniel Berlin wrote:

mysql> delete from longdescs where length(thetext) > 100;
Query OK, 251 rows affected (2 min 12.11 sec)


Thank you.


I may just set up a pre-commit hook to check the log message length and
hav eit not let you commit if it's ridiculously large.


Maybe checkins on a branch shouldn't affect the bugzilla database at all?


Bernd

Re: Not usable email content encoding

[Bernd Schmidt]

On 3/18/20 3:22 PM, Frank Ch. Eigler via Gcc wrote:

The From: header rewriting for DMARC participants is something sourceware
is doing now.


Out of curiousity, is this rewriting you are talking about the cause for 
a lot of mails showing up as "From: GCC List" rather than their real 
senders? This has become very annoying recently.



Bernd

Re: AVR CC0 transition

[Bernd Schmidt]

On 4/23/20 8:31 AM, Eric Botcazou wrote:

Thanks, I will take a look at Bernd's work. IIRC, he took a
different approach from what was suggested in the wiki, right?


Yes, let's say that it's a half-baked conversion, probably a consequence of
the bounty.  This might be good enough, depending on the architecture.


I very much disagree with this. I think my approach was possibly the 
only viable one, and definitely the most sensible one for this target. 
Not only is there nothing meaningful to be gained from separating cc 
setters and users on m68k given that almost all instructions (including 
moves) clobber the flags, it is not really an actively maintained target 
and any more adventurous approach would have introduced many more 
possibilities for error. Generating exactly the same code as before as 
much as possible was the correct goal IMO.



Bernd

Re: Offloading: libgfortran, libm dependencies

[Bernd Schmidt]

On 10/02/2015 05:20 PM, Thomas Schwinge wrote:

How should we handle libgfortran and libm dependencies in offloaded code?

As the linking requirements especially regarding libgfortran may be
different for each offloading target (shared and/or static libraries
supported, static linking enforced, libquadmath needed, and so on), I
think the specific configuration must happen inside the offloading
execution path (mkoffload).  Thus, trying to do this inside the gfortran
front end, gcc/fortran/gfortranspec.c:lang_specific_driver etc., does not
appear to be doing it the right way; for offloaded code, we'll always be
using the lto1 front end instead of the gfortran one.  Is a libgfortran
link spec like libgomp's, together with some flag (similar to
-fopenmp/-fopenacc being used with the libgomp link spec) the right thing
to do?


So I think I'm following your reasoning, and what you suggest may well 
be the best solution. The question then becomes how to decide when to 
pass that new flag. Have f951 put it into the options written into LTO 
somehow?



Bernd

Re: OpenACC (gomp-4_0-branch) patch review

[Bernd Schmidt]

On 10/16/2015 11:44 AM, Thomas Schwinge wrote:

Lately, Bernd has
stepped up a few times to review OMP patches (many thanks, Bernd!), but
also he sometimes stated that even though a patch appears fine to him,
he'd like "Jakub to have a look".


I'll just comment on this briefly. In general I'll try to review 
anything I think I can figure out and which doesn't have a super-active 
maintainer, but some areas have folks who clearly know the code better. 
The whole gomp area is one of those, and when in doubt, I like to err on 
the side of allowing (in this case) Jakub a chance to take a look.



There's still a bit of clean-up and development going on on
gomp-4_0-branch, but what should be the strategy to get it merged into
trunk?  Instead of us extracting and submitting individual changes (which
we certainly can do, but which is a huge time-sink if they're then not
handled quickly), would you maybe prefer to do a "whole-branch" review?


It might be good to start with a relatively high-level overview of the 
current approach, also documenting which parts of OpenACC the changes 
implement and which ones they don't.



would it perhaps make sense to officially
appoint somebody else to review OMP changes in addition to you?  And,
also, allow for "somewhat non-perfect" changes to be committed, and later
address the "warts"?


Depends on how "somewhat non-perfect" is defined - you might want to 
elaborate. Code should follow the coding standards, add documentation, 
testcases, etc., those are minimum requirements for everyone. In cases 
where something is implemented in a way that has a clearly superiour 
alternative, I think it is reasonable to ask for it to be changed (the 
builtin folding fell into this category for me). In terms of the current 
general approach towards implementing OpenACC I don't intend to give you 
a hard time, especially since past patch review from Jakub pointed in 
this direction and it would be unreasonable to second-guess this choice now.


On the bright side I think most of omp-low.c could be described as 
"somewhat non-perfect", so you'd be following existing practice.



Bernd

How do we write unused arguments?

[Bernd Schmidt]

When reviewing patches I'm never quite sure which of the following we 
should be using:


some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED)

some_target_hook (tree decl, machine_mode ARG_UNUSED (mode))

some_target_hook (tree decl, machine_mode /* mode */)

some_target_hook (tree decl, machine_mode)

Any opinions? I'm leaning towards the last version since it's idiomatic 
in the language we're using and has the least amount of visual clutter. 
If no one comments, I'll start enforcing that in patch reviews. 
Currently no one seems sure and everything is getting totally inconsistent.



Bernd

Re: Solaris vtv port breaks x32 build

[Bernd Schmidt]

(add gcc-patches)

On 12/01/2015 08:39 AM, Matthias Klose wrote:

On 01.12.2015 03:58, Ulrich Drepper wrote:

On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law  wrote:

Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?



The problem macro is _AC_COMPILER_EXEEXT_WORKS.  The message is at the
end.

This macro *should* work for cross-compiling but somehow it doesn't
work.  In libvtv/configure $cross_compiling is not defined
appropriately.  I'm configuring with the following which definitely
indicates that cross-compiling is selected.


that might be another instance of
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
Does something like this help?


Given that your the change you referenced in the archive was installed, 
I think your suggestion for libvtv can be checked in as obvious if it helps.



Bernd

Re: basic asm and memory clobbers - Proposed solution

[Bernd Schmidt]

On 12/14/2015 09:10 AM, Segher Boessenkool wrote:

That, and adding a memory clobber degrades performance for a lot of
existing basic asm that does not expect the clobber, e.g. asm(""),
asm("#"), asm("nop"), ...


I wonder about this. People keep bringing up "a lot of existing basic 
asm" in general, but are there any known examples in real software?



Bernd

Re: basic asm and memory clobbers - Proposed solution

[Bernd Schmidt]

On 12/17/2015 02:41 AM, David Wohlferd wrote:


So how about:

- Update the basic asm docs to describe basic asm's current (and
historical) semantics (ie clobber nothing).
- Emphasize how that might be different from users' expectations or the
behavior of other compilers.
- Warn that this could change in future versions of gcc.  To avoid
impacts from this change, use extended.
- Mention -Wonly-top-basic-asm as a way to locate affected statements.


Sounds like a pretty reasonable plan.


What's your take on making -Wonly-top-basic-asm a default (either now or
v7)?  Is making it a non-default a waste of time because no one will
ever see it?  Or is making it a default too aggressive? What about
adding it to -Wall?


Depends if anyone has one in system headers I guess. We could try to add 
it to -Wall.



Bernd

Re: Some real-life feedback on -Wmisleading-indentation

[Bernd Schmidt]

On 01/12/2016 06:44 AM, Jeff Law wrote:

I would argue that each of these does represent misleading
indentation and that the warning is warranted for each.
Perhaps they aren't as bad as prior cases, but I'd still
consider them mis-leading.

(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03242.html)

I still stand by that assessment.

ISTM for the wine case the backwards indentation (column-wise) of the IF
may be the right filter, maybe that in conjunction with the blank line
heuristic.  However, I stand by my belief that the blank line heuristic
is wrong when used by itself.


I also still agree with this. It's worthy of note that most cases in 
Wine that use this pattern enclose the commented out code in braces, as in


if (0)
{
 /* stuff */
}
 normally indented code

If we warn about this, I'd agree it isn't helpful. IMO code that uses 
the pattern Gerald quoted should be fixed to use #if or add braces.



Bernd

Remove sel-sched?

[Bernd Schmidt]

There are a few open PRs involving sel-sched, and I'd like to start a 
discussion about removing it. Having two separate schedulers isn't a 
very good idea in the first place IMO, and since ia64 is dead, sel-sched 
gets practically no testing despite being the more complex one.


Thoughts?


Bernd

Re: Remove sel-sched?

[Bernd Schmidt]

On 01/14/2016 06:26 PM, Jeff Law wrote:

I think the bigger question Bernd is asking here is whether or not it
makes sense to have multiple schedulers.  In an ideal world we'd bake
them off select the best and deprecate/remove the others.

I didn't follow sel-sched development closely, so forgive me if the
questions are simplistic/naive, but what are the main benefits of
sel-sched and is it at a point (performance-wise) where it could
conceivably replace the aging haifa scheduler infrastructure?


I think haifa has the advantage in comprehensibility. It also has 
features that are missing from sel-sched such as c6x delay slot and 
modulo scheduling.



Bernd

Re: Remove sel-sched?

[Bernd Schmidt]

On 01/15/2016 11:13 AM, Richard Biener wrote:

Btw, I'd like people to start thinking if the scheduling algorithms
working on loops
(and sometimes requiring unrolling of loops) can be implemented in a way to
apply that unrolling on the GIMPLE level (not the scheduling itself of course).
Thus have an analysis phase (for the unrolling compute) that can be shared
across ILs.

Scheduling of loads / stores might still happen on GIMPLE if we have a good
enough idea of register pressure - I remember we jumped throuhg hoops in the
past to get better dependence info on RTL for this (ddr export to RTL, never
merged).

Basically unrolling on RTL should go away.


I don't think that's such a great idea. For C6X modulo scheduling I 
actually wanted unrolling during the final sched phase. I don't expect 
to be working on anything like this in the foreseeable future, but IMO 
at the gimple stage we simply don't know enough to make reasonable 
decisions for certain targets.



Bernd

Re: Reorder/combine insns on superscalar arch

[Bernd Schmidt]

On 01/15/2016 07:05 AM, Jeff Law wrote:


Well, you have to write the pattern and a splitter.  But these days
there's define_insn_and_split to help with that.  Reusing Bernd's work
may ultimately be easier though.


Maybe, but maybe also not in the way you think. I've always wanted the 
ability to combine 2->2 insns, for cases like this. The parallel would 
be split into two separate insns if it doesn't match. This would allow 
more complicated forms to be used if they are equally cheap, and can 
lead to elimination of instructions if it triggers more combinations.


I had a patch for this... 20 years ago. It was in pgcc for a while but 
apparently it had some bookkeeping problems. It would be nice to solve 
this at some point.



Bernd

Re: Question about how to fix PR69052

[Bernd Schmidt]

On 01/25/2016 08:51 PM, Jeff Law wrote:

No, the combiner works within a basic block only.  There was a group, I
believe in Moscow, that worked on a cross-block combiner.  It was
discussed at the Cauldron in California a few years back.  I don't know
if they did any further work on those ideas.

Is the issue here not knowing when the loop invariant can be forward
propagated back into the memory reference -- and for complex RTL like
you cited, you ultimately determine that no it can't be propagated and
thus increase its invariant cost?


Is this just a pass ordering problem? What happens if you do 
loop-invariant after combine?



Bernd

Re: Question about how to fix PR69052

[Bernd Schmidt]

On 01/26/2016 10:48 AM, Bin.Cheng wrote:

Yes, I moved whole loop pass (also the pass_web) after combine and it
worked.  A combine pass before loop-invariant can fix this problem.
Below passes are currently between loop transform and combine:

   NEXT_PASS (pass_web);
   NEXT_PASS (pass_rtl_cprop);
   NEXT_PASS (pass_cse2);
   NEXT_PASS (pass_rtl_dse1);
   NEXT_PASS (pass_rtl_fwprop_addr);
   NEXT_PASS (pass_inc_dec);
   NEXT_PASS (pass_initialize_regs);
   NEXT_PASS (pass_ud_rtl_dce);

I think pass_web needs to be after loop transform because it's used to
handle unrolled register live range.
pass_fwprop_addr and pass_inc_dec should stay where they are now.  And
putting pass_inc_dec before loop unroll may be helpful to keep more
auto increment addressing mode chosen by IVO.
We should not need to duplicate pass_initialize_regs.
So what's about pass_rtl_cprop, cse2 and dse1.  Should these pass be
duplicated after loop transform thus loop transformed code can be
cleaned up?


Hard to tell in advance - you might want to experiment a bit; set up a 
large collection of input files and see what various approaches do to 
code generation. In any case, I suspect this is gcc-7 material 
(unfortunately).



Bernd

Re: "cc" clobber

[Bernd Schmidt]

On 01/27/2016 12:12 AM, David Wohlferd wrote:

I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags.  I figured this would allow the
'normal' "cc" handling to occur.  But apparently there is no 'normal'
"cc" handling.


I have a dim memory that there's a difference between the "cc" and "CC" 
spellings. You might want to check that.



Bernd

Re: out of bounds access in insn-automata.c

[Bernd Schmidt]

On 03/23/2016 07:32 AM, Aldy Hernandez wrote:


int
maximal_insn_latency (rtx insn)
{
   int insn_code;

   if (insn == 0)
 insn_code = DFA__ADVANCE_CYCLE;


   else
 {
   insn_code = dfa_insn_code (as_a  (insn));
   if (insn_code > DFA__ADVANCE_CYCLE)
 return 0;
 }
   return internal_maximal_insn_latency (insn_code, insn);
}

In the case where insn==0, insn_code is set to the size of
default_latencies[] which will get accessed in the return.

Does insn==0 never happen?


I suspect it never happens in this function. I'd add a gcc_assert to 
that effect and try a bootstrap/test. Hmm, it seems to be a sel-sched 
only thing so a normal bootstrap would be meaningless, but from the 
context it looks fairly clearly like insn is always nonnull.


It looks like this block of code is written by a helper function that is 
really intended for other purposes than for maximal_insn_latency. Might 
be worth changing to

 int insn_code = dfa_insn_code (as_a  (insn));
 gcc_assert (insn_code <= DFA__ADVANCE_CYCLE);


Bernd

Re: out of bounds access in insn-automata.c

[Bernd Schmidt]

On 03/24/2016 11:17 AM, Aldy Hernandez wrote:

On 03/23/2016 10:25 AM, Bernd Schmidt wrote:

It looks like this block of code is written by a helper function that is
really intended for other purposes than for maximal_insn_latency. Might
be worth changing to
  int insn_code = dfa_insn_code (as_a  (insn));
  gcc_assert (insn_code <= DFA__ADVANCE_CYCLE);


dfa_insn_code_* and friends can return > DFA__ADVANCE_CYCLE so I can't
put that assert on the helper function.


So don't use the helper function? Just emit the block above directly.


Bernd

Re: out of bounds access in insn-automata.c

[Bernd Schmidt]

On 03/25/2016 04:43 AM, Aldy Hernandez wrote:

If Bernd is fine with this, I'm happy to retract my patch and any
possible followups.  I'm just interested in having no path causing a
possible out of bounds access.  If your patch will do that, I'm cool.


I'll need to see that patch first to comment :-)


Bernd

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[Bernd Schmidt]

On 08/04/2016 04:49 PM, Thomas Schwinge wrote:

Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches.
But that doesn't help if that's then not happening in reality.  (With the
exception of Bernd, who then did review such patches for a while, but
also seems to have stopped with that again.)


As for this particular patch, I saw it go by, but there were a number of 
things that stopped me from looking at it which I'll try to explain. The 
one quoted seems to be just a resubmission of one that was posted 
towards the end of this thread:



.


(The resubmission should have contained a pointer to that thread).

That's a submission of three patches. If you follow that thread, you'll 
see that Jakub objected to one of them, asking you to provide a smaller 
one with just the necessary functional changes. In response you posted 
what appears to be just a merge of all three patches together. From my 
point of view, I see no reason to go near it if Jakub has unaddressed 
objections.


It's possible that I've misunderstood something, but that leads me to 
one piece of advice I could give (and I'm repeating myself here): write 
clearer patch introductions. After reading this:



On Wed, 13 Jul 2016 12:37:07 +0200, I wrote:

As discussed before, "offloading compilation is slow; I suppose because
of having to invoke several tools (LTO streaming -> mkoffload -> offload
compilers, assemblers, linkers -> combine the resulting images; but I
have not done a detailed analysis on that)".  For this reason it is
beneficial (that is, it is measurable in libgomp testing wall time) to
limit offload compilation to the one (in the OpenACC case) offload target
that we're actually going to test (that is, execute).  Another reason is
that -foffload=-fdump-tree-[...] produces clashes (that is,
unpredicatable outcome) in the file names of offload compilations' dump
files' names.  Here is a patch to implement that, to specify
-foffload=[...] during libgomp OpenACC testing.  As that has been
challenged before:

| [...] there actually is a difference between offload_plugins and
| offload_targets (for example, "intelmic"
| vs. "x86_64-intelmicemul-linux-gnu"), and I'm using both variables --
| to avoid having to translate the more specific
| "x86_64-intelmicemul-linux-gnu" (which we required in the test harness)
| into the less specific "intelmic" (for plugin loading) in
| libgomp/target.c.  I can do that, so that we can continue to use just a
| single offload_targets variable, but I consider that a less elegant
| solution.


I'm already somewhat confused about what you want to achieve and how. It 
sounds like you're trying to fix a dejagnu issue but then I look at the 
patch and see lots of libgomp configury changes.


Avoid writing information that is irrelevant to the patch at hand, such 
as most of the first sentence in the block quoted above. Don't quote 
yourself from past discussions, write something new that's specific and 
relevant to someone who's going to try and understand your patch. Try 
not to have three or four parenthetical comments in one sentence.


A better way to write the first paragraph might be:

"When testing libgomp for a compiler that supports more than one offload 
target, we iterate over the targets and run the test for each. That 
currently produces binaries for all offload targets, each time, which is 
wasted effort. Hence, this patch, which sets -foffload=xyz as 
appropriate.  This speeds up the compiler and also avoids name clashes 
between dump files."


That even adds information that was missing from your submission: I had 
to look at the patch to see that we iterate over targets, and that's 
relevant to the question of whether we need the patch or not.


Since the patch does way more, that needs to be adequately explained, 
and your original idea of a multi-part submission was in fact correct. 
You need to somehow deal with the fact that one of them was rejected, 
either using persuasion or reworking the other patches (possibly showing 
that such a reworking would be significantly worse).



Bernd

Re: style convention: /*foo_p=*/ to annotate bool arguments

[Bernd Schmidt]

On 10/04/2016 12:41 PM, Jonathan Wakely wrote:

On 4 October 2016 at 10:21, David Brown wrote:

On 04/10/16 01:48, Martin Sebor wrote:

In a recent review Jason and I discussed the style convention
commonly followed in the C++ front end to annotate arguments
in calls to functions taking bool parameters with a comment
along the lines of

  foo (1, 2, /*bar_p=*/true);


I like this convention at the call-site, otherwise "true" or "false"
doesn't tell you much and you have to look at the declaration.


Isn't that the case for "1" and "2" too?


IMHO even better is to not use bool and define an enumeration type, so
the call site has something unambiguous like foo (1, 2, yes_bar) or
foo (1, 2, no_bar).


Yeah, this I could get behind as a guideline (not really a rule) for new 
code.



Bernd

Re: basic_block flags, BB_VISITED

[Bernd Schmidt]

On 10/14/2016 10:01 AM, Thomas Schwinge wrote:

After the "Add Early VRP" GCC trunk commit r240291 (Kugan CC for your
information), I've been observing all kinds of OpenACC offloading
failures.  I now figured out what's going on.

The "evrp" pass uses basic_block's BB_VISITED flag.  It first clears
these all, gcc/tree-vrp.c:execute_early_vrp:

  FOR_EACH_BB_FN (bb, cfun)
{
  bb->flags &= ~BB_VISITED;

..., then does its processing, and at the end, clears these again:

  FOR_EACH_BB_FN (bb, cfun)
bb->flags &= ~BB_VISITED;

I note that this looks slightly different from what
gcc/cfg.c:clear_bb_flags whould be doing, which works from
ENTRY_BLOCK_PTR_FOR_FN onwards:


So maybe it should just call clear_bb_flags instead of doing the loop 
itself? Ok if that works.



Bernd

Re: basic_block flags, BB_VISITED

[Bernd Schmidt]

On 10/14/2016 11:26 AM, Richard Biener wrote:

On Fri, Oct 14, 2016 at 11:15 AM, Bernd Schmidt  wrote:

So maybe it should just call clear_bb_flags instead of doing the loop
itself? Ok if that works.


That doesn't generally work, it clears too many flags (it was appearantly
designed for RTL).


Or maybe it could be argued that more tree-specific flags ought to be in 
BB_FLAGS_TO_PRESERVE, or that it would make more sense to define a more 
specific BB_FLAGS_TO_KEEP.


So maybe just change the loop at the end of evrp, it clearly wants to 
clean up after itself so just make it do it reliably.



Bernd

Re: negative latencies

[Bernd Schmidt]

On 05/21/2014 05:30 PM, Vladimir Makarov wrote:

On 2014-05-20, 5:18 PM, shmeel gutl wrote:

The problem that I see is that the haifa scheduler schedules one cycle
at a time, in a forward order, by picking from a list of instructions
that can be scheduled without delays. So, in the above example, if
instruction one is scheduled during cycle 3, it can't schedule
instruction two during cycle 0, 1, or 2 because its producer dependency
(instruction one) hasn't been scheduled yet. It won't be able to
schedule it until cycle 3. So I am asking if there is an existing
mechanism to back schedule instruction two once instruction one is
issued.



I see, thanks.  There is no such mechanism in the current insn
scheduler.


Well, the scheduler has support for an exposed pipeline that is used by 
the C6X port. Insns are split into multiple pieces which are forced to 
be scheduled at a fixed distance in time from each other, each piece 
describing the effects that occur at that point in time.  This could 
probably be made to work for this target's requirements, but it might 
run quite slowly.



Bernd

Re: negative latencies

[Bernd Schmidt]

On 05/23/2014 10:07 AM, shmeel gutl wrote:


Exposed pipeline is not my problem. Negative latency is my problem. I
don't see negative latency for c6x, not in unit reservations and not in
adjust cost. Did I miss something?


You just need to model it differently. Rather than saying instruction A 
has a negative latency relative to instruction B, you need to describe 
that instruction B reads its inputs later than when it is actually 
issued. The mechanism used in the C6X backend is the scheduler's 
record_delay_slot_pair function.


The scheduler would see

B is issued (*)

A is issued, executes and writes its outputs

B reads its inputs (*)

The two insns marked as (*) would be such a delay pair. The first one 
would generate code, the second one exists only for the purposes of 
building the right scheduling dependencies.



Bernd

Re: [gomp4] Offloading wiki page

[Bernd Schmidt]

On 07/21/2014 09:07 PM, Ilya Verbin wrote:

I've created a wiki page about offloading.  Any improvements are welcome.


It says "Immutable Page", so I can't seem to edit it. Anyway, here are 
my thoughts on the configure/make changes (should go into the TODO section):


The host and offload compilers need to be able to find each other. This 
is achieved by installing the offload compiler into special locations, 
and informing each about the presence of the other. All available 
offload compilers must first be configured with 
"--enable-as-accelerator-for=host-triplet", and installed into the same 
prefix as the host compiler. Then the host compiler is built with 
"--enable-offload-targets=target1,target2,..." which identifies the 
offload compilers that have already been built and installed.


The install locations for the offload compilers differ from those of a 
normal cross toolchain, by the following mapping:


bin/$target-gcc   -> bin/$host-accel-$target-gcc
lib/gcc/$target/$ver/ -> lib/gcc/$host/$ver/accel/$target

It may be necessary to compile offload compilers with a sysroot, since 
otherwise install locations for libgomp could clash (maybe that library 
needs to move into lib/gcc/..?)


A target needs to provide a mkoffload tool if it wishes to be usable as 
an accelerator. It is installed as one of EXTRA_PROGRAMS, and the host 
lto-wrapper knows how to find it from the paths described above. 
mkoffload will invoke the offload compiler in LTO mode to produce an 
offload binary from the host object files, then post-process this to 
produce a new object file that can be linked in with the host 
executable. It can find the host compiler by examining $COLLECT_GCC, and 
it must take care to clear this and certain other environment variables 
when executing the offload compiler so as to not confuse it.


The object file produced with mkoffload should contain a constructor 
that calls GOMP_offload_register to identify itself at run-time. 
Arguments to that function are a symbol called __OPENMP_TARGET__, 
provided by libgcc and unique per shared object, a table with 
information about mappings between host and offload functions and 
variables, and a target identifier.


[ Note: on gomp-4_0-branch, all the Makefile bits aren't entirely 
working at the moment since we were intending to use a slightly 
different scheme for nvptx. However, this is how it should work after I 
get some patches installed. ]


For reference, I'm attaching my current version of ptx mkoffload.


Bernd

/* Offload image generation tool for ptx

   Nathan Sidwell 
   Bernd Schmidt 

   Munges PTX assembly into a C source file defining the PTX code as a
   string.

   This is not a complete assembler.  We presume the source is well
   formed from the compiler and can die horribly if it is not.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "intl.h"
#include 
#include "obstack.h"
#include "diagnostic-core.h"
#include "collect-utils.h"

const char tool_name[] = "nvptx mkoffload";

#define COMMENT_PREFIX "#"

typedef enum Kind
{
  /* 0-ff used for single char tokens */
  K_symbol = 0x100, /* a symbol */
  K_label,  /* a label defn (i.e. symbol:) */
  K_ident,  /* other ident */
  K_dotted, /* dotted identifier */
  K_number,
  K_string,
  K_comment
} Kind;

typedef struct Token
{
  unsigned short kind : 12;
  unsigned short space : 1; /* preceded by space */
  unsigned short end : 1;   /* succeeded by end of line */
  /* Length of token */
  unsigned short len;

  /* Token itself */
  char const *ptr;
} Token;

/* statement info */
typedef enum Vis
{
  V_dot = 0,  /* random pseudo */
  V_var = 1,  /* var decl/defn */
  V_func = 2, /* func decl/defn */
  V_insn = 3, /* random insn */
  V_label = 4, /* label defn */
  V_comment = 5,
  V_pred = 6,  /* predicate */
  V_mask = 0x7,
  V_global = 0x08, /* globalize */
  V_weak = 0x10,   /* weakly globalize */
  V_no_eol = 0x20, /* no end of line */
  V_prefix_comment = 0x40 /* prefixed comment */
} Vis;

typedef struct Stmt
{
  struct Stmt *next;
  Token *tokens;
  unsigned char vis;
  unsigned len : 12;
  unsigned sym : 12;
} Stmt;

struct id_map
{
  id_map *next;
  char *ptx_name;
};

static const char *read_file (FILE *);
static Token *tokenize (const char *);

static void write_token (FILE *, const Token *);
static void write_tokens (FILE *, const Token *, unsigned, int);

static Stmt *alloc_stmt (unsigned, Token *, Token *, const Token *);
#define alloc_comment(S,E) alloc_stmt (V_comment, S, E, 0)
#define append_stmt(V, S) ((S)->next = *(V), *(V) = (S))
static Stmt *rev_stmts (Stmt *);
static void write_stmt (FILE *, const Stmt *);
static void write_stmts (FILE *, const Stmt *);

static Token *parse_insn (Token *);
static Token *parse_list_nosemi (Token *);
static Token *parse_init (Token *);
static Tok

Re: [gomp4] Offloading wiki page

[Bernd Schmidt]

On 07/22/2014 01:24 PM, Thomas Schwinge wrote:
> On Tue, 22 Jul 2014 13:06:19 +0200, Bernd Schmidt 
 wrote:

>> It says "Immutable Page", so I can't seem to edit it.
>
> Probably applies for your write access to any wiki page, and that's
> because you've not been added to thw whitelist,
> <https://gcc.gnu.org/wiki/EditorGroup>?  I can add your ID, as can
> everyone else who already has access.

Sounds plausible. I couldn't remember enough account details to login or 
reset the password, so I made a new account, BerndSchmidt - if you could 
add that...



Bernd

Re: Offloading not relocatable

[Bernd Schmidt]

On 09/17/2014 04:42 PM, Jakub Jelinek wrote:

mkoffload should make similar attempts to find the offloading compiler
driver.  It should try (relative to mkoffload binary) probably:
../../../../../bin/x86_64-intelmic-linux-gnu-g++
(why does it try g++ and not gcc btw?), then perhaps:
./x86_64-intelmic-linux-gnu-g++
(so that one can e.g. put a symlink next to mkoffload and point it wherever 
needed)
and perhaps as last fallback, try to execute x86_64-intelmic-linux-gnu-g++
from PATH env var.


It should be easier - the nvptx mkoffload examines COLLECT_GCC for a 
path, and uses that if it's available (otherwise relying on PATH). I 
don't know what the mic offload is doing, I haven't looked yet.



Bernd

Re: Offloading not relocatable

[Bernd Schmidt]

On 09/17/2014 06:22 PM, Jakub Jelinek wrote:


which presumably means that some undesirable vars from host environment
were kept by mkoffload in the environment for the offloading compiler
and that has the undesirable effect of affecting how the offloading
compiler driver works.  Because, if I invoke
/usr/local/bin/x86_64-intelmic-linux-gnu-g++ manually, it can find cc1plus
just fine.


unset GCC_EXEC_PREFIX
in the /usr/local/bin/x86_64-intelmic-linux-gnu-g++ script somewhat helps,
presumably mkoffload shouldn't export GCC_EXEC_PREFIX env var when
calling the driver, as it should be driver's business to find everything
else on its own.


That's also a solved problem in nvptx mkoffload - you do need to unset 
these environment variables when invoking the target compiler. I've 
posted the source a few times but here it is again.



Bernd


/* Offload image generation tool for ptx

   Nathan Sidwell 
   Bernd Schmidt 

   Munges PTX assembly into a C source file defining the PTX code as a
   string.

   This is not a complete assembler.  We presume the source is well
   formed from the compiler and can die horribly if it is not.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "intl.h"
#include 
#include "obstack.h"
#include "diagnostic-core.h"
#include "collect-utils.h"

const char tool_name[] = "nvptx mkoffload";

#define COMMENT_PREFIX "#"

typedef enum Kind
{
  /* 0-ff used for single char tokens */
  K_symbol = 0x100, /* a symbol */
  K_label,  /* a label defn (i.e. symbol:) */
  K_ident,  /* other ident */
  K_dotted, /* dotted identifier */
  K_number,
  K_string,
  K_comment
} Kind;

typedef struct Token
{
  unsigned short kind : 12;
  unsigned short space : 1; /* preceded by space */
  unsigned short end : 1;   /* succeeded by end of line */
  /* Length of token */
  unsigned short len;

  /* Token itself */
  char const *ptr;
} Token;

/* statement info */
typedef enum Vis
{
  V_dot = 0,  /* random pseudo */
  V_var = 1,  /* var decl/defn */
  V_func = 2, /* func decl/defn */
  V_insn = 3, /* random insn */
  V_label = 4, /* label defn */
  V_comment = 5,
  V_pred = 6,  /* predicate */
  V_mask = 0x7,
  V_global = 0x08, /* globalize */
  V_weak = 0x10,   /* weakly globalize */
  V_no_eol = 0x20, /* no end of line */
  V_prefix_comment = 0x40 /* prefixed comment */
} Vis;

typedef struct Stmt
{
  struct Stmt *next;
  Token *tokens;
  unsigned char vis;
  unsigned len : 12;
  unsigned sym : 12;
} Stmt;

struct id_map
{
  id_map *next;
  char *ptx_name;
};

static const char *read_file (FILE *);
static Token *tokenize (const char *);

static void write_token (FILE *, const Token *);
static void write_tokens (FILE *, const Token *, unsigned, int);

static Stmt *alloc_stmt (unsigned, Token *, Token *, const Token *);
#define alloc_comment(S,E) alloc_stmt (V_comment, S, E, 0)
#define append_stmt(V, S) ((S)->next = *(V), *(V) = (S))
static Stmt *rev_stmts (Stmt *);
static void write_stmt (FILE *, const Stmt *);
static void write_stmts (FILE *, const Stmt *);

static Token *parse_insn (Token *);
static Token *parse_list_nosemi (Token *);
static Token *parse_init (Token *);
static Token *parse_file (Token *);

static Stmt *decls;
static Stmt *vars;
static Stmt *fns;

static id_map *func_ids, **funcs_tail = &func_ids;
static id_map *var_ids, **vars_tail = &var_ids;

/* Files to unlink.  */
static const char *ptx_name;
static const char *ptx_cfile_name;

/* Delete tempfiles.  */

/* Unlink a temporary file unless requested otherwise.  */

void
maybe_unlink (const char *file)
{
  if (! debug)
{
  if (unlink_if_ordinary (file)
  && errno != ENOENT)
fatal_error ("deleting file %s: %m", file);
}
  else
fprintf (stderr, "[Leaving %s]\n", file);
}

void
tool_cleanup (bool)
{
}

/* Add or change the value of an environment variable, outputting the
   change to standard error if in verbose mode.  */
static void
xputenv (const char *string)
{
  if (verbose)
fprintf (stderr, "%s\n", string);
  putenv (CONST_CAST (char *, string));
}


static void
record_id (const char *p1, id_map ***where)
{
  const char *end = strchr (p1, '\n');
  if (!end)
fatal_error ("malformed ptx file");

  id_map *v = XNEW (id_map);
  size_t len = end - p1;
  v->ptx_name = XNEWVEC (char, len + 1);
  memcpy (v->ptx_name, p1, len);
  v->ptx_name[len] = '\0';
  v->next = NULL;
  id_map **tail = *where;
  *tail = v;
  *where = &v->next;
}

/* Read the whole input file.  It will be NUL terminated (but
   remember, there could be a NUL in the file itself.  */

static const char *
read_file (FILE *stream)
{
  size_t alloc = 16384;
  size_t base = 0;
  char *buffer;

  if (!fseek (stream, 0, SEEK_END))
{
  /* Get the file size.  */
  long s = ftell (stream);
  if (

Re: Offloading not relocatable

[Bernd Schmidt]

On 09/17/2014 06:39 PM, Ilya Verbin wrote:

Yeah, I got that all these prefixes are not working with modified
DESTDIR.  I’ll fix mkoffload.

2014-09-17 20:30 GMT+04:00 Bernd Schmidt :

That's also a solved problem in nvptx mkoffload - you do need to unset these
environment variables when invoking the target compiler. I've posted the
source a few times but here it is again.


I see there:
   unsetenv ("GCC_EXEC_PREFIX");
   unsetenv ("COMPILER_PATH");
   unsetenv ("LIBRARY_PATH");

Or do you mean, that there is no need to set them to the new values
before invoking the target compiler?


Exactly - you need to unset them before calling x86-accel-nvptx-gcc, but 
that driver has its own logic to find its binaries, so nothing else is 
necessary. You need to know where to find x86-accel-nvptx-gcc, and that 
can be done by examining COMPILER_PATH.



Bernd

Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th

[Bernd Schmidt]

On 11/03/2014 10:18 AM, Jakub Jelinek wrote:

What larger merges are still planned for GCC 5?
I'm aware of pending merges from match-and-simplify branch, there
are the JIT changes partially? approved, MPX also partially? approved,
Intel offloading patches partially approved, PTX support partially
reviewed.


I think the basic ptx port has been fully reviewed and I'll start 
checking things in soon. The offloading pieces have depend on Ilya's 
patches. I'll let Thomas answer about the plan for OpenACC changes.



Bernd

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

[Bernd Schmidt]

On 11/11/2014 09:30 AM, Eric Botcazou wrote:

I just don't like all the as_a/is_a stuff enforced everywhere,
it means more typing, more temporaries, more indentation.
So, as I view it, instead of the checks being done cheaply (yes, I think
the gimple checking as we have right now is very cheap) under the
hood by the accessors (gimple_assign_{lhs,rhs1} etc.), those changes
put the burden on the developers, who has to check that manually through
the as_a/is_a stuff everywhere, more typing and uglier syntax.
I just don't see that as a step forward, instead a huge step backwards.
But perhaps I'm alone with this.


IMO that's the sort of things some of us were afraid of when the C++ switch
was being discussed and IIRC we were told this would not happen...


I'm with both of you on this.


Bernd

Re: Bernd Schmidt appointed as nvptx port maintainer

[Bernd Schmidt]

On 11/21/2014 06:57 PM, Jeff Law wrote:

Bernd, please add yourself as the maintainer for that port in the
MAINTAINERS file.


Thanks, done.


Bernd

Re: Proposal for the transition timetable for the move to GIT

[Bernd Schmidt]

On 12/6/19 6:21 PM, Eric S. Raymond wrote:


Your approach sounds pretty reasonable except for that part. I don't
trust git-svn at *all* - I've collided with it too often during
past conversions.  It has a nasty habit of leaving damage in places
that are difficult to audit.


So, which steps are we taking to ensure such damage does not occur with 
either method of conversion? Do we have any verification scripts already?



Bernd

Re: Proposal for the transition timetable for the move to GIT

[Bernd Schmidt]

On 12/9/19 7:19 PM, Joseph Myers wrote:


For any conversion we're clearly going to need to run various validation
(comparing properties of the converted repository, such as contents at
branch tips, with expected values of those properties based on the SVN
repository) and fix issues shown up by that validation.  reposurgeon has
its own tools for such validation; I also intend to write some validation
scripts myself.


Would it be feasible to require that both conversions produce the same 
output repository to some degree? Can we just look at release tags and 
require that they have the same hash in both conversions, or are there 
good reasons why the two would produce different outputs?




Bernd

Re: Test GCC conversion with reposurgeon available

[Bernd Schmidt]

On 12/17/19 10:32 PM, Joseph Myers wrote:

git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git


It seems that permission bits are not reproduced entirely correctly. For 
example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and 
the git-svn repository) to -rw-r--r-- in this new git repository.


I vote for including .cvsignore files. Their absence makes diff 
comparisons of "git ls-tree" on specific revisions needlessly noisy.



Bernd

Re: Test GCC conversion with reposurgeon available

[Bernd Schmidt]

On 12/18/19 10:55 PM, Joseph Myers wrote:

git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git


I cloned this one and started trying random things again.
The previous one had some strange-looking merge commits, but it sounded 
like that was a known issue, and indeed the ones I had seen were fixed 
in this new version.
I decided to write a small script to check whether there were any merge 
commits with more than two parents, and there are a few which have 
three. One commit seems to occur as a parent in all of these: 
422854db0e8605867e0834035aa2b1da1b71cbfb. An example is 
b743e467e43e6211f2c2537f1f07bbceb4d3aa61, apparently from spu-4_5-branch.


No idea whether there is an issue or whether this is worth looking at, 
but I figured I'd point it out at least.



Bernd

Re: Proposal for the transition timetable for the move to GIT

[Bernd Schmidt]

On 1/10/20 8:33 AM, Maxim Kuvyrkov wrote:

Joseph, please point to message on gcc@ mailing list that expresses consensus 
of GCC community to use reposurgeon conversion.  Otherwise, it is not 
appropriate to substitute one's opinion for community consensus.


I was on the fence for a long time, since I felt that the rewritten 
reposurgeon was still somewhat unproven. However, I think the 
reposurgeon conversion is probably the best choice at this point, given 
that an actual problem caused by the use of git-svn was demonstrated by 
Richard E, indicating that the scripts do not have an inherent 
reliability advantage. I also think Joseph has a very throrough pair of 
eyeballs.


I have no opinion one way or another which method should be used to 
identify author names, since I have not looked into that.



Bernd

Re: Improving code generation in the nvptx back end

[Bernd Schmidt]

On 02/17/2017 02:09 PM, Thomas Schwinge wrote:

Hi!

On Fri, 17 Feb 2017 14:00:09 +0100, I wrote:

[...] for "normal" functions there is no reason to use the
".param" space for passing arguments in and out of functions.  We can
then get rid of the boilerplate code to move ".param %in_ar*" into ".reg
%ar*", and the other way round for "%value_out"/"%value".  This will then
also simplify the call sites, where all that code "evaporates".  That's
actually something I started to look into, many months ago, and I now
just dug out those changes, and will post them later.

(Very likely, the PTX "JIT" compiler will do the very same thing without
difficulty, but why not directly generate code that is less verbose to
read?)


Using my WIP patch, the generated PTX code changes/is simplified as
follows:


It's probably a good idea to run cuobjdump -sass to see whether this has 
any effect at all.


The most important issue that needs solving is probably still the old 
issue that ptxas isn't reliable. Looks like the llvm folks ran into the 
same problem, as I discovered last week:

  https://bugs.llvm.org//show_bug.cgi?id=27738


Bernd

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Bernd Schmidt]

On 03/17/2017 07:38 PM, Pinski, Andrew wrote:

One of the following revision caused a bootstrap comparison failure on 
aarch64-linux-gnu:
r246225
r246226
r246227


Can you help narrow that down?


Bernd

Re: combiner: how to compute cost for bit insertion?

[Bernd Schmidt]

On 07/10/2017 05:10 PM, Georg-Johann Lay wrote:
> (set (zero_extract:QI (reg/i:QI 24 r24)
> (const_int 1 [0x1])
> (const_int 6 [0x6]))
> (lshiftrt:QI (reg:QI 52)
> (const_int 6 [0x6])))

> The problem is that the backend only sees
> 
> avr_rtx_costs[bset:combine(266)]=true (size) total=24, outer=set:
> (lshiftrt:QI (reg:QI 52)
> (const_int 6 [0x6]))

> How can I fix that?

I've thought for a while is that (set (zero_extract)) is a crazy way to
express this kind of operation. This should be

(set (destreg) (bfinsert (input) (bitpos) (len) (value))

Adding an rtx code like that is trivial, but ideally all the code that
understands set of zero_extract would also be updated to understand the
new form.


Bernd

Re: Possible bug in cse.c affecting pre/post-modify mem access

[Bernd Schmidt]

On 05/12/2018 07:01 PM, Jeff Law wrote:

> No.  We're not supposed to have any auto-inc insns prior to the auto-inc
> pass.  A stack push/pop early in the compiler would have to be
> represented by a PARALLEL.
> 
> It's been this way forever.  It's documented in the internals manual
> somewhere.

Sorry, but you're misremembering this. Stack pushes/pops were always
represented with autoinc, these being the only exception to the rule you
remember. You can easily verify this by looking at a .expand dump from a
32-bit i386 compiler - I just did so with 2.95 and 6.4. It's all pre_dec
for argument passing.


Bernd

Re: Possible bug in cse.c affecting pre/post-modify mem access

[Bernd Schmidt]

On 05/14/2018 10:55 PM, Jeff Law wrote:
> That does sound vaguely familiar.  Did we put autoinc notes on the stack
> pushes?

Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps.

> That makes me wonder if there is a latent bug though.  Consider pushing
> args to a pure function.  Could we then try to CSE the memory reference
> and get it wrong because we haven't accounted for the autoinc?

Can't know for sure but one would hope something would test for
side_effects_p.


Bernd

Re: Possible bug in cse.c affecting pre/post-modify mem access

[Bernd Schmidt]

On 05/15/2018 12:58 PM, A. Skrobov wrote:
>>> That makes me wonder if there is a latent bug though.  Consider pushing
>>> args to a pure function.  Could we then try to CSE the memory reference
>>> and get it wrong because we haven't accounted for the autoinc?
>>
>> Can't know for sure but one would hope something would test for
>> side_effects_p.
> 
> If side_effects_p were checked in all the right places, then our port
> (which is more liberal at generating auto-inc insns in early passes)
> wouldn't have cse generate incorrect code, right?

No, I'd expect you'd also need to make sure cse and other passes
understand the side effects. I think it's best not to emit these insns
early, unless you are prepared to put a lot of effort in to fix up the
early passes. My recommendation is to change the port.


Bernd

Re: Repo conversion troubles.

[Bernd Schmidt]

On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly.  This time I have mismatches in the following
> files.

So what are the diffs? Are we talking about small differences (like one
change missing) or large-scale mismatches?


Bernd

Scheduling automaton question

[Bernd Schmidt]

Suppose I have two insns, one reserving (A|B|C), and the other reserving
A. I'm observing that when the first one is scheduled in an otherwise
empty state, it reserves the A unit and blocks the second one from being
scheduled in the same cycle. This is a problem when there's an
anti-dependence of cost 0 between the two instructions.

Vlad - two questions. Is this behaviour what you would expect to happen,
and how much work do you think would be involved to fix it (i.e. make
the first one transition to a state where we can still reserve any two
out of the three units)?


Bernd

Re: Scheduling automaton question

[Bernd Schmidt]

On 02/11/2011 02:13 PM, Alexander Monakov wrote:
> Could you please clarify a bit: would the modified behavior match what your
> target CPU does?  The current behavior matches CPUs without lookahead in
> instruction dispatch: the first insn goes to the first matching execution
> unit (A), the second has to wait.

The CPU I'm working on needs to specify explicitly which unit an insn is
using, but to generate optimal code that assignment must be made _after_
scheduling all the insns in a given cycle.


Bernd

Re: Scheduling automaton question

[Bernd Schmidt]

On 02/11/2011 07:43 PM, Frédéric RISS wrote:
> Le vendredi 11 février 2011 à 13:33 +0100, Bernd Schmidt a écrit :
>> Suppose I have two insns, one reserving (A|B|C), and the other reserving
>> A. I'm observing that when the first one is scheduled in an otherwise
>> empty state, it reserves the A unit and blocks the second one from being
>> scheduled in the same cycle. This is a problem when there's an
>> anti-dependence of cost 0 between the two instructions.
> 
> If you generate a NDFA ( using '(automata_option "ndfa")' ) it should
> allow you to schedule both instructions together as this should try all
> functional unit alternatives. 

Ah, that seems to be exactly what I was looking for. Thanks!
I'd expect this won't work too well with define_query_cpu_unit, so I'll
need another method to assign units after scheduling.


Bernd

Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)

[Bernd Schmidt]

On 04/04/2011 11:58 PM, Steven Bosscher wrote:

> In the PR audit trail, I've proposed to revert the patch, and HJ and
> Benjamin are also in favor of that. In Benjamin's works: Bootstrap has
> been broken for much too long, on all the common devel arches.

Which is not actually true, see the second-to-last message in that bug:

"But x86/Linux, x86-64/Linux, x86-64/Darwin, x86/Solaris and
SPARC/Solaris now bootstrap fine for me so there is some progress."

What's still broken is --disable-checking bootstrap on i686-linux. This
reproduces for me with both with a tree checked out at revision 171823,
which is the one before my checkins, and a current tree with my patches
reverted. There's a tendency for people to pile on an existing bugzilla
report rather than properly investigate what's actually causing their
problems.

What's left are failures on mips64-linux and ia64, which I'm
investigating now. I don't think anyone has done a proper analysis for
what caused them either, although I guess my prune_ready_list patch is a
major suspect. Clearly this is unfortunate, but I don't think these two
are common devel arches either, as claimed by Steven.


Bernd

Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)

[Bernd Schmidt]

On 04/05/2011 12:51 AM, Ian Lance Taylor wrote:
> Steven Bosscher  writes:
> 
>> My proposal would be: A patch may be reverted immediately by anyone
>> with SVN write access if bootstrap is broken for more than 24 hours on
>> any primary target. With proper notification to everyone involved,
>> obviously.
> 
> I agree.
> 
> At the summit in October there was a discussion about this.  I was on
> the side of fast rollback for new failures.  Would anybody care to
> present the opposite view with regard to a patch like this?  Can we
> agree on fast rollback for bootstrap failures on x86/x86_64 GNU/Linux
> systems?

For i686-linux bootstraps it's hard to argue against it, but in general
I find it easier to cope with the occasional broken tree than with
getting patches reverted when you can't reproduce the failure. A while
ago ARM was broken for what seemed like a long time; didn't stop me from
testing ARM patches.

Another danger is getting a mob effect as in PR48403 (which I've also
seen happen on other occasions) and getting the wrong set of patches
reverted by trigger-happy people. To be blunt, there are some people on
this list who tend to react panicky to bugs and skip proper analysis (as
in this case); I don't want to encourage such folks to revert stuff
willy-nilly. Sometimes you just need a bit of time and assistance from
testers who actually see the problem to understand it.

If there's a change in policy I'd at least make allowances for weekends.
There's considerably less traffic on the mailing lists on Saturdays and
Sundays, which suggests few people will be inconvenienced if the tree is
broken during such a time. We also don't want everyone to only check
things in on Mondays because they worry they'll come back after a
weekend to find their stuff gone from the tree.


Bernd

Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)

[Bernd Schmidt]

On 04/05/2011 08:26 AM, Steven Bosscher wrote:
> On Tue, Apr 5, 2011 at 3:14 AM, Bernd Schmidt  wrote:
> 
>> For i686-linux bootstraps it's hard to argue against it, but in general
>> I find it easier to cope with the occasional broken tree than with
>> getting patches reverted when you can't reproduce the failure.
> 
> Maybe you find that easier, but auto-testers do not.

The auto-testers serve the developers, not the other way round.


Bernd

Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)

[Bernd Schmidt]

On 04/05/2011 08:26 AM, Steven Bosscher wrote:
> I don't understand, really, why it's such a big deal to revert a patch
> quickly if it broke something.

To answer this as well, firstly a proposal that comes with a request to
revert the wrong patch discredits itself.

Breaking stuff by accident is a fact of life with gcc. You have to give
people the chance to investigate and understand the problems. Since I
know what it's like to break things by accident, I don't like to shout
and complain at others when it happens to them, especially since it's
never been more than an inconvenience for me if a particular revision of
trunk was broken. I just use an earlier one, or revert the problematic
patch.

We're in stage 1, and this isn't primarily about keeping the autotesters
happy. If that was our goal we'd stay in stage 4.

> You feel mobbed and I'm sorry you feel that
> way, but it shows that a lot of people tried to work on GCC in that
> weekend.

Actually, this happened _after_ I checked in the fix for the bootstrap
issue (well, HJ checked it in without waiting for the test results).
When the tree was working again, you, HJ and bkoz decided that my
patches needed to be reverted, based on no actual facts whatsoever. This
demonstrates that we need to be careful, and that the decision to revert
something cannot be left to the whims of random people.

Once I managed to reproduce the problem I gave an ETA for the fix. After
that (on Sunday and early Monday) there was little activity on the bug.
No one asked me to revert anything until _after_ the problem was fixed.


Bernd

Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)

[Bernd Schmidt]

On 04/05/2011 02:23 PM, Steven Bosscher wrote:

> However, my point is that developers can investigate breakage without
> keeping the trunk broken.

If they can reproduce it; you don't always have access to the system
that shows the breakage. A reversion policy that's too trigger-happy can
leave you unable to make forward progress on an important patch. At the
very least you'd need to write in stone that a patch can be reinstalled
if the reporter of the problem is unwilling to assist in debugging or
testing candidate patches.

I agree that i686-linux bootstraps could be treated slightly more
aggressively, but I'd still like to limit the set of people who can make
such a decision.

In this particular case, if anyone wanted the patch reverted they should
have said something on Friday or Saturday. The scale of the problem
wasn't apparent to me at the beginning since I was bootstrapping
successfully on two different machines, both on x86_64 and i686
(admittedly due to idiocy in the way I was configuring the compiler).


Bernd

Re: To Steering Committee: RFC for patch revert policy (PR48403, bootstrap broken on many targets)

[Bernd Schmidt]

On 04/05/2011 04:49 PM, Jeff Law wrote:
> On 04/04/11 20:57, H.J. Lu wrote:
>> Patch was checked in at Fri Apr  1 17:46:17 2011.  I reported the failure
>> at 2011-04-01 18:49:28 and identified the range of causes.  It is too bad
>> to take 3 days to fix it.
> Note the checking was Friday evening, it's entirely possible that the
> offender has a life and didn't work over the weekend.

The offender worked a number of hours Saturday to reproduce the problem
and investigate its cause. When it became apparent in the very late
evening that the fix would be more than a one-liner and would involve
testing some nonstandard options on ppc, I posted a status update with
an ETA. IMO that (or earlier) would have been a good moment for anyone
who was unable to do development work on Sunday due to the breakage to
ask for a revert, rather than overreact later _after_ the problem was fixed.
My (incorrect) perspective at that point was still that I had successful
bootstraps on two machines with three different installations of Linux,
vs a failure on only one, and no one had asked for the patch to be
reverted, so the problem was likely to be not too bad. The fact that
other architectures than x86 were affected had also not been reported at
the time.


Bernd

Re: gcc detect multiple -o passed on one command line

[Bernd Schmidt]

On 05/05/2011 11:53 PM, Ian Lance Taylor wrote:
> Jon Grant  writes:
> 
>> Is it expected that more than one -o option should be allowed by GCC
>> on command line? The later -o option overriding earlier.
> 
> Yes, this is expected.  Most Unix utilities behave that way: when an
> option with an argument is specified twice, and it only makes sense to
> specify it once, then the option argument which comes last is used.

Huh. If you add -E to the command line you get

  cc1: error: output filename specified twice

so we're a little inconsistent here.


Bernd

C6X port 13/11: MAINTAINERS

[Bernd Schmidt]

On 05/10/2011 06:51 PM, Joseph S. Myers wrote:

> * If you are volunteering to be maintainer of the port, make that explicit 
> (and probably post to gcc@ for the attention of the SC; maintainership 
> needs approving by the SC, separately from the technical review of the 
> patches).

Patch appended.


Bernd
* MAINTAINERS (c6x port): New entry.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 173563)
+++ MAINTAINERS (working copy)
@@ -50,6 +50,7 @@ avr port  Anatoly Sokolov ae...@post.ru
 avr port   Eric Weddington eric.wedding...@atmel.com
 bfin port      Bernd Schmidt   ber...@codesourcery.com
 bfin port  Jie Zhang   jzhang...@gmail.com
+c6x port       Bernd Schmidt   ber...@codesourcery.com
 cris port  Hans-Peter Nilsson  h...@axis.com
 fr30 port  Nick Cliftonni...@redhat.com
 frv port   Nick Cliftonni...@redhat.com

Re: Wrong code: missing input reload

[Bernd Schmidt]

On 06/01/2011 04:00 PM, Georg-Johann Lay wrote:
> Eric Botcazou schrieb:
>>> You are right, I was staring at the wrong place. subreg of hardreg
>>> should not be there.
>>
>> You can take a look at PR target/48830, this is a related problem for the 
>> SPARC where reload generates:
>>
>> (set (reg:SI 708 [ D.2989+4 ])
>> (subreg:SI (reg:DI 72 %f40) 4))
>>
>> and (subreg:SI (reg:DI 72 %f40) 4) isn't simplifiable either.  H.P. wrote a 
>> tentative patch for the subreg machinery to forbid this.  Other references 
>> are:
>>   http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01688.html
>>   http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01743.html
> 
> The problems is that find_reloads generates the wrong reload type.
> 
> It sets the reload_type of "=" operands to RELOAD_WRITE. But for
> subregs as above, there are bits between inner mode and outer mode
> that already contain meaningful data and that data isn't wiped out by
> writing to the subreg (because outer mode is > word_mode).
> 
> Thus, a patch could look like that:
[...]
> Is this a reasonable fix?

I don't really think so. You'll need to find out where the subreg of a
hard register was made and stop it from doing that.


Bernd