Question about gcse.c vs cc0

[Steven Bosscher]

Hello,

In gcse.c:insert_insn_end_basic_block() I found the following code:

#ifdef HAVE_cc0
  /* FIXME: 'twould be nice to call prev_cc0_setter here but it aborts
 if cc0 isn't set.  */
  note = find_reg_note (insn, REG_CC_SETTER, NULL_RTX);
  if (note)
insn = XEXP (note, 0);
  else
{
  rtx maybe_cc0_setter = prev_nonnote_insn (insn);
  if (maybe_cc0_setter
  && INSN_P (maybe_cc0_setter)
  && sets_cc0_p (PATTERN (maybe_cc0_setter)))
insn = maybe_cc0_setter;
}
#endif

How can this work? As far as grep understands, only link_cc0_insns
creates REG_CC_SETTER notes, but that function is only called from
reorg.c (and even then, only if it makes a transformation). So NOTE
will always be NULL.

Are REG_CC_SETTER/REG_CC_USER notes supposed to exist before dbr_sched?

Ciao!
Steven


P.S. The code goes on to use prev_nonnote_insn, which may cross basic
block boundaries, so prev_nonnote_insn_bb should be used instead.

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

[Mailaripillai, Kannan Jeganathan]

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

build results for 4.6.3

[JohnT]

i686-pc-linux-gnu
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /usr/local/gcc-4.6.3/configure --prefix=/usr 
--enable-languages=c,c++,ada,fortran,java,lto,objc

Thread model: posix
gcc version 4.6.3 (GCC)
Mandriva 2010.0
Linux localhost 2.6.31.14-desktop-1mnb #1 SMP Wed Nov 24 11:24:43 EST 2010 
i686 AMD Athlon(tm) XP 1900+ GNU/Linux

glibc-2.10.1-6.7mnb2
512 Mb
binutils 2.21.1
ppl-0.12.1
cloog-ppl-0.15.11

Workaround for building this java with an older java (gcj-4.4.1) already 
installed and a bug in gjar that causes a nullpointer exception: remove 
the old java before building, so the build system uses the just-compiled 
gjar to finish the build.


Submitted by John Tellefson

--
http://www.mozilla.org Firefox browser, Thunderbird email, Seamonkey 
all-in-one, Sunbird calendar and more. Free secure open-source software 
for Windows, Linux, Mac OS and other operating systems

ICE with MEM_REF when Pmode is different from word_mode

[Mohamed Shafi]

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));
}
  base = TREE_OPERAND (base, 0);
}
  else
base = build_fold_addr_expr (base);

the assert check in size_binop fails


  gcc_assert (int_binop_types_match_p (code, TREE_TYPE (arg0),
   TREE_TYPE (arg1)));

This is because the mode of arg0 and arg1 are different, one is Pmode
and other is word_mode.
This is present in m32c target which also has different Pmode and word_mode.
Is this a know failure? I cannot find a bug entry for this issue.
Should i report this?

Regards,
Shafi

Re: ICE with MEM_REF when Pmode is different from word_mode

[Richard Guenther]

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.

>        }
>      base = TREE_OPERAND (base, 0);
>    }
>  else
>    base = build_fold_addr_expr (base);
>
> the assert check in size_binop fails
>
>
>  gcc_assert (int_binop_types_match_p (code, TREE_TYPE (arg0),
>                                       TREE_TYPE (arg1)));
>
> This is because the mode of arg0 and arg1 are different, one is Pmode
> and other is word_mode.
> This is present in m32c target which also has different Pmode and word_mode.
> Is this a know failure? I cannot find a bug entry for this issue.
> Should i report this?
>
> Regards,
> Shafi

Re: [cxx-conversion] gcc-4.7.0 on Cygwin and MinGW32 with --enable-build-with-cxx successes

[Diego Novillo]

On 12-05-25 17:53 , Aaron Gray wrote:


Just to let people know I have succeeded in building gcc-4.7.0 with
--enable-build-with-cxx (All stages built as C++) on latest Cygwin
with GCC 4.5.3 and on MinGW32 with a rebuilt GCC 4.6.2 as the GCC
4.6.2 that came with MinGW was missing stdarg.h and stddef.h and
possibly other headers.


Thanks.  I've updated the list at http://gcc.gnu.org/wiki/CppBuildStatus.


Diego.

internal compiler error using lambda and this

[Andreas Karrenbauer]

To whom it may concern:

Please find a small code example which causes an internal compiler error with 
g++-4.7 (opensuse):

Best regards,

Andreas Karrenbauer


$ cat bug_g++.cc
auto foo = [&](int a) { return a > this->b; };

int main() { return 0; }

$ g++-4.7 -v -Wall -g -std=c++0x bug_g++.cc -o bug_g++
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --
mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-
languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --
with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --
disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --
with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-
slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-
allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs 
--enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-
system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-
linux
Thread model: posix
gcc version 4.7.0 20120507 [gcc-4_7-branch revision 187228] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-g' '-std=c++11' '-o' 'bug_g++' '-shared-
libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib64/gcc/x86_64-suse-linux/4.7/cc1plus -quiet -v -D_GNU_SOURCE 
bug_g++.cc -quiet -dumpbase bug_g++.cc -mtune=generic -march=x86-64 -auxbase 
bug_g++ -g -Wall -std=c++11 -version -o /tmp/cc2EPl2Z.s
GNU C++ (SUSE Linux) version 4.7.0 20120507 [gcc-4_7-branch revision 187228] 
(x86_64-suse-linux)
compiled by GNU C version 4.7.0 20120507 [gcc-4_7-branch revision 
187228], GMP version 5.0.2, MPFR version 3.0.1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.7
 /usr/include/c++/4.7/x86_64-suse-linux
 /usr/include/c++/4.7/backward
 /usr/lib64/gcc/x86_64-suse-linux/4.7/include
 /usr/local/include
 /usr/lib64/gcc/x86_64-suse-linux/4.7/include-fixed
 /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/include
 /usr/include
End of search list.
GNU C++ (SUSE Linux) version 4.7.0 20120507 [gcc-4_7-branch revision 187228] 
(x86_64-suse-linux)
compiled by GNU C version 4.7.0 20120507 [gcc-4_7-branch revision 
187228], GMP version 5.0.2, MPFR version 3.0.1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f72701233f3fe65e145b992d6b2debcd
bug_g++.cc: In lambda function:
bug_g++.cc:1:36: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Re: Bootstrapping trunk error with gcc 4.6.2

[Ian Lance Taylor]

Thomas Koenig  writes:

> I just got a bootstrap error on trunk, with configuration
>
> ../trunk/configure --prefix=$HOME --enable-languages=c,fortran
> --disable-build-poststage1-with-cxx
>
> The error was:
>
> ../../trunk/gcc/fortran/decl.c: In function 'match_attr_spec':
> ../../trunk/gcc/fortran/decl.c:3276:3: error: typedef 'decl_types'
> locally defined but not used [-Werror=unused-local-typedefs]
>decl_types;
>^
> cc1: all warnings being treated as errors
> make[3]: *** [fortran/decl.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: Leaving directory `/home/ig25/Gcc/trunk-bin/gcc'
> make[2]: *** [all-stage2-gcc] Error 2
> make[2]: Leaving directory `/home/ig25/Gcc/trunk-bin'
> make[1]: *** [stage2-bubble] Error 2
> make[1]: Leaving directory `/home/ig25/Gcc/trunk-bin'
> make: *** [all] Error 2
>
>
> Bootstrapping compiler was gcc version 4.6.2 (SUSE Linux)
>
> Any ideas?

The warning seems to be correct: the typedef is locally defined but not
used.  This is presumably from Dodji's 2012-05-04 change to make
-Wunused-local-typedefs part of -Wall.

Ian

[cxx-conversion] Merge from trunk

[Diego Novillo]

This merge brings cxx-conversion up to rev 187927.

Tested on x8_64.

[AVR,Committed]: Re: How to run a compiled C program?

[Georg-Johann Lay]

Ian Lance Taylor wrote:
> Georg-Johann Lay  writes:
> 
>> The avr backend auto-generates a part of the texi documentation by
>> means of a small C program. The relevant part of t-avr reads:
>>
>> s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext)
>>  $(RUN_GEN) $< | sed -e 's:\r::g' > avr-mmcu.texi
>>
>>
>> There was a problem report that the executable cannot be found.
>>
>> When I wrote that I checked other uses of RUN_GEN (which is empty) in
>> $(builddir)/gcc/Makefile that do calls like $(RUN_GEN) build/...
>>
>> What is the correct way to call the executable? Add ./ like so?
>>
>> s-avr-mmcu-texi: gen-avr-mmcu-texi$(build_exeext)
>>  $(RUN_GEN) ./$< | sed -e 's:\r::g' > avr-mmcu.texi
> 
> Yes.
> 
> Ian

Thanks, applied here:

http://gcc.gnu.org/viewcvs?view=revision&revision=187968

Johann

Re: array bounds violation in caller-save.c : duplicate hard regs check added

[Jeff Law]

On 05/25/2012 05:18 PM, DJ Delorie wrote:

If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:

bfin cris m32c rl78 rx sh sh64 v850

The following succeed:

frv h8300 i386 ia64 m32r mep mipsisa32 mipsisa64 mn10300 powerpc tx39

Without this patch, the failing targets eventually overflow the
call_saved_regs[] array (size FIRST_PSEUDO_REGISTER) and corrupt other
memory and data structures.  I originally had an assert for that
bounds check too, but this one caught all the cases sooner.

Can someone who knows more about IRA and this optimization explain if
and/or why duplicate hard regs are allowed at that point, and what if
any changes should be made to avoid the array overflow?
It'd really help if you could probably a testcase so that we could run 
things under a debugger and/or analyze dump files.


jeff

Re: Question about gcse.c vs cc0

[Jeff Law]

On 05/29/2012 03:03 AM, Steven Bosscher wrote:

Hello,

In gcse.c:insert_insn_end_basic_block() I found the following code:

#ifdef HAVE_cc0
   /* FIXME: 'twould be nice to call prev_cc0_setter here but it aborts
  if cc0 isn't set.  */
   note = find_reg_note (insn, REG_CC_SETTER, NULL_RTX);
   if (note)
 insn = XEXP (note, 0);
   else
 {
   rtx maybe_cc0_setter = prev_nonnote_insn (insn);
   if (maybe_cc0_setter
   &&  INSN_P (maybe_cc0_setter)
   &&  sets_cc0_p (PATTERN (maybe_cc0_setter)))
 insn = maybe_cc0_setter;
 }
#endif

How can this work? As far as grep understands, only link_cc0_insns
creates REG_CC_SETTER notes, but that function is only called from
reorg.c (and even then, only if it makes a transformation). So NOTE
will always be NULL.

Are REG_CC_SETTER/REG_CC_USER notes supposed to exist before dbr_sched?
Well, we're talking about code that is 14 years old...  I really don't 
remember.




P.S. The code goes on to use prev_nonnote_insn, which may cross basic
block boundaries, so prev_nonnote_insn_bb should be used instead.

On a cc0 target, this is not true.

jeff

Re: array bounds violation in caller-save.c : duplicate hard regs check added

[DJ Delorie]

> > If I apply this patch, which checks for duplicate hard registers within
> > -fira-share-save-slots, the following *-elf targets fail due to the assert:
> >
> > bfin cris m32c rl78 rx sh sh64 v850
>
> It'd really help if you could probably a testcase so that we could run 
> things under a debugger and/or analyze dump files.

They failed building newlib.  RL78 fails in qsort.c, for example.

Re: array bounds violation in caller-save.c : duplicate hard regs check added

[Jeff Law]

On 05/29/2012 11:11 AM, DJ Delorie wrote:

If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:

bfin cris m32c rl78 rx sh sh64 v850


It'd really help if you could probably a testcase so that we could run
things under a debugger and/or analyze dump files.


They failed building newlib.  RL78 fails in qsort.c, for example.

So, provide the .i file.  That's standard procedure.

jeff

Re: array bounds violation in caller-save.c : duplicate hard regs check added

[DJ Delorie]

dj@greed pts/0 ~/m32c/gcc/rl78-elf/gcc
$ ./cc1 -quiet -O3 qsort.i 
DJERR: DUPLICATE HARD REG 12
../../../../../src/newlib/libc/search/qsort.c: In function 'qsort':
../../../../../src/newlib/libc/search/qsort.c:222:1: internal compiler error: 
in setup_save_areas, at caller-save.c:574
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


# 1 "../../../../../src/newlib/libc/search/qsort.c"
# 1 "/greed/dj/m32c/newlib/rl78-elf/rl78-elf/newlib/libc/search//"
# 1 ""
# 1 "../../../../../src/newlib/libc/search/qsort.c"
# 77 "../../../../../src/newlib/libc/search/qsort.c"
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/_ansi.h" 1 3 4
# 15 "/greed/dj/m32c/newlib/src/newlib/libc/include/_ansi.h" 3 4
# 1 "/greed/dj/m32c/newlib/rl78-elf/rl78-elf/newlib/targ-include/newlib.h" 1 3 4
# 16 "/greed/dj/m32c/newlib/src/newlib/libc/include/_ansi.h" 2 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/config.h" 1 3 4



# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/ieeefp.h" 1 3 4
# 5 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/config.h" 2 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/features.h" 1 3 4
# 6 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/config.h" 2 3 4
# 17 "/greed/dj/m32c/newlib/src/newlib/libc/include/_ansi.h" 2 3 4
# 78 "../../../../../src/newlib/libc/search/qsort.c" 2
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/stdlib.h" 1 3 4
# 10 "/greed/dj/m32c/newlib/src/newlib/libc/include/stdlib.h" 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/ieeefp.h" 1 3 4
# 11 "/greed/dj/m32c/newlib/src/newlib/libc/include/stdlib.h" 2 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/_ansi.h" 1 3 4
# 12 "/greed/dj/m32c/newlib/src/newlib/libc/include/stdlib.h" 2 3 4



# 1 "/greed/dj/m32c/install/lib/gcc/rl78-elf/4.8.0/include/stddef.h" 1 3 4
# 213 "/greed/dj/m32c/install/lib/gcc/rl78-elf/4.8.0/include/stddef.h" 3 4
typedef unsigned int size_t;
# 325 "/greed/dj/m32c/install/lib/gcc/rl78-elf/4.8.0/include/stddef.h" 3 4
typedef long int wchar_t;
# 16 "/greed/dj/m32c/newlib/src/newlib/libc/include/stdlib.h" 2 3 4

# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/reent.h" 1 3 4
# 14 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/reent.h" 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/_types.h" 1 3 4
# 12 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/_types.h" 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_types.h" 1 3 4






# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_default_types.h" 1 
3 4
# 26 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_default_types.h" 3 
4
typedef signed char __int8_t ;
typedef unsigned char __uint8_t ;




typedef signed int __int16_t;
typedef unsigned int __uint16_t;
# 46 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_default_types.h" 3 
4
typedef __int16_t __int_least16_t;
typedef __uint16_t __uint_least16_t;
# 62 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_default_types.h" 3 
4
typedef signed long __int32_t;
typedef unsigned long __uint32_t;
# 76 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_default_types.h" 3 
4
typedef __int32_t __int_least32_t;
typedef __uint32_t __uint_least32_t;
# 99 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_default_types.h" 3 
4
typedef signed long long __int64_t;
typedef unsigned long long __uint64_t;
# 8 "/greed/dj/m32c/newlib/src/newlib/libc/include/machine/_types.h" 2 3 4
# 13 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/_types.h" 2 3 4
# 1 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/lock.h" 1 3 4





typedef int _LOCK_T;
typedef int _LOCK_RECURSIVE_T;
# 14 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/_types.h" 2 3 4


typedef long _off_t;







typedef short __dev_t;




typedef unsigned short __uid_t;


typedef unsigned short __gid_t;



__extension__ typedef long long _off64_t;







typedef long _fpos_t;
# 58 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/_types.h" 3 4
typedef long _ssize_t;




# 1 "/greed/dj/m32c/install/lib/gcc/rl78-elf/4.8.0/include/stddef.h" 1 3 4
# 354 "/greed/dj/m32c/install/lib/gcc/rl78-elf/4.8.0/include/stddef.h" 3 4
typedef unsigned int wint_t;
# 64 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/_types.h" 2 3 4



typedef struct
{
  int __count;
  union
  {
wint_t __wch;
unsigned char __wchb[4];
  } __value;
} _mbstate_t;



typedef _LOCK_RECURSIVE_T _flock_t;




typedef void *_iconv_t;
# 15 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/reent.h" 2 3 4






typedef unsigned long __ULong;
# 37 "/greed/dj/m32c/newlib/src/newlib/libc/include/sys/reent.h" 3 4
struct _reent;






struct _Bigint
{
  struct _Bigint *_next;
  int _k, _maxwds, _sign, _wds;
  __ULong _x[1];
};


struct __tm
{
  int __tm_sec;
  int __tm_min;
  int __tm_hour;
  int __tm_mday;
  int __tm_mon;
  int __tm_year;
  int __tm_wday;
  int __tm_yday;
  int __tm_isdst;
};







str

gcov / lcov producing icorrect results due to white space in source.

[TK Banks]

Good people,

CAVEATS:

Forgive me if this gets double posted.  I sent it last night after
joining this mailing list, but my message did not seem to show up.

I'm also not sure I'm directing this issue to the correct mailing list.
If not, perhaps someone would be so kind as to point me to the right
mailing list or forum.

VERSION INFO:

> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 10.04.4 LTS
Release:10.04
Codename:   lucid

> g++ --version
g++.real (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3


> gcov --version
gcov (Ubuntu 4.4.3-4ubuntu5.1) 4.4.3

> lcov --version
lcov: LCOV version 1.7

THE PROBLEM:

I am a member of a perhaps dying breed that likes opening and closing braces to 
line up vertically.  This is causing lcov & gcov
to incorrectly claim that the line associated with the opening
brace of some constructors to never be hit by my unit tests.  Here
is a sample snip-it of lcov output for one of my constructors:

1135  : template 1136 14 : inline 
Group::Group(Domain& d) 1137  : :   _domain(&d), 1138  :  
   _end(this, &_end, &_end, 0x8000), 1139 14 : _size(0) 
1140 0 : { 1141 14 : }

Notice that line 1140 is said to be executed zero times.  In my
browser, it's highlighted in an obnoxious and most chastising red.

If I reformat my source, moving the open brace to the end of the
previous line, I get these serene results:

1135  : template 1136 14 : inline 
Group::Group(Domain& d) 1137  : :   _domain(&d), 1138  :  
   _end(this, &_end, &_end, 0x8000), 1139 14 : _size(0) { 
1140 14 : }

MY QUESTIONS:

Is this a known bug?

Is the bug most likely with gcc or gcov/lcov?

Has this bug already been fixed in a later release of gcc and/or gcov/lcov?

Is this all part of an insidious and highly orchestrated conspiracy to
force "wrong-headed" folks like myself to put their braces out of alignment?

Thanks,
Matt Busche

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

[Vladimir Makarov]

On 05/29/2012 02:33 AM, Richard Sandiford wrote:

Hi Vlad,

Thanks for the answer.

Vladimir Makarov  writes:

On 05/28/2012 03:09 PM, Richard Sandiford wrote:

Or is it a conceptual part of the algorithm?

No.

More generally,
what kind of situations does the second pass help with?

I can not show such situations right now but I did some benchmarking
long ago on the old RA and the second pass is really important for
better code generation.  That time I even thought about 3rd pass for
-O3.  I don't think the situation is now different.

Cost pass is a complicated part.  It is impossible to find some good
literature which could help.  The problem is in GCC compiler specifics
when code selection is not done (at least fully) before RA and we don't
know until reload end what  alternative will be used.  So some code
selection is done in combiner, some in IRA (including cost pass by
defining allocation classes for pseudos) and final code selection is
done in reload.

Understood.  But I wasn't sure what the second pass was actually trying
to do, or more specifically, how it was expected to give different
results from the first pass.  Most other parts of IRA are well commented
and describe what the code is trying to do (with as you say the usual
caveat that this is always going to be a heuristic, and may not be taken
directly from the literature).  But I couldn't see a similar comment
describing how the second pass worked and what it was trying to do.

I'd be happy to add one myself, but I haven't worked it out yet :-)



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.  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.

I just run SPECInt2000 on x86 (-O2) without and with 2nd pass for today 
trunk.
2nd pass permits to reduce code size 1.36% in average, requires 0.2% 
more compilation time, and

improves performance by 2.6%.

Re: Question about gcse.c vs cc0

[Ian Lance Taylor]

Steven Bosscher  writes:

> In gcse.c:insert_insn_end_basic_block() I found the following code:
>
> #ifdef HAVE_cc0
>   /* FIXME: 'twould be nice to call prev_cc0_setter here but it aborts
>  if cc0 isn't set.  */
>   note = find_reg_note (insn, REG_CC_SETTER, NULL_RTX);
>   if (note)
> insn = XEXP (note, 0);
>   else
> {
>   rtx maybe_cc0_setter = prev_nonnote_insn (insn);
>   if (maybe_cc0_setter
>   && INSN_P (maybe_cc0_setter)
>   && sets_cc0_p (PATTERN (maybe_cc0_setter)))
> insn = maybe_cc0_setter;
> }
> #endif
>
> How can this work? As far as grep understands, only link_cc0_insns
> creates REG_CC_SETTER notes, but that function is only called from
> reorg.c (and even then, only if it makes a transformation). So NOTE
> will always be NULL.
>
> Are REG_CC_SETTER/REG_CC_USER notes supposed to exist before dbr_sched?

Looking at the code, it's fairly clear that it is simply an inlined copy
of prev_cc0_setter which does not require that the insn use cc0.  I
expect that it was never useful to check for a REG_CC_SETTER note, and
the code could be simplified to 

  rtx maybe_cc0_setter = prev_nonnote_insn (insn);
  if (maybe_cc0_setter
  && INSN_P (maybe_cc0_setter)
  && sets_cc0_p (PATTERN (maybe_cc0_setter)))
insn = maybe_cc0_setter;


> P.S. The code goes on to use prev_nonnote_insn, which may cross basic
> block boundaries, so prev_nonnote_insn_bb should be used instead.

As Jeff alluded to, RTL does not permit the CC0 setter and CC0 user to
be in different basic blocks before reorg.  In fact, the whole point of
this code is to keep the CC0 setter and user adjacent.

Ian

Re: gcov / lcov producing icorrect results due to white space in source.

[Ian Lance Taylor]

TK Banks  writes:

> I'm also not sure I'm directing this issue to the correct mailing list.
> If not, perhaps someone would be so kind as to point me to the right
> mailing list or forum.

In fact, gcc@gcc.gnu.org is the wrong mailing list.  The right mailing
list would be gcc-h...@gcc.gnu.org.  Please take any followups there.
Thanks.


> I am a member of a perhaps dying breed that likes opening and closing braces 
> to line up vertically.  This is causing lcov & gcov
> to incorrectly claim that the line associated with the opening
> brace of some constructors to never be hit by my unit tests.  Here
> is a sample snip-it of lcov output for one of my constructors:
>
> 1135  : template 1136 14 : inline 
> Group::Group(Domain& d) 1137  : :   _domain(&d), 1138  :
>  _end(this, &_end, &_end, 0x8000), 1139 14 : _size(0) 
> 1140 0 : { 1141 14 : }
>
> Notice that line 1140 is said to be executed zero times.  In my
> browser, it's highlighted in an obnoxious and most chastising red.

I can't figure out your line breaks there--all the code is on a single
line.  That said, it sounds like this is a small bug somewhere, and I
would guess it is somewhere in GCC.  Please report it following the
instructions at http://gcc.gnu.org/bugs/ .  Thanks.

Ian

Re: gcov / lcov producing icorrect results due to white space in source.

[TK Banks]

Thanks Ian.
Would it be poor-form to submit a bug without first testing on the latest 
version of the compiler?  (I'm just running whatever version Ubuntu doles out 
via the management system:  4.3.4)


Yeah, I noticed that my lines got joined.  It looked good in my yahoo mailer 
text box before I hit send.  Most annoying.  I'm guessing it had something to 
do with the fact that it was cut-n-paste from a web page generated by a 
unix-based web server and into a windows-based web-mailer.  I'll blame it on 
yahoo.


Thanks again,
Matt Busche






- Original Message -
From: Ian Lance Taylor 
To: TK Banks 
Cc: "gcc@gcc.gnu.org" 
Sent: Tuesday, May 29, 2012 4:27 PM
Subject: Re: gcov / lcov producing icorrect results due to white space in 
source.

TK Banks  writes:

> I'm also not sure I'm directing this issue to the correct mailing list.
> If not, perhaps someone would be so kind as to point me to the right
> mailing list or forum.

In fact, gcc@gcc.gnu.org is the wrong mailing list.  The right mailing
list would be gcc-h...@gcc.gnu.org.  Please take any followups there.
Thanks.


> I am a member of a perhaps dying breed that likes opening and closing braces 
> to line up vertically.  This is causing lcov & gcov
> to incorrectly claim that the line associated with the opening
> brace of some constructors to never be hit by my unit tests.  Here
> is a sample snip-it of lcov output for one of my constructors:
>
> 1135  :     template 1136 14 :     inline 
> Group::Group(Domain& d) 1137  :         :   _domain(&d), 1138  :    
>          _end(this, &_end, &_end, 0x8000), 1139 14 :             _size(0) 
> 1140 0 :     { 1141 14 :     }
>
> Notice that line 1140 is said to be executed zero times.  In my
> browser, it's highlighted in an obnoxious and most chastising red.

I can't figure out your line breaks there--all the code is on a single
line.  That said, it sounds like this is a small bug somewhere, and I
would guess it is somewhere in GCC.  Please report it following the
instructions at http://gcc.gnu.org/bugs/ .  Thanks.

Ian

Re: gcov / lcov producing icorrect results due to white space in source.

[Ian Lance Taylor]

TK Banks  writes:

> Would it be poor-form to submit a bug without first testing on the latest 
> version of the compiler?  (I'm just running whatever version Ubuntu doles out 
> via the management system:  4.3.4)

It's OK to do that, just make clear that version of the compiler you
tested.

Ian