Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Tristan Gingold]

Hi,

did you try with this patch:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html

Tristan.

On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote:

> Hi,
> 
> This modification (assertion) is causing failure in ia64-hp-hpux11.23:
> 
> r187199 | rsandifo | 2012-05-05 10:41:49 -0700 (Sat, 05 May 2012) | 247 lines
> Changed paths:
>   M /trunk/gcc/explow.c
>   * explow.c (plus_constant, plus_constant_mode): Likewise.  Assert that 
> the mode is sensible.
> 
> Haven't analyzed the issue. Thought of checking, if it is a known issue.
> 
> Error:
> --
> test.c: In function 'main':
> test.c:5:7: internal compiler error: in plus_constant, at explow.c:88
>   boo (&iarr[1]);
>   ^
> 
> Testcase (test.c):
> --
> int iarr[2];
> extern int boo(int *);
> 
> int main(void) {
>  boo (&iarr[1]);
>  return 0;
> }
> 
> Compilation command: 
> 
> gcc -c test.c
> ^ This compiler is built out of revision 187199 (trunk). Error attached above.
> 
> Configuration:
> --
> COLLECT_GCC=.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/xgcc
> Target: ia64-hp-hpux11.23
> Configured with: ...gcc/src/configure --host=ia64-hp-hpux11.23 
> --build=ia64-hp-hpux11.23 --prefix=.../gcc-ia64-hp-hpux11.23-trunk \
> --with-local-prefix=.../gcc-ia64-hp-hpux11.23-trunk --disable-nls \
> --with-gmp=.../ia64-hp-hpux11.23 --with-mpfr=.../ia64-hp-hpux11.23 \
> --with-mpc=.../ia64-hp-hpux11.23 --with-libelf=.../ia64-hp-hpux11.23 \
> --disable-libmudflap --enable-libunwind-exceptions SED=/usr/bin/sed \
> --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.8.0 20120505 (experimental) (GCC)
> COLLECT_GCC_OPTIONS='-B' '/.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/' 
> '-c' '-v'
> GNU C (GCC) version 4.8.0 20120505 (experimental) (ia64-hp-hpux11.23)
> compiled by GNU C version 4.5.1, GMP version 4.2.4, MPFR version 2.4.1, MPC 
> version 0.8
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> 
> Regards,
> Kannan
> 

RE: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

[Mailaripillai, Kannan Jeganathan]

Thanks Tristan. I have not applied this patch. I will give it a try.

Regards,
Kannan

-Original Message-
From: Tristan Gingold [mailto:ging...@adacore.com] 
Sent: Wednesday, May 30, 2012 1:46 PM
To: Mailaripillai, Kannan Jeganathan
Cc: gcc@gcc.gnu.org
Subject: Re: regression due to r187199 explow.c? in target ia64-hp-hpux11.23.

Hi,

did you try with this patch:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html

Tristan.

On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote:

> Hi,
> 
> This modification (assertion) is causing failure in ia64-hp-hpux11.23:
> 
> r187199 | rsandifo | 2012-05-05 10:41:49 -0700 (Sat, 05 May 2012) | 247 lines
> Changed paths:
>   M /trunk/gcc/explow.c
>   * explow.c (plus_constant, plus_constant_mode): Likewise.  Assert that 
> the mode is sensible.
> 
> Haven't analyzed the issue. Thought of checking, if it is a known issue.
> 
> Error:
> --
> test.c: In function 'main':
> test.c:5:7: internal compiler error: in plus_constant, at explow.c:88
>   boo (&iarr[1]);
>   ^
> 
> Testcase (test.c):
> --
> int iarr[2];
> extern int boo(int *);
> 
> int main(void) {
>  boo (&iarr[1]);
>  return 0;
> }
> 
> Compilation command: 
> 
> gcc -c test.c
> ^ This compiler is built out of revision 187199 (trunk). Error attached above.
> 
> Configuration:
> --
> COLLECT_GCC=.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/xgcc
> Target: ia64-hp-hpux11.23
> Configured with: ...gcc/src/configure --host=ia64-hp-hpux11.23 
> --build=ia64-hp-hpux11.23 --prefix=.../gcc-ia64-hp-hpux11.23-trunk \
> --with-local-prefix=.../gcc-ia64-hp-hpux11.23-trunk --disable-nls \
> --with-gmp=.../ia64-hp-hpux11.23 --with-mpfr=.../ia64-hp-hpux11.23 \
> --with-mpc=.../ia64-hp-hpux11.23 --with-libelf=.../ia64-hp-hpux11.23 \
> --disable-libmudflap --enable-libunwind-exceptions SED=/usr/bin/sed \
> --enable-languages=c,c++,fortran
> Thread model: posix
> gcc version 4.8.0 20120505 (experimental) (GCC)
> COLLECT_GCC_OPTIONS='-B' '/.../build-ia64-hp-hpux11.23-trunk/obj_gcc/gcc/' 
> '-c' '-v'
> GNU C (GCC) version 4.8.0 20120505 (experimental) (ia64-hp-hpux11.23)
> compiled by GNU C version 4.5.1, GMP version 4.2.4, MPFR version 2.4.1, MPC 
> version 0.8
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> 
> Regards,
> Kannan
> 

Re: How to compare two text files? Using sed, cmp, diff, tr?

[Georg-Johann Lay]

Joern Rennecke wrote:
> Quoting Georg-Johann Lay:
> 
>> The sed -e 's:\r::g' from above that tries to fix line endings has the
>> problem that not all sed implementations are the same, i.e. some just do
>> sed -e 's:r::g' and remove all r's.
>>
>> I searched some time how to accomplish this but did not find a neat
>> solution.
>>
>> Can tr from roff be used? Is it a valid prerequisite for GCC?
> 
> tr is already used in a number of places in Makefile.in.  Note
> that there is a distinction between tools required to rebuild
> auto-generated files, and tool required to build GCC assuming all
> auto-generated files are up-to-date.  You should make it so that tr
> is not used if the timestamps indicate that the documentation
> is up-to-date.

The rebuild/nag part is inside the backend's t-snip so that only people
(re)building that target will trigger the rebuild and checking

> Look for the s-tm-texi rule in Makefile.in, it normalizes the line ending
> using tr (while taking care of a Solaris oddity), before comparing it to
> the existing version.

Thanks, the patch uses the same technique now:

http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01982.html

Johann

GCC 4.7.1 Status Report (2012-05-30)

[Richard Guenther]

Status
==

The GCC 4.7 branch is in regression and documentation fixes only state.

A release candidate for GCC 4.7.1 is scheduled for the beginning of
next week.  This is a good time to verify regression status for
your favorite target and to consider to flush your pending 4.7-branch
patches list.

As usual the number of bugs is slowly increasing.  Still many serious
bugs have been fixed.


Quality Data


Priority  #   Change from Last Report
---   ---
P10
P2   85   + 19 
P35   -  8 
---   ---
Total90   + 11


Previous Report
===

http://gcc.gnu.org/ml/gcc/2012-03/msg00345.html

The next report will be sent by me when announcing the release
candidate.

Re: Maybe expand MAX_RECOG_ALTERNATIVES ?

[Hans-Peter Nilsson]

On Fri, 11 May 2012, Greg McGary wrote:
> On 05/11/12 16:00, Greg McGary wrote:
>
> > My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so
> > that I can use insn attributes to identify operand signatures, or should I 
> > use
> > another approach?
>
> After some exploration, I don't see that another approach is even possible.  
> The
> predicates in define_insn_reservation must be statically evaluated by 
> genattrtab,
> so I can't use (match_test "...") or (symbol_ref "..."), where "..." is 
> arbitrary
> C code.  Is it true that define_insn_reservation predicates can only use 
> boolean
> expressions on (eq_attr ...), or am I missing something?

Seeing this hasn't been replied to yet, I can't help but stating
the obvious: handle it like MAX_RECOG_OPERANDS.  Trivially, just
count the commas (the alternatives) in define_insn and friends.
(I don't think commas are allowed in constraints; if they are,
you may have to restrict the new max to targets using
define_constraint and friends and let the others stay with 30.)

Patches are welcome but be prepared for a lengthy ping session
as always. :/

brgds, H-P

Re: ICE with MEM_REF when Pmode is different from word_mode

[Mohamed Shafi]

On 29 May 2012 17:31, Richard Guenther  wrote:
> On Tue, May 29, 2012 at 1:57 PM, Mohamed Shafi  wrote:
>> Hi,
>>
>> I am porting a private target in GCC 4.6.3 version. For my target
>> pointer size is 24bits and word size is 32bits. Moreover a byte is
>> 32bit
>>
>> For the testcase gcc.c-torture/compile/92-1.c i get the following ICE
>>
>> 92-1.c: In function 'f':
>> 92-1.c:18:5: internal compiler error: in size_binop_loc, at
>> fold-const.c:1436
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions
>>
>> This is the reduced testcase of the same
>>
>>  struct vp {
>>  int wa;
>> };
>>
>> typedef struct vp *vpt;
>>
>> typedef struct vc {
>>  int o;
>>  vpt py[8];
>> } *vct;
>>
>> typedef struct np *npt;
>> struct np {
>>  vct d;
>>  int di;
>> };
>>
>> int f(npt dp)
>> {
>>  vpt *py;
>>
>>  py = &dp->d->py[dp->di];
>>  return (int)(py[1])->wa;
>> }
>>
>> The ICE happens in tree_slp_vectorizer pass. The following is the tree
>> dump just before that
>>
>> ;; Function f (f)
>>
>> f (struct np * dp)
>> {
>>  struct vp * D.1232;
>>  int D.1230;
>>  unsigned int D.1228;
>>  int D.1227;
>>  struct vc * D.1225;
>>
>> :
>>  D.1225_2 = dp_1(D)->d;
>>  D.1227_4 = dp_1(D)->di;
>>  D.1228_5 = (unsigned int) D.1227_4;
>>  D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0 sz: 4};
>>  D.1230_10 = D.1232_9->wa;
>>  return D.1230_10;
>> }
>>
>> The ICE happens for
>>
>>  D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0 sz: 4};
>>
>> This is due to the addition of the new code in tree-data-ref.c (this
>> is was not there in 4.5 series)
>>
>>  if (TREE_CODE (base) == MEM_REF)
>>    {
>>      if (!integer_zerop (TREE_OPERAND (base, 1)))
>>        {
>>          if (!poffset)
>>            {
>>              double_int moff = mem_ref_offset (base);
>>              poffset = double_int_to_tree (sizetype, moff);
>>            }
>>          else
>>            poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND (base, 1));
>
> This should use mem_ref_offset, too.
>

This is present in the trunk also. Will you be submitting a patch for this?

Shafi

Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

[H.J. Lu]

Hi,

On Linux/i386:

[hjl@gnu-29 ~]$ echo __WCHAR_TYPE__ | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 1 ""
long int
[hjl@gnu-29 ~]$

On Linux/x86-64:

[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -
# 1 ""
# 1 ""
# 1 ""
# 1 ""
int
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -mx32 -E -
# 1 ""
# 1 ""
# 1 ""
# 1 ""
int
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m64 -E -
# 1 ""
# 1 ""
# 1 ""
# 1 ""
int
[hjl@gnu-6 include]$

Is this intentional?

-- 
H.J.

Re: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

[Joseph S. Myers]

On Wed, 30 May 2012, H.J. Lu wrote:

> On Linux/i386:

> long int

> On Linux/x86-64:
> 
> [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -

> int

That's a bug.  Not a very serious one - it doesn't affect C++ name 
mangling because wchar_t is a built-in type in C++, with its own mangling 
- but still a bug.  The choice of underlying type for wchar_t should not 
depend on what the compiler defaults to like that.  (Actually, it looks 
like a 32-bit-default compiler built --enable-targets=all also uses "int" 
here.)

The types of WCHAR_MIN and WCHAR_MAX in both stdint.h and wchar.h need to 
correspond correctly to the underlying type of wchar_t.  GCC's stdint.h 
gets this right automatically, glibc has bits/wchar.h with a special 
sysdeps/unix/sysv/linux/i386 version to use "long".

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

Re: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

[H.J. Lu]

On Wed, May 30, 2012 at 9:25 AM, Joseph S. Myers
 wrote:
> On Wed, 30 May 2012, H.J. Lu wrote:
>
>> On Linux/i386:
>
>> long int
>
>> On Linux/x86-64:
>>
>> [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -
>
>> int
>
> That's a bug.  Not a very serious one - it doesn't affect C++ name
> mangling because wchar_t is a built-in type in C++, with its own mangling
> - but still a bug.  The choice of underlying type for wchar_t should not
> depend on what the compiler defaults to like that.  (Actually, it looks
> like a 32-bit-default compiler built --enable-targets=all also uses "int"
> here.)
>
> The types of WCHAR_MIN and WCHAR_MAX in both stdint.h and wchar.h need to
> correspond correctly to the underlying type of wchar_t.  GCC's stdint.h
> gets this right automatically, glibc has bits/wchar.h with a special
> sysdeps/unix/sysv/linux/i386 version to use "long".
>

How can we fix it without causing problems for existing GCC
nor GLIBC installations?

-- 
H.J.

OPTION_DEFAULT_SPECS question

[Steve Ellcey]

I have a question about OPTION_DEFAULT_SPECS and default flag settings.
During a MIPS GCC build one can configure with --with-synci or
--without-synci (without is the default) and gcc.config sets with_synci
to either "synci" or "no-synci" as appropriate.

In mips.opt is:

msynci
Target Report Mask(SYNCI)
Use synci instruction to invalidate i-cache

And in mips.h we set OPTION_DEFAULT_SPECS to include:

{"synci", "%{!msynci:%{!mno-synci:-m%(VALUE)}}

So my understanding is that if a user on the GCC command line does not
specify -msynci or -mno-synci, GCC will add the flag itself, using one
or the other depending on the default set when configuring.

My question is: When checking the value of TARGET_SYNCI is there anyway
to tell if the flag was set explicitly by the user or implicitly by
the compiler?  The reason I want to know is that if I build GCC for MIPS
today and configure with --with-synci then some tests fail because
the test specifies an old MIPS architecture that doesn't support synci
and the test prints a warning:

  if (TARGET_SYNCI && !ISA_HAS_SYNCI)
{
  warning (0, "the %qs architecture does not support the synci "
   "instruction", mips_arch_info->name);
  target_flags &= ~MASK_SYNCI;
}

Ideally, this warning should only be printed if the user explicitly asked
for -msynci, not if -msynci was merely set as the default.  But I am not sure
how to tell the difference between those two situations.

Steve Ellcey
sell...@mips.com

Re: OPTION_DEFAULT_SPECS question

[David Edelsohn]

On Wed, May 30, 2012 at 1:39 PM, Steve Ellcey  wrote:
>

> My question is: When checking the value of TARGET_SYNCI is there anyway
> to tell if the flag was set explicitly by the user or implicitly by
> the compiler?  The reason I want to know is that if I build GCC for MIPS
> today and configure with --with-synci then some tests fail because
> the test specifies an old MIPS architecture that doesn't support synci
> and the test prints a warning:
>
>  if (TARGET_SYNCI && !ISA_HAS_SYNCI)
>    {
>      warning (0, "the %qs architecture does not support the synci "
>               "instruction", mips_arch_info->name);
>      target_flags &= ~MASK_SYNCI;
>    }
>
> Ideally, this warning should only be printed if the user explicitly asked
> for -msynci, not if -msynci was merely set as the default.  But I am not sure
> how to tell the difference between those two situations.

I think you want to examine target_flags_explicit.

- David

Re: MIPS: 2'nd pass of ira, causes weird register allocation for 2-op mult

[Klaus Pedersen]

Thanks for the pointer,

On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov  wrote:
> Here is an extract from my article from GCC Summit 2004 proceedings.
>
>  It is interesting to note that the pass also implicitly does code
> selection.  Regclass works in two passes.  On the first pass, it
> defines the preferred and alternative classes without taking the
> possible classes of other operands into account.

I had a problem similar to Richard, I simply couldn't figure out what
the second pass tried to do. I ended up single stepping and
printf'fing. I still didn't get much clearer on what was going on.



> For example, an
> instruction with two operand pseudo-registers exists in two variants;
> one accepting classes {\em A} and {\em B}, and other one accepting
> {\em C} and {\em D}.  On the first pass, the algorithm does not see
> that the variant with classes {\em A} and {\em D} will be more costly
> because it will require the generation of additional move
> instructions.  On the second pass, the algorithm will take it into
> account. As a result the preferred or alternative class of a
> pseudo-register could change.  This means two passes are not enough to
> find the preferred and alternative classes accurately; but it is a
> good approximation.

On my MIPS target (1000's of files) I never saw that second pass gives
better code (for practical reasons - smaller size!). I will try to redo
and sumerize these results on a clean 4.7 and with the simple fixes
later today.

If I change the ACC_REGS penalty from 6 to 3 in mips_move_to_gpr_cost()
I get some improvement. MIPS1 need the accumulator for all mult
and div operations, so there are no point in this penalty that makes the
ACC more expensive than FP and memory.

My question is - if the first pass gives you a valid hard register -
shouldn't that be the default if second gives you something bad like
NO_REGS? It is not that you can generate better code if you have been
forced to reload from memory.


>
> I just run SPECInt2000 on x86 (-O2) without and with 2nd pass for today
> trunk.

I would love to redo the test on MIPS, but SPECInt is hardly suitable for
embedded, even if source was available.


> 2nd pass permits to reduce code size 1.36% in average, requires 0.2% more
> compilation time, and
> improves performance by 2.6%.

Re: MIPS: 2'nd pass of ira, causes weird register allocation for 2-op mult

[Vladimir Makarov]

On 05/30/2012 10:27 PM, Klaus Pedersen wrote:

Thanks for the pointer,

On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov  wrote:

Here is an extract from my article from GCC Summit 2004 proceedings.

  It is interesting to note that the pass also implicitly does code
selection.  Regclass works in two passes.  On the first pass, it
defines the preferred and alternative classes without taking the
possible classes of other operands into account.

I had a problem similar to Richard, I simply couldn't figure out what
the second pass tried to do. I ended up single stepping and
printf'fing. I still didn't get much clearer on what was going on.


2nd pass was a part of the old RA for long time for a reason.



For example, an
instruction with two operand pseudo-registers exists in two variants;
one accepting classes {\em A} and {\em B}, and other one accepting
{\em C} and {\em D}.  On the first pass, the algorithm does not see
that the variant with classes {\em A} and {\em D} will be more costly
because it will require the generation of additional move
instructions.  On the second pass, the algorithm will take it into
account. As a result the preferred or alternative class of a
pseudo-register could change.  This means two passes are not enough to
find the preferred and alternative classes accurately; but it is a
good approximation.

On my MIPS target (1000's of files) I never saw that second pass gives
better code (for practical reasons - smaller size!). I will try to redo
and sumerize these results on a clean 4.7 and with the simple fixes
later today.
The effect of 2nd pass may be target depended.  The problem with RA 
being most target dependent code is that one code is trying to work well 
for all targets.

If I change the ACC_REGS penalty from 6 to 3 in mips_move_to_gpr_cost()
I get some improvement. MIPS1 need the accumulator for all mult
and div operations, so there are no point in this penalty that makes the
ACC more expensive than FP and memory.

My question is - if the first pass gives you a valid hard register -
shouldn't that be the default if second gives you something bad like
NO_REGS? It is not that you can generate better code if you have been
forced to reload from memory.

The only problem is how to know that the 2nd pass makes worse choice.  
The 2nd pass should give not a worse choice.  It is not true now for 
MIPS.  We will try to fix it.

I just run SPECInt2000 on x86 (-O2) without and with 2nd pass for today
trunk.

I would love to redo the test on MIPS, but SPECInt is hardly suitable for
embedded, even if source was available.

I guess the run will take forever.  So please, don't bother with this at 
least untill your problem will be fixed.

2nd pass permits to reduce code size 1.36% in average, requires 0.2% more
compilation time, and
improves performance by 2.6%.
There is a simple solution for your problem which I mentioned in my 
email.  Unfortunately, it slows down x86 compiler by 0.5% which I 
believe is big.  So I'll search another solution.


Thanks for reporting this problem and sorry for a long wait.