Re: Pedantic error on address-of main breaks libjava bootstrap

2008-07-30 Thread Andrew Haley
Aaron W. LaFramboise wrote:
> When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
> with:
> 
>> ./sysdep/backtrace.h: In function '_Unwind_Reason_Code
>> fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
>> _Jv_UnwindState*)':
>> ./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of
>> function '::main'
> 
> On mingw32, backtrace.h is a symlink or copy to i386/backtrace.h, which
> is what has this problem:
> 
>>   if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
>>   || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
>>   || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
>> break;
> 
> The code needs the address of main to stop the unwind.  What is the
> proper way to suppress this warning?  __extension__ doesn't seem to help.
> 
> (I'm actually not sure what has changed to cause this warning to start
> happening now.)

Please send the command line that led to this.

Thanks,
Andrew.



Re: frameworklet to assess the quality of debug information

2008-07-30 Thread Richard Guenther
On Tue, Jul 29, 2008 at 9:01 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> On Jul 29, 2008, "Richard Guenther" <[EMAIL PROTECTED]> wrote:
>
>> why not pair the testcase with a gdb script directly?
>
> Mostly a matter of convenience.  Writing code and adding "test this
> here, etc", and not having to adjust a testcase all over just because
> you have to add an #include feels so much better than the alternative.
> And then, having it all in a single file that uses shared
> infrastructure feels better than having to write one script per test,
> but maybe that's just me.

Ok, but maybe there's a trick to embed the gdb script in the source
like you can embed a Makefile in the source ...

Richard.


Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types

2008-07-30 Thread Manuel López-Ibáñez
2008/5/28 Andriy Gapon <[EMAIL PROTECTED]>:
> on 27/05/2008 22:00 Andrew Pinski said the following:
>>
>> On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
>>>
>>> Thank you for the explanation! I didn't realize the difference.
>>>
>>> OTOH, do you think that those arithmetic warnings are practical (as
>>> opposed
>>> to being correct)?
>>
>> I think so as the short int case has a defined overflow of the signed
>> short type that is SHRT_MAX + 1 is defined while INT_MAX + 1 is not.
>
> I still feel like disagreeing.
> Consider this:
> *
> int main()
> {
>short short_x;
>
>short_x = short_x + 1;
>short_x += 1;
>short_x++;
>++short_x;
>
>return 0;
> }
> *
>
> $ gcc43 -Wconversion test-conv2.c -o test-conv
> test-conv2.cc: In function 'int main()':
> test-conv2.cc:5: warning: conversion to 'short int' from 'int' may alter its
> value
> test-conv2.cc:6: warning: conversion to 'short int' from 'int' may alter its
> value
>
> I thought that in C all 4 forms were equivalent and this was purely a style
> choice. Now they are different.
>

Please open a bug report (http://gcc.gnu.org/bugs.html) with this
issue and add [EMAIL PROTECTED] to the CC list. Otherwise this will be
forgotten.

Cheers,

Manuel.


Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types

2008-07-30 Thread Manuel López-Ibáñez
2008/5/27 Andrew Pinski <[EMAIL PROTECTED]>:
> On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote:
>> Thank you for the explanation! I didn't realize the difference.
>>
>> OTOH, do you think that those arithmetic warnings are practical (as opposed
>> to being correct)?
>
> I think so as the short int case has a defined overflow of the signed
> short type that is SHRT_MAX + 1 is defined while INT_MAX + 1 is not.

Andrew, I don't understand what you mean by "SHRT_MAX + 1 is defined
while INT_MAX + 1 is not".

Is there actually any difference in the following cases given   short
short_x = SHRT_MAX ?

   short_x = short_x + 1;
   short_x += 1;
   short_x++;
   ++short_x;

What about unsigned short ushort_x = USHRT_MAX ?

   ushort_x = ushort_x + 1;
   ushort_x += 1;
   ushort_x++;
   ++ushort_x;

Cheers,

Manuel.


Re: failure notice

2008-07-30 Thread G Shyam Sundar
Hi,
   I am working with a kernel module, which was compiled using GCC
4.X, for x86_64 platform.
   After dis-assembling the module object file, I see that the callq
function is always called with the next instruction of the code as the
target address(based on IP only), as the offset feild following the
instruction "e8"(corresponding to callq) is always 0, instead of the
address of the function where I would think the call should be
actually made to.
   What I want to understand is, how function calls work here? Based
on my understanding, the callq instruction should be followed by a
offset address, so that RIP = RIP + Offset. The offset in my case is
always 0. For the following code, the actual address where
qla2xxx_wake_dpc(pha) starts from is 0x1ac68
C Code:
qla2x00_timer{
.
.
test_bit(RELOGIN_NEEDED, &ha->dpc_flags)))
   qla2xxx_wake_dpc(pha);
   qla2x00_restart_timer(ha, WATCH_INTERVAL);
}

Disassembly:
0x0001df91 : test $20,%eax
0x0001df96 : je 0x1dfa0
0x0001df98 : mov %r15,%rdi
0x0001df9b : callq 0x1dfa0
0x0001dfa0 : mov 0(%rip),%rsi
0x0001dfa7 : lea 0x2288(%r12),%rdi
0x0001dfaf : add $0x64,%rsi
0x0001dfb3 : callq 0x1dfb8
0x0001dfb8 : add $0x8,%rsp
0x0001dfbc : pop %rbx
0x0001dfbd : pop %r12
0x0001dfbf : pop %r13
0x0001dfc1 : pop %r14
0x0001dfc3 : pop %r15
0x0001dfc5 : leaveq
0x0001dfc6 : retq

Hexdump starting 0x1df98:
4c 89 ff
e8 00 00 00 00
48 8b 35 00 00 00 00
49 8d bc 24 88 22 00 00
48 83 c6 64
e8 00 00 00 00
I am not sure if this is the right list for this query. Please point
me to the right one if this is not.
Thanks
Shyam


RE: failure notice

2008-07-30 Thread Dave Korn
G Shyam Sundar wrote on 30 July 2008 10:24:

>What I want to understand is, how function calls work here? 

  Google "linking".

> I am not sure if this is the right list for this query. Please point
> me to the right one if this is not.

  This is a binutils question really.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today



Re: failure notice

2008-07-30 Thread Andrew Haley
G Shyam Sundar wrote:
> Hi,
>I am working with a kernel module, which was compiled using GCC
> 4.X, for x86_64 platform.
>After dis-assembling the module object file, I see that the callq
> function is always called with the next instruction of the code as the
> target address(based on IP only), as the offset feild following the
> instruction "e8"(corresponding to callq) is always 0, instead of the
> address of the function where I would think the call should be
> actually made to.

Use "objdump --reloc"

Andrew.



Support for OpenVMS host supports

2008-07-30 Thread Paolo Bonzini
I stumbled in this while looking at how x-* host files are used.  There 
are two files in this configuration that "must be compiled with DEC C".


One is vcrt0.o, which has about 5 lines of executable code.  This makes 
me think that it would be best if someone with access to the OS would 
compile it, so that we can put assembly-language source code for it.


The other is pcrt0.o, which AFAICT had a syntax error since its inception:

 48001 kenner __main (arg1, arg2, arg3, image_file_desc, arg5, arg6)
 48001 kenner  void *arg1, *arg2, *arg3;
 48001 kenner  void *image_file_desc;
 48001 kenner  void *arg5, *arg6)

So, the question is: do we care about this target?  Maybe AdaCore has 
patches to fix it?


Paolo


Re: Support for OpenVMS host supports

2008-07-30 Thread Arnaud Charlet
I'm including Doug Rupp who is our VMS expert and is one of the people
at AdaCore maintaining the VMS port.

> I stumbled in this while looking at how x-* host files are used.  There are 
> two files in this configuration that "must be compiled with DEC C".
> 
> One is vcrt0.o, which has about 5 lines of executable code.  This makes me 
> think that it would be best if someone with access to the OS would compile 
> it, so that we can put assembly-language source code for it.
> 
> The other is pcrt0.o, which AFAICT had a syntax error since its inception:
> 
>  48001 kenner __main (arg1, arg2, arg3, image_file_desc, arg5, arg6)
>  48001 kenner  void *arg1, *arg2, *arg3;
>  48001 kenner  void *image_file_desc;
>  48001 kenner  void *arg5, *arg6)
> 
> So, the question is: do we care about this target?  Maybe AdaCore has 
> patches to fix it?

AdaCore certainly cares about alpha vms and ia64 vms, and we do have lots
of patches for VMS (which are currently based on GCC 4.1, so not ready yet
for direct submission).

Arno


Re: std::isfinite broken?

2008-07-30 Thread Eus
Hi Ho!

--- On Tue, 7/29/08, "Neal Becker" <[EMAIL PROTECTED]> wrote:

> Paolo Carlini wrote:
> 
> > ... ah, ok, now I see what you meant, you meant that x is *not* finite,
> > still, std::isfinite(x) != 0. Still, testcase badly needed...
> >
> > Paolo.
> #include 
> #include 
> 
> int main () {
>   double x = log (0);
>   if (not std::isfinite (x)) {
> throw std::runtime_error ("not finite");
>   }
> }
>
> Compiled with -O3 -ffast-math will not throw.

It worked with me.

Here is the record:

[EMAIL PROTECTED]:~/shared/del/PHP$ cat x.c

#include 
#include 
#include 

int main () {
  double x = log (0);
  if (not std::isfinite (x)) {
std::cout << "Inside if" << std::endl;
  }

  std::cout << "Outside if" << std::endl;
  return 0;
}
[EMAIL PROTECTED]:~/shared/del/PHP$ g++ -o a -O3 -ffast-math x.c
[EMAIL PROTECTED]:~/shared/del/PHP$ ./a
Inside if
Outside if

[EMAIL PROTECTED]:~/shared/del/PHP$ g++ -v
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.3.6/specs
Configured with: ../gcc-3.3.6/configure --prefix=/usr --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld 
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.3.6

Best regards,
Eus


  


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Eus
Hi Ho!

--- On Tue, 7/29/08, "Dennis Clarke" <[EMAIL PROTECTED]> wrote:

> hold on .. on the NEWS page I see ... okay .. how very user friendly.
> Sort of the thing one would put on the project homepage I would think.

Do you mind to tell me what you saw?
I was looking for the interesting part on the latest release of the NEWS on the 
CVS but to no avail.

Thank you for your help.

> Dennis

Best regards,
Eus


  


Re: frameworklet to assess the quality of debug information

2008-07-30 Thread Daniel Jacobowitz
On Mon, Jul 28, 2008 at 06:39:40PM -0300, Alexandre Oliva wrote:
> Here's my first cut at trying to tell how well or how bad we perform
> in terms of debug info, that can be dropped into the GCC run-time test
> infrastructure and used by means of #include in new tests that add
> GUALCHK* annotations (or with separate compilation, if some stuff is
> moved into a separate header).

FWIW, I think this is a good approach.

-- 
Daniel Jacobowitz
CodeSourcery


Re: std::isfinite broken?

2008-07-30 Thread Paolo Carlini

Hi ho, ho!! ;)

It worked with me.
  
Try a recent gcc (eg, 4.3.x) and you will get the same, actually 
expected, result of the original poster.


Paolo.


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Dennis Clarke
On Wed, Jul 30, 2008 at 3:23 PM, Eus <[EMAIL PROTECTED]> wrote:
> Hi Ho!
>
> --- On Tue, 7/29/08, "Dennis Clarke" <[EMAIL PROTECTED]> wrote:
>
>> hold on .. on the NEWS page I see ... okay .. how very user friendly.
>> Sort of the thing one would put on the project homepage I would think.
>
> Do you mind to tell me what you saw?
> I was looking for the interesting part on the latest release of the NEWS on 
> the CVS but to no avail.
>
> Thank you for your help.

It says :

GNU C Library NEWS -- history of user-visible changes.  2008-7-27
Copyright (C) 1992-2007, 2008 Free Software Foundation, Inc.
See the end for copying conditions.

Please send GNU C library bug reports via 
using `glibc' in the "product" field.

Version 2.9

* Unified lookup for getaddrinfo: IPv4 and IPv6 addresses are now looked
  up at the same time.  Implemented by Ulrich Drepper.

* TLS descriptors for LD and GD on x86 and x86-64.
  Implemented by Alexandre Oliva.

* getaddrinfo now handles DCCP and UDPlite.
  Implemented by Ulrich Drepper.

* New fixed-size conversion macros: htobe16, htole16, be16toh, le16toh,
  htobe32, htole32, be32toh, le32toh, htobe64, htole64, be64toh, le64toh.
  Implemented by Ulrich Drepper.

* New implementation of memmem, strstr, and strcasestr which is O(n).
  Implemented by Eric Blake.

* New Linux interfaces: inotify_init1, paccept, dup3, epoll_create2, pipe2

* Implement "e" option for popen to open file descriptor with the
  close-on-exec flag set

* Many functions, exported and internal, now atomically set the close-on-exec
  flag when run on a sufficiently new kernel.  Implemented by Ulrich Drepper.

Version 2.8

* New locales: bo_CN, bo_IN, shs_CA.

* New encoding: HP-ROMAN9, HP-GREEK8, HP-THAI8, HP-TURKISH8.

* Sorting rules for some Indian languages (Devanagari and Gujarati).
  Implemented by Pravin Satpute.

* IPV6 addresses in /etc/resolv.conf can now have a scope ID

* nscd caches now all timeouts for DNS entries
  Implemented by Ulrich Drepper.

* nscd is more efficient and wakes up less often.
  Implemented by Ulrich Drepper.

* More checking functions: asprintf, dprintf, obstack_printf, vasprintf,
  vdprintf, and obstack_vprintf.
  Implemented by Jakub Jelinek.

* Faster memset for x86-64.
  Implemented by Harsha Jagasia and H.J. Lu.

* Faster memcpy on x86.
  Implemented by Ulrich Drepper.

* ARG_MAX is not anymore constant on Linux.  Use sysconf(_SC_ARG_MAX).
  Implemented by Ulrich Drepper.

* Faster sqrt and sqrtf implemention for some PPC variants.
  Implemented by Stephen Munroe.

Version 2.7

* More checking functions: fread, fread_unlocked, open*, mq_open.
  Implemented by Jakub Jelinek and Ulrich Drepper.

* Extend fortification to C++.  Implemented by Jakub Jelinek.

* Implement 'm' modifier for scanf.  Add stricter C99/SUS compliance
  by not recognizing 'a' as a modifier when those specs are requested.
  Implemented by Jakub Jelinek.

* PPC optimizations to math and string functions.
  Implemented by Steven Munroe.

* New interfaces: mkostemp, mkostemp64.  Like mkstemp* but allow additional
  options to be passed.  Implemented by Ulrich Drepper.

* More CPU set manipulation functions.  Implemented by Ulrich Drepper.

* New Linux interfaces: signalfd, eventfd, eventfd_read, and eventfd_write.
  Implemented by Ulrich Drepper.

* Handle private futexes in the NPTL implementation.
  Implemented by Jakub Jelinek and Ulrich Drepper.

* Add support for O_CLOEXEC.  Implement in Hurd.  Use throughout libc.
  Implemented by Roland McGrath and Ulrich Drepper.

* Linux/x86-64 vDSO support.  Implemented by Ulrich Drepper.

* SHA-256 and SHA-512 based password encryption.
  Implemented by Ulrich Drepper.

* New locales: ber_DZ, ber_MA, en_NG, fil_PH, fur_IT, fy_DE, ha_NG, ig_NG,
  ik_CA, iu_CA, li_BE, li_NL, nds_DE, nds_NL, pap_AN, sc_IT, tk_TM, ug_CN,
  yo_NG.

+ New iconv modules: MAC-CENTRALEUROPE, ISO-8859-9E, KOI8-RU.
  Implemented by Ulrich Drepper.

Version 2.6

* New Linux interfaces: epoll_pwait, sched_getcpu.

* New generic interfaces: strerror_l.

* nscd can now cache the services database.   Implemented by Ulrich Drepper.

etc etc etc

Dennis


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Denys Vlasenko
On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Raksit Ashok wrote:
>>There is a more optimized version for 64-bit:
>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
>>I think this looks similar to your implementation, Agner.
>
> Yes it is similar to my code.

3164 line source file which implements memcpy().
You got to be kidding.
How much of L1 icache it blows away in the process?
I bet it performs wonderfully on microbenchmarks though.

   2991 .balign 16   # sadistic alignment strikes 
again
   2992 L(bkPxQx):  .int L(bkP0Q0)-L(bkPxQx) # why use two bytes when
we can use four?

Seriously. What possible reason there can be to align
a randomly accessed data table to 16 bytes?
4 bytes I understand, but 16?
--
vda


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Denys Vlasenko
On Wed, Jul 30, 2008 at 5:57 PM, Denys Vlasenko
<[EMAIL PROTECTED]> wrote:
> On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
>> Raksit Ashok wrote:
>>>There is a more optimized version for 64-bit:
>>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
>>>I think this looks similar to your implementation, Agner.
>>
>> Yes it is similar to my code.
>
> 3164 line source file which implements memcpy().
> You got to be kidding.
> How much of L1 icache it blows away in the process?
> I bet it performs wonderfully on microbenchmarks though.
>
>   2991 .balign 16   # sadistic alignment strikes 
> again
>   2992 L(bkPxQx):  .int L(bkP0Q0)-L(bkPxQx) # why use two bytes when
> we can use four?
>
> Seriously. What possible reason there can be to align
> a randomly accessed data table to 16 bytes?
> 4 bytes I understand, but 16?

I'm afraid I sounded a bit confrontational above, here comes the
clarification. I have nothing against making code faster.
But there should be some balance between -O999 mindset
and -Os midset. If you just found a tweak which gives you 1.2%
speedup in microbencmark but code grew 4 times bigger, *stop*.
Think about it.

"We unrolled the loop two gazillion times and it's 3% faster now"
is a similarly bad idea.

I must admit that I didn't look too closely at
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
but at the first glance it sure looks like someone
got carried away a bit.
--
vda


Re: unsigned comparison warning

2008-07-30 Thread Hariharan

Thanks Ian. I will raise this in gcc-help mailing list.

Cheers
Hari

Ian Lance Taylor wrote:

Hariharan <[EMAIL PROTECTED]> writes:


I found something rather strange with the unsigned comparison warnings
in GCC.


This is the wrong mailing list.  The mailing list gcc@gcc.gnu.org is
for gcc developers.  The mailing list [EMAIL PROTECTED] is for
questions about using gcc.  Please take any followups to
[EMAIL PROTECTED]  Thanks.



and i did gcc -O2 -c trial.c, then i get a warning

trial.c:6: warning: comparison is always true due to limited range of data type

It works the same way if i used an unsigned short. But, if i use
unsigned int/long, i dont get this warning. This is on x86. Is there
an explanation for this? 


You neglected to mention the version of gcc.  In current gcc, I don't
see any warning when using "gcc -O2 -c trial.c".  I see a warning for
both "unsigned char" and "unsigned int" when I add the -Wextra option.

Ian


Re: gcc emit wrong symbols in multiple inheritance case

2008-07-30 Thread Benjamin Smedberg

Ian Lance Taylor wrote:

"Bo Yang" <[EMAIL PROTECTED]> writes:


Could anybody give some advice on this? Thanks!


The mailing list gcc@gcc.gnu.org is for gcc developers, who mostly do
not use cygwin.  Try asking on [EMAIL PROTECTED] and/or
[EMAIL PROTECTED]


For what it's worth, Bo is my intern in the Google SoC and has traced this 
back to being a code-generation error (missed stdcall mangling) in the mingw 
backend. I will work with him to narrow the problem and reformulate the 
question..


--BDS


Re: gcc emit wrong symbols in multiple inheritance case

2008-07-30 Thread Brian Dessent
Benjamin Smedberg wrote:

> For what it's worth, Bo is my intern in the Google SoC and has traced this
> back to being a code-generation error (missed stdcall mangling) in the mingw
> backend. I will work with him to narrow the problem and reformulate the
> question..

Isn't this ?  If so it has regressed as that
was supposedly fixed in 4.3.

Brian


Re: Pedantic error on address-of main breaks libjava bootstrap

2008-07-30 Thread Aaron W. LaFramboise

Andrew Haley wrote:

Aaron W. LaFramboise wrote:

When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:


./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of
function '::main'

On mingw32, backtrace.h is a symlink or copy to i386/backtrace.h, which
is what has this problem:


  if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
  || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
  || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
break;

The code needs the address of main to stop the unwind.  What is the
proper way to suppress this warning?  __extension__ doesn't seem to help.

(I'm actually not sure what has changed to cause this warning to start
happening now.)


Please send the command line that led to this.


Here's the complete command line.

/mingw/src/gccf/./gcc/xgcc -shared-libgcc -B/mingw/src/gccf/./gcc 
-nostdinc++ -L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src 
-L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src/.libs 
-L/mingw/src/gccf/i386-pc-mingw32/winsup/mingw 
-L/mingw/src/gccf/i386-pc-mingw32/winsup/w32api/lib -isystem 
/mingw/src/svn/winsup/mingw/include -isystem 
/mingw/src/svn/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/ 
-B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include 
-isystem /mingw/i386-pc-mingw32/sys-include -DHAVE_CONFIG_H -I. 
-I../../../svn/libjava -I./include -I./gcj -I../../../svn/libjava 
-Iinclude -I../../../svn/libjava/include 
-I../../../svn/libjava/classpath/include -Iclasspath/include 
-I../../../svn/libjava/classpath/native/fdlibm 
-I../../../svn/libjava/../boehm-gc/include -I../boehm-gc/include 
-I../../../svn/libjava/libltdl -I../../../svn/libjava/libltdl 
-I../../../svn/libjava/.././libjava/../gcc 
-I../../../svn/libjava/../zlib -I../../../svn/libjava/../libffi/include 
-I../libffi/include -fno-rtti -fnon-call-exceptions -mthreads 
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 
-ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra 
-Wall -D_GNU_SOURCE -DPREFIX=\"/mingw\" 
-DTOOLEXECLIBDIR=\"/mingw/lib/gcc/i386-pc-mingw32/4.4.0\" 
-DJAVA_HOME=\"/mingw\" 
-DBOOT_CLASS_PATH=\"/mingw/share/java/libgcj-4.4.0.jar\" 
-DJAVA_EXT_DIRS=\"/mingw/share/java/ext\" 
-DGCJ_ENDORSED_DIRS=\"/mingw/share/java/gcj-endorsed\" 
-DGCJ_VERSIONED_LIBDIR=\"/mingw/lib/gcj-4.4.0-10\" 
"-DPATH_SEPARATOR=\";\"" -DECJ_JAR_FILE=\"\" 
-DLIBGCJ_DEFAULT_DATABASE=\"/mingw/lib/gcj-4.4.0-10/classmap.db\" 
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.0-10/classmap.db\" -g -O2 
-MT stacktrace.lo -MD -MP -MF .deps/stacktrace.Tpo -c 
../../../svn/libjava/stacktrace.cc  -DDLL_EXPORT -DPIC -o .libs/stacktrace.o


Sorry, I noticed now that there isn't actually a -pedantic anywhere in 
there.  Removing -Wextra and -Wall have no effect, so this is obviously 
a default error.  Adding -fpermissive turns the error into a warning.


What do you think?


Re: gcc emit wrong symbols in multiple inheritance case

2008-07-30 Thread Benjamin Smedberg

Brian Dessent wrote:

Benjamin Smedberg wrote:


For what it's worth, Bo is my intern in the Google SoC and has traced this
back to being a code-generation error (missed stdcall mangling) in the mingw
backend. I will work with him to narrow the problem and reformulate the
question..


Isn't this ?  If so it has regressed as that
was supposedly fixed in 4.3.


Bo is currently testing with 4.3, so I believe at this point that the 
Mozilla code is tickling a related but not identical bug... but I'm not sure.


--BDS



Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Agner Fog

Denys Vlasenko wrote:

3164 line source file which implements memcpy().
You got to be kidding.
How much of L1 icache it blows away in the process?
I bet it performs wonderfully on microbenchmarks though.

I agree that the OpenSolaris memcpy is bigger than necessary. However, 
it is necessary to have 16 branches for covering all possible alignments 
modulo 16. This is because, unfortunately, there is no XMM shift 
instruction with a variable count, only with a constant count, so we 
need one branch for each value of the shift count. Since only one of the 
branches is used, it doesn't take much space in the code cache. The 
speed is improved by a factor 4-5 by this 16-branch algorithm, so it is 
certainly worth the extra complexity.


The future AMD SSE5 instruction set offers a possibility to join the 
many branches into one, but only on AMD processors. Intel is not going 
to support SSE5, and the future Intel AVX instruction set doesn't have 
an instruction that can be used for this purpose. So we will need 
separate branches for Intel and AMD code in future implementation of 
libc. (Explained in www.agner.org/optimize/asmexamples.zip).



"We unrolled the loop two gazillion times and it's 3% faster now"
is a similarly bad idea.
  
I agree completely. My memcpy code is much smaller than the OpenSolaris 
and Mac implementations and approximately equally fast. Some compilers 
unroll loops way too much in my opinion.


Re: Pedantic error on address-of main breaks libjava bootstrap

2008-07-30 Thread Manuel López-Ibáñez
2008/7/30 Aaron W. LaFramboise <[EMAIL PROTECTED]>:
> Andrew Haley wrote:
>>
>> Aaron W. LaFramboise wrote:
>>>
>>> When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
>>> with:
>>>
 ./sysdep/backtrace.h: In function '_Unwind_Reason_Code
 fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
 _Jv_UnwindState*)':
 ./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of
 function '::main'
>>>
>>> On mingw32, backtrace.h is a symlink or copy to i386/backtrace.h, which
>>> is what has this problem:
>>>
  if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
  || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
  || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
break;
>>>
>>> The code needs the address of main to stop the unwind.  What is the
>>> proper way to suppress this warning?  __extension__ doesn't seem to help.
>>>
[snip]
> Sorry, I noticed now that there isn't actually a -pedantic anywhere in
> there.  Removing -Wextra and -Wall have no effect, so this is obviously a
> default error.  Adding -fpermissive turns the error into a warning.

* You don't need -pedantic to get a pedwarn. -pedantic enables all
pedwarns but some of them are enabled even without -pedantic.

* -fdiagnostics-show-option should tell you what is generating that
diagnostic (but only if it can be disabled). If you are using trunk,
it should show [-fpermissive].

* That is a "permissive error" or permerror for short. These are
errors that can be downgraded to warnings using -fpermissive.

* It would be interesting to know when this started to show up because
as far as I see, it was a default pedwarn before, so nothing should
have changed. What revision of GCC are you using to compile? In which
revision did it work?

* permerrors and default pedwarns are not affected by __extension__.
Nonetheless, is there an __extension__ in that code?

* Is i386/backtrace.h a system header?

Cheers,

Manuel.


Re: Pedantic error on address-of main breaks libjava bootstrap

2008-07-30 Thread Andrew Haley
Manuel López-Ibáñez wrote:
> 2008/7/30 Aaron W. LaFramboise <[EMAIL PROTECTED]>:
>> Andrew Haley wrote:
>>> Aaron W. LaFramboise wrote:
 When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
 with:

> ./sysdep/backtrace.h: In function '_Unwind_Reason_Code
> fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
> _Jv_UnwindState*)':
> ./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of
> function '::main'
 On mingw32, backtrace.h is a symlink or copy to i386/backtrace.h, which
 is what has this problem:

>  if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
>  || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
>  || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
>break;
 The code needs the address of main to stop the unwind.  What is the
 proper way to suppress this warning?  __extension__ doesn't seem to help.

> [snip]
>> Sorry, I noticed now that there isn't actually a -pedantic anywhere in
>> there.  Removing -Wextra and -Wall have no effect, so this is obviously a
>> default error.  Adding -fpermissive turns the error into a warning.
> 
> * You don't need -pedantic to get a pedwarn. -pedantic enables all
> pedwarns but some of them are enabled even without -pedantic.
> 
> * -fdiagnostics-show-option should tell you what is generating that
> diagnostic (but only if it can be disabled). If you are using trunk,
> it should show [-fpermissive].
> 
> * That is a "permissive error" or permerror for short. These are
> errors that can be downgraded to warnings using -fpermissive.

Right, so all we need to do is add -fpermissive to the build options.

> * It would be interesting to know when this started to show up because
> as far as I see, it was a default pedwarn before, so nothing should
> have changed. What revision of GCC are you using to compile? In which
> revision did it work?
> 
> * permerrors and default pedwarns are not affected by __extension__.
> Nonetheless, is there an __extension__ in that code?
> 
> * Is i386/backtrace.h a system header?

No.

Thanks,
Andrew.


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Dennis Clarke
On Wed, Jul 30, 2008 at 5:14 PM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Denys Vlasenko wrote:
>>>
>>> 3164 line source file which implements memcpy().
>>> You got to be kidding.
>>> How much of L1 icache it blows away in the process?
>>> I bet it performs wonderfully on microbenchmarks though.
>>>
>
> I agree that the OpenSolaris memcpy is bigger than necessary. However, it is
> necessary to have 16 branches for covering all possible alignments modulo
> 16. This is because, unfortunately, there is no XMM shift instruction with a
> variable count, only with a constant count, so we need one branch for each
> value of the shift count. Since only one of the branches is used, it doesn't
> take much space in the code cache. The speed is improved by a factor 4-5 by
> this 16-branch algorithm, so it is certainly worth the extra complexity.

You forgot to look at PowerPC :

http://cvs.opensolaris.org/source/xref/ppc-dev/ppc-dev/usr/src/lib/libc/ppc/gen/memcpy.s

is that nice and small ?


Dennis Clarke


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Denys Vlasenko
On Wednesday 30 July 2008 19:14, Agner Fog wrote:
> I agree that the OpenSolaris memcpy is bigger than necessary. However, 
> it is necessary to have 16 branches for covering all possible alignments 
> modulo 16. This is because, unfortunately, there is no XMM shift 
> instruction with a variable count, only with a constant count, so we 
> need one branch for each value of the shift count. Since only one of the 
> branches is used, it doesn't take much space in the code cache. The 
> speed is improved by a factor 4-5 by this 16-branch algorithm, so it is 
> certainly worth the extra complexity.

I tend to doubt that odd-byte aligned large memcpys are anywhere
near typical. malloc and mmap both return well-aligned buffers
(say, 8 byte aligned). Static and on-stack objects are also
at least word-aligned 99% of the time.

memcpy can just use "relatively simple" code for copies in which
either src or dst is not word aligned. This cuts possibilities down
from 16 to 4 (or even 2?).
--
vda


gcc-4.2-20080730 is now available

2008-07-30 Thread gccadmin
Snapshot gcc-4.2-20080730 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080730/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch 
revision 138346

You'll find:

gcc-4.2-20080730.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20080730.tar.bz2 C front end and core compiler

gcc-ada-4.2-20080730.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20080730.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20080730.tar.bz2  C++ front end and runtime

gcc-java-4.2-20080730.tar.bz2 Java front end and runtime

gcc-objc-4.2-20080730.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20080730.tar.bz2The GCC testsuite

Diffs from 4.2-20080723 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Christopher Faylor
On Tue, Jul 29, 2008 at 04:14:49PM +1000, Ben Elliston wrote:
>> Since there is no libc mailing list, I thought that the gcc list is the 
>> place to contact the maintainers of libc. Am I on the wrong list? Or are 
>> there no maintainers of libc?
>
>See:
>  http://sources.redhat.com/glibc/
>
>You want the libc-alpha list, I think.

I think libc-help is a more likely place to start.

cgf


Re: gcc will become the best optimizing x86 compiler

2008-07-30 Thread Agner Fog

Denys Vlasenko wrote:

I tend to doubt that odd-byte aligned large memcpys are anywhere
near typical. malloc and mmap both return well-aligned buffers
(say, 8 byte aligned). Static and on-stack objects are also
at least word-aligned 99% of the time.

memcpy can just use "relatively simple" code for copies in which
either src or dst is not word aligned. This cuts possibilities down
from 16 to 4 (or even 2?).
  
The XMM code is still more than 3 times faster than rep movsl when data 
are aligned by 4 or 8, but not by 16.
Even if odd addresses are rare, they must be supported, but we can put 
the most common cases first.
strcpy and strcat can be implemented efficiently simply by calling 
strlen and memcpy, since both strlen and memcpy can be optimized very 
well. This can give unaligned addresses.


Dennis Clarke wrote:

You forgot to look at PowerPC :

http://cvs.opensolaris.org/source/xref/ppc-dev/ppc-dev/usr/src/lib/libc/ppc/gen/memcpy.s

is that nice and small ?
  

.. and slow. Why doesn't it use Altivec?