Missing features on Changes for GCC 4.3

[Kai Tietz]

Hello,

I missed on the gcc changes page the new target x86_64-pc-mingw32 support 
for cross compilation. Also the new pragma feature for mingw (pragma 
push_macro/pop_macro) is missing, too.
Is this intended to wait for mingw to provide a offical header-set for 
this, or was it simply forgotten ?

Regards,
 i.A. Kai Tietz

--
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger

[cxx0x-branch] Rvalue references vs RVO

[Sylvain Pion]

Hi,

I have done some experiments with the rvalue reference feature on the 
cxx0x-branch.

If I execute the following program:
-
#include 

struct A {
  A () { std::cout << "def ctor" << std::endl; }
  A (const A&) { std::cout << "normal copy" << std::endl; }
  A (A&&)  { std::cout << "rvalue ref copy" << std::endl; }
  ~A (){ std::cout << "dtor" << std::endl; }
};

A f() {  return A(); }

int main() {  A c = f(); }

I get :
-
def ctor
rvalue ref copy
dtor
rvalue ref copy
dtor
dtor
--

Now if I comment out the "rvalue reference constructor", I get the optimal:

def ctor
dtor


I am wondering: is this behavior (2 extra copies) required by the 
rvalue-reference
specifications, or would gcc be allowed to do better?

Even if the whole point of rvalue-reference copies is that they are supposed to 
be
cheap (can we count on them to be fully optimized by the lower level optimizers,
in principle?), it would probably be better to still be allowed to skip the 2 
extra
copies completely using the RVO, even for objects defining an rvalue-ref copy
constructor, right?



BTW, http://gcc.gnu.org/projects/cxx0x.html does not yet mention the rvalue 
reference patch.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project
CGAL, http://cgal.org/

Getting the name of the file to compile

[albino aiello]

Hi all,
i'm writing a new option pass. For more reason, i have to know the name 
of the file .c to compile. For example: if the user writing in the shell 
the following command :

- gcc filename.c
i want to obtain the variable char* that contain the value filename.
I have seen in the file gcc.c that it exist argc and argv variables but 
i have not access to they in the passes.c .

Thanks to all,
Albino

Re: Getting the name of the file to compile

[albino aiello]

Basile STARYNKEVITCH ha scritto:


Maybe you just want the main_input_filename declared in
gcc-trunk/gcc/input.h (near line 80)?
  


Yes,
exactly.
Thank you so much.

Re: New wiki page on testing compile times and memory usage

[Diego Novillo]

Gerald Pfeifer wrote on 05/06/07 18:14:

> Nice, thanks for sharing these.  How about the patch below?

Sure, thanks.

live insns deleted by delete_trivially_dead_insns()

[Rask Ingemann Lambertsen]

I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
failure. From the first subreg dump:

;; Function memcmp (memcmp)

; Splitting reg 73 -> 89 90
; Splitting reg 74 -> 91 92
; Splitting reg 75 -> 93 94
[cut]

(insn 58 151 59 3 memcmp.c:81 (set (reg:HI 91)
(const_int 3 [0x3])) 23 {*movhi} (nil)
(nil))

(insn 59 58 63 3 memcmp.c:81 (set (reg:HI 92 [+2 ])
(const_int 0 [0x0])) 23 {*movhi} (nil)
(nil))

(insn 63 59 152 3 memcmp.c:81 (clobber (reg:HI 93)) -1 (nil)
(insn_list:REG_LIBCALL 62 (nil)))

(insn 152 63 61 3 memcmp.c:81 (clobber (reg:HI 94 [+2 ])) -1 (nil)
(nil))

(insn 61 152 62 3 memcmp.c:81 (parallel [
(set (reg:HI 93)
(and:HI (reg:HI 89)
(reg:HI 91)))
(clobber (reg:CC 13 cc))
]) 120 {*andhi3} (nil)
(nil))

(insn 62 61 64 3 memcmp.c:81 (parallel [
(set (reg:HI 94 [+2 ])
(and:HI (reg:HI 90 [+2 ])
(reg:HI 92 [+2 ])))
(clobber (reg:CC 13 cc))
]) 120 {*andhi3} (nil)
(insn_list:REG_RETVAL 63 (nil)))

(insn 64 62 65 3 memcmp.c:81 (set (reg:HI 76)
(reg:HI 93)) 23 {*movhi} (nil)
(nil))

(insn 65 64 66 3 memcmp.c:81 (parallel [
(set (reg:HI 76)
(ior:HI (reg:HI 76)
(reg:HI 94 [+2 ])))
(clobber (reg:CC 13 cc))
]) 122 {*iorhi3} (nil)
(nil))

(insn 66 65 67 3 memcmp.c:81 (set (reg:CC 13 cc)
(compare:CC (reg:HI 76)
(const_int 0 [0x0]))) 481 {*cmphi_const0_cc} (nil)
(nil))

   CSE comes along, notices that insn 62 just sets reg 94 to zero. Reg 94,
btw, isn't used after insn 65.

;; Function memcmp (memcmp)
[cut]
(insn 58 151 59 3 memcmp.c:81 (set (reg:HI 91)
(const_int 3 [0x3])) 23 {*movhi} (nil)
(nil))

(insn 59 58 63 3 memcmp.c:81 (set (reg:HI 92 [+2 ])
(const_int 0 [0x0])) 23 {*movhi} (nil)
(nil))

(insn 63 59 152 3 memcmp.c:81 (clobber (reg:HI 93)) -1 (nil)
(insn_list:REG_LIBCALL 62 (nil)))

(insn 152 63 61 3 memcmp.c:81 (clobber (reg:HI 94 [+2 ])) -1 (nil)
(nil))

(insn 61 152 62 3 memcmp.c:81 (parallel [
(set (reg:HI 93)
(and:HI (reg:HI 89)
(reg:HI 91)))
(clobber (reg:CC 13 cc))
]) 120 {*andhi3} (nil)
(nil))

(insn 62 61 64 3 memcmp.c:81 (set (reg:HI 94 [+2 ])
(reg:HI 92 [+2 ])) 23 {*movhi} (nil)
(expr_list:REG_EQUAL (const_int 0 [0x0])
(insn_list:REG_RETVAL 63 (nil

(insn 64 62 65 3 memcmp.c:81 (set (reg:HI 76)
(reg:HI 93)) 23 {*movhi} (nil)
(nil))

(insn 65 64 66 3 memcmp.c:81 (set (reg:HI 76)
(reg:HI 93)) 23 {*movhi} (nil)
(nil))

(insn 66 65 67 3 memcmp.c:81 (set (reg:CC 13 cc)
(compare:CC (reg:HI 93)
(const_int 0 [0x0]))) 481 {*cmphi_const0_cc} (nil)
(nil))

   Notice that we now have both a REG_EQUAL and a REG_RETVAL note on insn
62.

   It isn't until the loop2_done dump that the problem shows up.
delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
replacing reg 92 with const_int 0, determines that the while libcall
sequence 63-152-61-62 is dead and can be deleted, without ever checking
insns 63, 152 or 61 for liveness. The result is disaster:

;; Function memcmp (memcmp)
[cut]

Register 91 used 1 times across 0 insns; set 1 time; dies in 0 places.

Register 92 used 1 times across 0 insns; set 1 time; dies in 0 places.

Register 95 used 1 times across 0 insns; set 1 time; dies in 0 places.

Register 96 used 1 times across 0 insns; set 1 time; dies in 0 places.

[cut - why is register 93 not listed?]


(insn 60 56 151 3 memcmp.c:81 (clobber (reg:HI 91)) -1 (nil)
(nil))

(insn 151 60 66 3 memcmp.c:81 (clobber (reg:HI 92 [+2 ])) -1 (nil)
(nil))

(insn 66 151 67 3 memcmp.c:81 (set (reg:CC 13 cc)
(compare:CC (reg:HI 93)
(const_int 0 [0x0]))) 481 {*cmphi_const0_cc} (nil)
(nil))

(jump_insn 67 66 68 3 memcmp.c:81 (set (pc)
(if_then_else (ne (reg:CC 13 cc)
(const_int 0 [0x0]))
(label_ref 93)
(pc))) 561 {*bne_cc} (nil)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))

-- 
Rask Ingemann Lambertsen

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

Hi Aaron,

One issue that might affect many some is that COM doesn't work. 
 has a patch that is 
pending review I guess, but probably won't go into 4.2.


Its not a very big patch, shame it cannot be reviewed in time.

Does this effect XPCOM meaning Mozilla and friends will not compile ?

Aaron

libffi & powerpc

[Patrick Olinet]

Hi there,

I'm running an embedded platform based on a powerpc 405EP CPU and a
gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled
binaries crash at runtime when interpreting java bytecode ("Illegal
instruction" message).

After many investigations, it looks like the problem comes from the
libffi library : I've run the libffi testsuite on my embedded paltform
and many of the tests show the same "Illegal instruction" message. For
instance, the "cls_uint" test crashes at the following line (from the
cls_uint.c file) :

res = (*((cls_ret_uint)pcl))(2147483647);

My knowledge about the powerpc architectures is very limited, but I've
seen mailing lists threads talking about "EABI" that I don't quite
understand but my intuition is that it could be related. For instance,
could it be that my cross toolchain is not compiled with the right
EABI (does this question make sense??) ?

Any ideas or thoughts about this problem ?

Thanks in advance for your replies.

Regards,
Patrick Olinet

Combined tree builds for mingw32

[Daniel Jacobowitz]

Has anyone tried a combined (src+gcc) tree build for i586-mingw32
lately?

So far I've rediscovered that you need to manually specify
--with-newlib; otherwise libstdc++ tries to run link tests.
But I'm still failing to build libstdc++ in various different ways.
The #undef min / #undef max in c++config.h do not work if c++config.h
is included before windows.h, which happens during a build of the PCH;
with that hacked around, I still get:

/space/fsf/mingw/obj/i586-mingw32msvc/libstdc++-v3/include/i586-mingw32msvc/bits/ctype_base.h:59:
error: '_N' was not declared in this scope

Nothing pulls in the definition of _U, _N, etc before that point.

I'm sure it's not as broken as it seems, so I must be missing
something... at one point, ./configure --target=i586-mingw32
--with-newlib was all it took.

-- 
Daniel Jacobowitz
CodeSourcery

One more df-branch benchmarking on SPEC2000

[Vladimir Makarov]

 This is one more df-branch comparison after the last merge branch (done
05/03) with the mainline on the merge point (r124382).

 There is a big progress since last my benchmarking on compilation
speed of SPECFP2000 for PPC64.  But whatever changed this does not
work well for all platforms and benchmarks.  Compilation time for some
platforms even worsened a bit.

 The most degradation in code quality were fixed too and even more the
code on the branch is now better for P4.

 All toolchains were compiled with --enable-checking=release (-O2 was
used to SPEC2000 benchmarks).  Four platforms for benchmarking were
used:

x86_64: 2.6 Ghz Core2.
Itanium: 1.6Ghz Itanium2.
PPC64: 2.5Ghz G5.
Pentium4: 3.2Ghz Pentium4 (additionally -mtune=pentium4 was used).

The attachments contain more verbose info about SPEC2000 results
(there base is df-branch, peak is mainline on the merge point) and can
be used to find what tests still needs attention.

Here is the summary:

Compilation time SPECINT2000 (user time sec):
**Mainline Branch Change

x86_64139.39   148.48   +6.5%
Itanium   446.00   484.56   +8.6%
PPC64 374.33   399.72   +6.8%
Pentium4  253.89   269.43   +4.9%

Compilation time SPECFP2000 (user time sec):
**Mainline Branch Change

x86_64101.99   111.11   +8.9%
Itanium   363.08   407.20  +12.2%   
PPC64 320.69   324.28   +1.1%

Pentium4  183.92   200.15   +8.8%

Code Size SPECINT2000 (text segment)
**Change

x86_64+0.51%
Itanium   -0.14%
PPC64 +0.48%
Pentium4  +0.48%

Code Size SPECFP2000 (text segment)
**Change

x86_64+0.16%
Itanium   -0.20%
PPC64 -0.05%
Pentium4  -0.02%

SPECINT200 Scores:
**Mainline Branch Change

x86_641932 1924   -0.41%
Itanium861  858   -0.35%
PPC64  671  667   -0.59%
Pentium4   878  885   +0.91%

SPECFP200 Scores:
**Mainline Branch Change

x86_641745 1752   +0.40%
Itanium521  517   -0.77%
PPC64  661  660   -0.15%
Pentium4   682  687   +0.73%

 Estimated Estimated
   Base  Base  Base  Peak  Peak  Peak
   BenchmarksRef Time  Run Time   RatioRef Time  Run Time   Ratio
               
   164.gzip  1400  98.7  1419  1400  99.8  1403 
   164.gzip  1400  98.7  1419  1400  99.9  1401 
   164.gzip  1400  98.7  1419* 1400  99.8  1402*
   175.vpr   1400  87.6  1598  1400  87.3  1604 
   175.vpr   1400  87.6  1598* 1400  87.2  1606*
   175.vpr   1400  87.5  1599  1400  87.1  1608 
   176.gcc   1100  62.8  1753  1100  61.2  1797*
   176.gcc   1100  62.7  1754  1100  61.1  1801 
   176.gcc   1100  62.7  1754* 1100  61.2  1796 
   181.mcf   1800 1131587  1800 1131588*
   181.mcf   1800 1141582  1800 1131593 
   181.mcf   1800 1131586* 1800 1141585 
   186.crafty1000  39.1  2560* 1000  39.0  2565 
   186.crafty1000  39.1  2560  1000  39.0  2565 
   186.crafty1000  39.0  2561  1000  39.0  2565*
   197.parser1800 1441252  1800 1441251 
   197.parser1800 1441252  1800 1441252 
   197.parser1800 1441252* 1800 1441251*
   252.eon   1300  52.5  2478  1300  51.5  2523*
   252.eon   1300  52.4  2482  1300  51.6  2520 
   252.eon   1300  52.4  2481* 1300  51.5  2524 
   253.perlbmk   1800  71.8  2506  1800  71.1  2533 
   253.perlbmk   1800  71.9  2504  1800  70.9  2538 
   253.perlbmk   1800  71.9  2505* 1800  71.0  2536*
   254.gap   1100  54.6  2015* 1100  54.3  2025*
   254.gap   1100  54.7  2012  1100  54.2  2028 
   254.gap   1100  54.6  2015  1100  54.3  2025 
   255.vortex1900  85.0  2236* 1900  84.1  2260 
   255.vortex1900  85.0  2237  1900  84.1  2260*
   255.vortex1900  85.0  2235  1900  84.0  2261 
   256.bzip2 1500  81.1  1849  1500  81.5  1840 
   256.bzip2 1500  81.1  1849* 1500  81.6  1838*
   256.bzip2  

Re: Combined tree builds for mingw32

[Paolo Carlini]

Hi,


The #undef min / #undef max in c++config.h do not work if c++config.h
is included before windows.h, which happens during a build of the PCH;
 

I'm not sure to understand. Can you explain in better detail? 
Proviously, we had those undefs in the middle of stl_algobase.h, I don't 
see why that was better. Also, I don't understand what the PCHs have to 
do with windows.h



with that hacked around, I still get:

/space/fsf/mingw/obj/i586-mingw32msvc/libstdc++-v3/include/i586-mingw32msvc/bits/ctype_base.h:59:
error: '_N' was not declared in this scope

Nothing pulls in the definition of _U, _N, etc before that point.
 

Before *which* point? AFAICS, the only place where ctype_base.h is 
included is in bits/locale_facets.h, *after* ...


Paolo.

Re: Combined tree builds for mingw32

[Daniel Jacobowitz]

On Mon, May 07, 2007 at 07:25:25PM +0200, Paolo Carlini wrote:
> Hi,
> 
> > The #undef min / #undef max in c++config.h do not work if c++config.h
> > is included before windows.h, which happens during a build of the PCH;
> >  
> I'm not sure to understand. Can you explain in better detail? Proviously, we 
> had those undefs in the middle of stl_algobase.h, I don't see why that was 
> better. Also, I don't understand what the PCHs have to do with windows.h

The failing command is trying to compile the PCH.  This means that
we're including a large number of libstdc++ headers in a row.  One of
the first ones pulls in c++config.h, which has #undef max; but so far,
nothing has included .  Later, something includes
gthr-default.h; on this platform that pulls in , which
eventually #define's min.  Then later we get , which now sees
the definition.

> > with that hacked around, I still get:
> >
> > /space/fsf/mingw/obj/i586-mingw32msvc/libstdc++-v3/include/i586-mingw32msvc/bits/ctype_base.h:59:
> > error: '_N' was not declared in this scope
> >
> > Nothing pulls in the definition of _U, _N, etc before that point.
> >  
> Before *which* point? AFAICS, the only place where ctype_base.h is included 
> is 
> in bits/locale_facets.h, *after* ...

Hmm, there are three 's in the src repository:

/space/fsf/commit/src/newlib/libc/include/ctype.h
/space/fsf/commit/src/winsup/cygwin/include/ctype.h
/space/fsf/commit/src/winsup/mingw/include/ctype.h

That third one does not define _U.  It uses _UPPER instead.  Does this
mean --with-newlib does not work for mingw32?  (Note, you can't build
without it either.)

-- 
Daniel Jacobowitz
CodeSourcery

Re: Combined tree builds for mingw32

[Paolo Carlini]

Daniel Jacobowitz wrote:


The failing command is trying to compile the PCH.  This means that
we're including a large number of libstdc++ headers in a row.  One of
the first ones pulls in c++config.h, which has #undef max; but so far,
nothing has included .  Later, something includes
gthr-default.h; on this platform that pulls in , which
eventually #define's min.  Then later we get , which now sees
the definition.
 

I see, but I still don't get why this is worse than time ago, when the 
undefs where placed in the middle of stl_algobase.h and nowhere else. Do 
you?



Hmm, there are three 's in the src repository:

/space/fsf/commit/src/newlib/libc/include/ctype.h
/space/fsf/commit/src/winsup/cygwin/include/ctype.h
/space/fsf/commit/src/winsup/mingw/include/ctype.h

That third one does not define _U.  It uses _UPPER instead.  Does this
mean --with-newlib does not work for mingw32?

No idea, absolutely, I don't know the source directory. But, again, I 
don't see, in general, why things are worse than some time ago. In the 
libstdc++-v3 directory nothing changed about ctype_base.h lately, it 
doesn't include anything, and is only included after .


Paolo.

Re: Combined tree builds for mingw32

[Paolo Carlini]

Paolo Carlini wrote:


The failing command is trying to compile the PCH.  This means that
we're including a large number of libstdc++ headers in a row.  One of
the first ones pulls in c++config.h, which has #undef max; but so far,
nothing has included .  Later, something includes
gthr-default.h; on this platform that pulls in , which
eventually #define's min.  Then later we get , which now sees
the definition. 


I see, but I still don't get why this is worse than time ago, when the 
undefs where placed in the middle of stl_algobase.h and nowhere else. 
Do you?


Forgot: in fact, I don't see why the specific scenario above can happen: 
 now includes c++config.h, which (now, not in old releases) 
undefs #min and #max again...


Paolo.

Re: Combined tree builds for mingw32

[Daniel Jacobowitz]

On Mon, May 07, 2007 at 01:37:51PM -0400, Daniel Jacobowitz wrote:
> That third one does not define _U.  It uses _UPPER instead.  Does this
> mean --with-newlib does not work for mingw32?  (Note, you can't build
> without it either.)

That does appear to be the case.  With --with-newlib, we get
config/os/newlib which will not compile with mingw32's ctype.h.
Without it, we get configure-time errors because you can not link
mingw programs until after libstdc++ has been built.  Winsup depends
on libstdc++, and winsup provides crt2.o.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Combined tree builds for mingw32

[Paolo Carlini]

Paolo Carlini wrote:

Forgot: in fact, I don't see why the specific scenario above can 
happen:  now includes c++config.h, which (now, not in old 
releases) undefs #min and #max again...


Never mind, c++config.h has been included before. May previous doubts 
stand however.


Paolo.

Re: Combined tree builds for mingw32

[Brian Dessent]

Daniel Jacobowitz wrote:

> The failing command is trying to compile the PCH.  This means that
> we're including a large number of libstdc++ headers in a row.  One of
> the first ones pulls in c++config.h, which has #undef max; but so far,
> nothing has included .  Later, something includes
> gthr-default.h; on this platform that pulls in , which
> eventually #define's min.  Then later we get , which now sees
> the definition.

Wouldn't the cleanest way to handle this just be to make it a policy
that any header that #includes windows.h must either first #define
NOMINMAX or immediately #undef min and max afterward?  If gthr-default.h
gets it via config/gthr-win32.h then it seems it would be simple to just
do this at the two places where that file includes windows.h.

> Hmm, there are three 's in the src repository:
> 
> /space/fsf/commit/src/newlib/libc/include/ctype.h
> /space/fsf/commit/src/winsup/cygwin/include/ctype.h
> /space/fsf/commit/src/winsup/mingw/include/ctype.h
> 
> That third one does not define _U.  It uses _UPPER instead.  Does this
> mean --with-newlib does not work for mingw32?  (Note, you can't build
> without it either.)

Well MinGW doesn't use any part of newlib so using --with-newlib sounds
like it's technically incorrect.  The right way is probably to add
something that does the equivalent of
--with-headers=$top_srcdir/winsup/mingw/include (and also --with-libs?)
if it detects the $target mingw* and a combined tree.  I think there is
something similar to this already present for using winsup/cygwin in a
combined tree.

Brian

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Ian Lance Taylor]

David Daney <[EMAIL PROTECTED]> writes:

> Kaz Kojima wrote:
> > Hi,
> >
> > I've noticed that some libjava tests fail for SH on trunk and
> > 4.2.0 RC3.
> >
> > New tests that FAIL:
> >
> > Divide_1 -O3 -findirect-dispatch output - bytecode->native test
> > Divide_1 -O3 output - bytecode->native test
> > Divide_1 -O3 output - source compiled test
> > Divide_1 -findirect-dispatch output - bytecode->native test
> > Divide_1 output - bytecode->native test
> > Divide_1 output - source compiled test
> > pr6388 -O3 -findirect-dispatch output - bytecode->native test
> > pr6388 -O3 output - bytecode->native test
> > pr6388 -O3 output - source compiled test
> > pr6388 -findirect-dispatch output - bytecode->native test
> > pr6388 output - bytecode->native test
> > pr6388 output - source compiled test
> >
> > I see same FAILs in the RC3 testresults for x86_64, hppa, ia64,
> > ppc, sparc and s390 at gcc-testresults, though not for i686.
> > Is this a known issue?
> >
> >
> It is now.
> 
> Same thing on mipsel-unknown-linux-gnu:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00265.html
> 
> This is a regression from:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00666.html
> 
> I was hoping that 4.2.0 would be good, but very recently someone broke
> it.  Don't people test for regressions before committing?

This is again my fault.  Very sorry about this.  I ran the gcc
testsuite but I didn't run the libjava testsuite.

This is a bug in C++ code in libjava.  The libjava code assumes that
signed overflow is implementation defined.  The libjava code looks
like this:

  if (num < 0)
{
  isNeg = true;
  num = -(num);
  if (num < 0)
{
  // Must be MIN_VALUE, so handle this special case.
  // FIXME use 'unsigned jint' for num.

Since signed overflow is undefined, VRP can conclude that if (num <
0), - num is > 0.  My patch let VRP notice this.  So the special case
is never handled.

This patch appears to fix the problem.  I'm running the libjava tests
now.  Does this look OK to the java maintainers for 4.2 branch and
mainline?  Mark, should I commit to 4.2 branch?

Ian


2007-05-07  Ian Lance Taylor  <[EMAIL PROTECTED]>

* java/lang/natString.cc (_Jv_FormatInt): Avoid undefined signed
overflow.


Index: natString.cc
===
--- natString.cc(revision 124337)
+++ natString.cc(working copy)
@@ -371,11 +371,11 @@ _Jv_FormatInt (jchar* bufend, jint num)
   if (num < 0)
 {
   isNeg = true;
-  num = -(num);
-  if (num < 0)
+  if (num != (jint) -2147483648U)
+   num = -(num);
+  else
{
- // Must be MIN_VALUE, so handle this special case.
- // FIXME use 'unsigned jint' for num.
+ // Handle special case of MIN_VALUE.
  *--ptr = '8';
  num = 214748364;
}

Re: Combined tree builds for mingw32

[Daniel Jacobowitz]

On Mon, May 07, 2007 at 07:47:01PM +0200, Paolo Carlini wrote:
> Daniel Jacobowitz wrote:
> 
> > The failing command is trying to compile the PCH.  This means that
> > we're including a large number of libstdc++ headers in a row.  One of
> > the first ones pulls in c++config.h, which has #undef max; but so far,
> > nothing has included .  Later, something includes
> > gthr-default.h; on this platform that pulls in , which
> > eventually #define's min.  Then later we get , which now sees
> > the definition.
> >  
> I see, but I still don't get why this is worse than time ago, when the undefs 
> where placed in the middle of stl_algobase.h and nowhere else. Do you?

I am just guessing, but I suspect that something before the middle of
stl_algobase.h caused  to be included.  Here's the ugly
patch I'm using right now to get past this:

@@ -226,6 +226,10 @@ _GLIBCXX_END_NAMESPACE
 #define __N(msgid) (msgid)

 // For example,  is known to #define min and max as
 macros...
+// HACK
+#ifdef __MSVCRT__
+# include 
+#endif
 #undef min
 #undef max

Unfortunately, libstdc++ uses ioctl if FIONREAD is defined, but mingw
defines FIONREAD without defining ioctl (there's "ioctlsocket", but it
doesn't work on files).  Something now causes the definition of
FIONREAD to be visible to basic_file_stdio.cc.  So I needed another
hack there too.

> No idea, absolutely, I don't know the source directory. But, again, I don't 
> see, in general, why things are worse than some time ago. In the libstdc++-v3 
> directory nothing changed about ctype_base.h lately, it doesn't include 
> anything, and is only included after .

That's a good question.  I don't know either; maybe combined tree
builds never worked?

Anyway, I did get it built eventually.  But I'm stumped as to why I 
had to maul the sources to get it to work.  Here's hoping someone else
knows what's going on with this port.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Combined tree builds for mingw32

[Daniel Jacobowitz]

On Mon, May 07, 2007 at 10:55:38AM -0700, Brian Dessent wrote:
> Well MinGW doesn't use any part of newlib so using --with-newlib sounds
> like it's technically incorrect.  The right way is probably to add
> something that does the equivalent of
> --with-headers=$top_srcdir/winsup/mingw/include (and also --with-libs?)
> if it detects the $target mingw* and a combined tree.  I think there is
> something similar to this already present for using winsup/cygwin in a
> combined tree.

Maybe the right thing is to change these lines in crossconfig.m4?

  *-mingw32*)
AC_CHECK_HEADERS([sys/types.h locale.h float.h])
GLIBCXX_CHECK_LINKER_FEATURES
GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT

Those are the "bad" tests.

-- 
Daniel Jacobowitz
CodeSourcery

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Mark Mitchell]

Ian Lance Taylor wrote:

> This patch appears to fix the problem.  I'm running the libjava tests
> now.  Does this look OK to the java maintainers for 4.2 branch and
> mainline?  Mark, should I commit to 4.2 branch?

If this (or a variant) is approved by the Java maintainers, please do
apply the same patch to the 4.2 branch, unless I've warned that I'm
doing a final release build.  (That's not going to happen imminently;
I'm still reviewing the latest lists of nasties.)

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Combined tree builds for mingw32

[Paolo Carlini]

... should have explicitely added that changes to the mingw32 configure 
and mingw-specific config files are of course more than welcome: as soon 
as you are happy with a set of tweaks, just let the v3 people know!


Paolo.

Re: One more df-branch benchmarking on SPEC2000

[Richard Guenther]

On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:

  This is one more df-branch comparison after the last merge branch (done
05/03) with the mainline on the merge point (r124382).

  There is a big progress since last my benchmarking on compilation
speed of SPECFP2000 for PPC64.  But whatever changed this does not
work well for all platforms and benchmarks.  Compilation time for some
platforms even worsened a bit.

  The most degradation in code quality were fixed too and even more the
code on the branch is now better for P4.

  All toolchains were compiled with --enable-checking=release (-O2 was
used to SPEC2000 benchmarks).  Four platforms for benchmarking were
used:

x86_64: 2.6 Ghz Core2.
Itanium: 1.6Ghz Itanium2.
PPC64: 2.5Ghz G5.
Pentium4: 3.2Ghz Pentium4 (additionally -mtune=pentium4 was used).

The attachments contain more verbose info about SPEC2000 results
(there base is df-branch, peak is mainline on the merge point) and can
be used to find what tests still needs attention.

Here is the summary:

Compilation time SPECINT2000 (user time sec):
**Mainline Branch Change

x86_64139.39   148.48   +6.5%
Itanium   446.00   484.56   +8.6%
PPC64 374.33   399.72   +6.8%
Pentium4  253.89   269.43   +4.9%


Note that while I appreciate the benchmarking very much, not
providing details on which SPEC tests regress in compile time is bad.
Can you manually identify the worst offender, ideally by file?  Or is it
just overall regressing?

Thanks,
Richard.

tuples: call for help

[Aldy Hernandez]

Hi Dan.  Hi folks.

People (ok, so it was Dan) had asked if there was anything they could do to
help the tuples effort.  

The pretty print routines could definitely use a lot of cases
(dump_gimple_stmt), and the work is very self contained.

There is also the constructors and accessors for the IR.  Currently there
are there are only routines for GS_ASSIGN and GS_RETURN.

Just in case anyone was bored.
Aldy

Re: One more df-branch benchmarking on SPEC2000

[Vladimir Makarov]

Richard Guenther wrote:


On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:



Compilation time SPECINT2000 (user time sec):
**Mainline Branch Change

x86_64139.39   148.48   +6.5%
Itanium   446.00   484.56   +8.6%
PPC64 374.33   399.72   +6.8%
Pentium4  253.89   269.43   +4.9%



Note that while I appreciate the benchmarking very much, not
providing details on which SPEC tests regress in compile time is bad.
Can you manually identify the worst offender, ideally by file?  Or is it
just overall regressing?

I can guess it is mostly overall regression.  Of course there is always 
worst offender.  I could find it but it will take some time which 
unfortunately I don't have next 2 weeks.  Sorry for that.  Even such 
benchmarking takes a lot of time.


I do such bechmarking because I am worried more about missed code 
regressions for now (I think that easy significant compile time 
improvement is not possible anymore).  After the merging such code 
quality comparison will be impossible and it will be hard to say what 
is missed because of the new df code.  And I see that people (mostly 
Seongbae) doing a good job  fixing code regressions.  I really 
appreciate that because I know how hard to fix them for SPEC2000.

Re: live insns deleted by delete_trivially_dead_insns()

[Eric Botcazou]

>It isn't until the loop2_done dump that the problem shows up.
> delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
> 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
> replacing reg 92 with const_int 0, determines that the while libcall
> sequence 63-152-61-62 is dead and can be deleted, without ever checking
> insns 63, 152 or 61 for liveness.

Because it's the semantics of libcall sequences.  My take is that the lower 
subreg pass breaks it in this case.

-- 
Eric Botcazou

Re: One more df-branch benchmarking on SPEC2000

[Steven Bosscher]

On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:

Richard Guenther wrote:

> On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
>>
>> Compilation time SPECINT2000 (user time sec):
>> **Mainline Branch Change
>> 
>> x86_64139.39   148.48   +6.5%
>> Itanium   446.00   484.56   +8.6%



From what I can tell, a significant amount of extra compile time on

Itanium is spent in the scheduler. I've compared the number of
schedulable insns on the trunk and on the df branch, and it appears we
give the scheduler more freedom on the branch. This inevitably takes
time (the scheduler is the slowest part of GCC-on-Itanium already,
anyway).



>> PPC64 374.33   399.72   +6.8%
>> Pentium4  253.89   269.43   +4.9%
>
>
> Note that while I appreciate the benchmarking very much, not
> providing details on which SPEC tests regress in compile time is bad.
> Can you manually identify the worst offender, ideally by file?  Or is it
> just overall regressing?
>
I can guess it is mostly overall regression.


It is.  There are a few known common bottlenecks that still need fixing.

Gr.
Steven

Re: live insns deleted by delete_trivially_dead_insns()

[Paolo Bonzini]

Eric Botcazou wrote:

   It isn't until the loop2_done dump that the problem shows up.
delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
replacing reg 92 with const_int 0, determines that the while libcall
sequence 63-152-61-62 is dead and can be deleted, without ever checking
insns 63, 152 or 61 for liveness.


Because it's the semantics of libcall sequences.  My take is that the lower 
subreg pass breaks it in this case.


Can you also check -fno-forward-propagate?

Paolo

Re: live insns deleted by delete_trivially_dead_insns()

[Rask Ingemann Lambertsen]

On Mon, May 07, 2007 at 10:12:21PM +0200, Paolo Bonzini wrote:
> Eric Botcazou wrote:
> >>   It isn't until the loop2_done dump that the problem shows up.
> >>delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
> >>62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
> >>replacing reg 92 with const_int 0, determines that the while libcall
> >>sequence 63-152-61-62 is dead and can be deleted, without ever checking
> >>insns 63, 152 or 61 for liveness.
> >
> >Because it's the semantics of libcall sequences.  My take is that the 
> >lower subreg pass breaks it in this case.

   I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with
-fno-move-loop-invariants or -fno-split-wide-types.

> Can you also check -fno-forward-propagate?

   Yes. It'll have to wait until Wednesday, though.

   To be able to continue testing, I worked around it like this:

Index: gcc/cse.c
===
--- gcc/cse.c   (revision 124334)
+++ gcc/cse.c   (working copy)
@@ -4983,8 +4983,11 @@ cse_insn (rtx insn, rtx libcall_insn)
&& GET_CODE (XEXP (XEXP (src_const, 0), 0)) == LABEL_REF
&& GET_CODE (XEXP (XEXP (src_const, 0), 1)) == LABEL_REF))
{
- /* We only want a REG_EQUAL note if src_const != src.  */
- if (! rtx_equal_p (src, src_const))
+ /* We only want a REG_EQUAL note if src_const != src.  Don't add one
+if the insn has a REG_RETVAL note since this will confuse
+delete_trivially_dead_insns() (see dead_libcall_p()).  */
+ if (!rtx_equal_p (src, src_const)
+ && !find_reg_note (insn, REG_RETVAL, NULL))
{
  /* Make sure that the rtx is not shared.  */
  src_const = copy_rtx (src_const);

-- 
Rask Ingemann Lambertsen

RE: Combined tree builds for mingw32

[Danny Smith]

> > 
> > > The failing command is trying to compile the PCH.  This means that
> > > we're including a large number of libstdc++ headers in a 
> row.  One of
> > > the first ones pulls in c++config.h, which has #undef 
> max; but so far,
> > > nothing has included .  Later, something includes
> > > gthr-default.h; on this platform that pulls in , which
> > > eventually #define's min.  Then later we get , 
> which now sees
> > > the definition.
> > >  
> > I see, but I still don't get why this is worse than time 
> ago, when the undefs 
> > where placed in the middle of stl_algobase.h and nowhere 
> else. Do you?
> 
> I am just guessing, but I suspect that something before the middle of
> stl_algobase.h caused  to be included.  Here's the ugly
> patch I'm using right now to get past this:
> 

You've probably discovered this already, but...

 should not be included by default in libstdc++ on mingw
target.
That is taken care of by config/os/mingw32/os_defines.h.  
min/max macros also are taken care of there, but I see the comment is
out-of-date.

Most people I know who build mingw-targeted  gcc/binutils natively or
cross, preinstall the
mingw runtime headers and libraries in $(prefix).  Unlike other systems,
mingw32 does not have 
a standard location for headers or libraries, but uses the
make_relative_prefix dance to find the local dirs.

Danny

Re: live insns deleted by delete_trivially_dead_insns()

[Rask Ingemann Lambertsen]

On Mon, May 07, 2007 at 09:35:38PM +0200, Eric Botcazou wrote:
> >It isn't until the loop2_done dump that the problem shows up.
> > delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn
> > 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully
> > replacing reg 92 with const_int 0, determines that the while libcall
> > sequence 63-152-61-62 is dead and can be deleted, without ever checking
> > insns 63, 152 or 61 for liveness.
> 
> Because it's the semantics of libcall sequences.  My take is that the lower 
> subreg pass breaks it in this case.


Here's what it looks like in the jump dump, right before the lower subreg
pass:

(insn 60 56 58 3 memcmp.c:81 (clobber (reg:SI 74)) -1 (nil)
(nil))

(insn 58 60 59 3 memcmp.c:81 (set (subreg:HI (reg:SI 74) 0)
(const_int 3 [0x3])) 23 {*movhi} (nil)
(nil))

(insn 59 58 63 3 memcmp.c:81 (set (subreg:HI (reg:SI 74) 2)
(const_int 0 [0x0])) 23 {*movhi} (nil)
(nil))

(insn 63 59 61 3 memcmp.c:81 (clobber (reg:SI 75)) -1 (nil)
(insn_list:REG_LIBCALL 62 (nil)))

(insn 61 63 62 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 75) 0)
(and:HI (subreg:HI (reg:SI 73) 0)
(subreg:HI (reg:SI 74) 0)))
(clobber (reg:CC 13 cc))
]) 120 {*andhi3} (nil)
(expr_list:REG_NO_CONFLICT (reg:SI 73)
(expr_list:REG_NO_CONFLICT (reg:SI 74)
(nil

(insn 62 61 64 3 memcmp.c:81 (parallel [
(set (subreg:HI (reg:SI 75) 2)
(and:HI (subreg:HI (reg:SI 73) 2)
(subreg:HI (reg:SI 74) 2)))
(clobber (reg:CC 13 cc))
]) 120 {*andhi3} (nil)
(insn_list:REG_RETVAL 63 (expr_list:REG_NO_CONFLICT (reg:SI 73)
(expr_list:REG_NO_CONFLICT (reg:SI 74)
(nil)

(insn 64 62 65 3 memcmp.c:81 (set (reg:HI 76)
(subreg:HI (reg:SI 75) 0)) 23 {*movhi} (nil)
(nil))

(insn 65 64 66 3 memcmp.c:81 (parallel [
(set (reg:HI 76)
(ior:HI (reg:HI 76)
(subreg:HI (reg:SI 75) 2)))
(clobber (reg:CC 13 cc))
]) 122 {*iorhi3} (nil)
(nil))

(insn 66 65 67 3 memcmp.c:81 (set (reg:CC 13 cc)
(compare:CC (reg:HI 76)
(const_int 0 [0x0]))) 481 {*cmphi_const0_cc} (nil)
(nil))

(jump_insn 67 66 68 3 memcmp.c:81 (set (pc)
(if_then_else (ne (reg:CC 13 cc)
(const_int 0 [0x0]))
(label_ref 93)
(pc))) 561 {*bne_cc} (nil)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))

-- 
Rask Ingemann Lambertsen

Re: Combined tree builds for mingw32

['Daniel Jacobowitz']

On Tue, May 08, 2007 at 09:11:45AM +1200, Danny Smith wrote:
> You've probably discovered this already, but...
> 
>  should not be included by default in libstdc++ on mingw
> target.
> That is taken care of by config/os/mingw32/os_defines.h.  
> min/max macros also are taken care of there, but I see the comment is
> out-of-date.

I hadn't.  Thanks a lot.  Now I see how it's all supposed to work.

It turns out that the problem I found for building in a combined tree
is legitimate, but all the others were garbage from my broken build
process and a series of really silly typos (like
--with-libs=/usr/i586-mingw32msvc/include <--).  So I think
crossconfig.m4 should be fixed for mingw32 to support combined tree
builds, but it's not as big a problem as I thought it was.

I'll take a stab at fixing crossconfig.m4 if I can find a chance.

-- 
Daniel Jacobowitz
CodeSourcery

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Tom Tromey]

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:

Ian> This is a bug in C++ code in libjava.

Thanks.  We enabled -fwrapv for the interpreter but, I think, thought
that perhaps the other C++ code was safe.
Would the new warning have caught this?

Ian> This patch appears to fix the problem.  I'm running the libjava tests
Ian> now.  Does this look OK to the java maintainers for 4.2 branch and
Ian> mainline?  Mark, should I commit to 4.2 branch?

Yes, this is fine.  Thanks.

Tom

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Ian Lance Taylor]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote:
> 
> > This patch appears to fix the problem.  I'm running the libjava tests
> > now.  Does this look OK to the java maintainers for 4.2 branch and
> > mainline?  Mark, should I commit to 4.2 branch?
> 
> If this (or a variant) is approved by the Java maintainers, please do
> apply the same patch to the 4.2 branch, unless I've warned that I'm
> doing a final release build.  (That's not going to happen imminently;
> I'm still reviewing the latest lists of nasties.)

Patch committed to mainline and 4.2 branch on the grounds that 1) it
is obvious; 2) in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31842#c3
Andrew Haley saw the patch and didn't choke.

Ian

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Ian Lance Taylor]

Tom Tromey <[EMAIL PROTECTED]> writes:

> > "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> 
> Ian> This is a bug in C++ code in libjava.
> 
> Thanks.  We enabled -fwrapv for the interpreter but, I think, thought
> that perhaps the other C++ code was safe.
> Would the new warning have caught this?

Yes.  With -Wstrict-overflow:

../../../trunk/libjava/java/lang/natString.cc: In function ‘jint 
_Jv_FormatInt(jchar*, jint)’:
../../../trunk/libjava/java/lang/natString.cc:375: warning: assuming signed 
overflow does not occur when simplifying conditional to constant


It also warns about this sort of code which occurs a few times in that
file:

  if (offset < 0 || count < 0 || offset + count < 0
  || offset + count > data_size)

Since if offset < 0 and count < 0, then VRP can assume that offset +
count < 0 is always true.  If you want to code to correctly check for
signed overflow of offset + count, you will need to instead write
something along the lines of INT_MAX - offset <= count.

Ian

MinGW, GCC Vista,

[craig]

Hi,

Do you guys know if the problem with the access() standard library function has
been worked around?
Windows vista has an updated MSVCRT.DLL which returns false for access() using 
X_OK, this parameter was previously ignored, and returned true. MinGW / GCC
does not work on Vista as a result.

Regards
Craig



This message was sent using IMP, the Internet Messaging Program.

Re: live insns deleted by delete_trivially_dead_insns()

[Paolo Bonzini]

Because it's the semantics of libcall sequences.  My take is that the 
lower subreg pass breaks it in this case.


   I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with
-fno-move-loop-invariants or -fno-split-wide-types.


Can you also check -fno-forward-propagate?


   Yes. It'll have to wait until Wednesday, though.


Ok.

Still, last time everybody spoke about removing libcall notes, the last 
reason to keep them was elimination of redundant computation for TLS.


This patch should have made it redundant:

http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01695.html

Paolo