Re: GCC 4.2.1 Status Report (2007-07-10)

2007-07-11 Thread Richard Guenther

On 7/11/07, Daniel Berlin [EMAIL PROTECTED] wrote:

On 7/11/07, Mark Mitchell [EMAIL PROTECTED] wrote:

 Summary
 ---

 The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.

 As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all
 changes.  If you have outstanding changes that have been approved, but
 not committed, make the commits before that time.  I plan to build GCC
 4.2.1 RC2 tomorrow evening.

 I will probably wait until a few days after the 13th to build the
 final release, in order to make sure that people have had a chance to
 test out RC2.

 We still have 3 wrong-code P1s:

 PR 32182 -fstrict-aliasing ...

This is not analyzed enough to know whether it's something i should
look at, or the C++ FE people should look at.  IE Nobody has pointed
out what is actually going wrong here, so i don't know whether it's
aliasing or what :)


Also this looks related to PR 32716.

Richard.


Re: AMD64 ABI compatibility

2007-07-11 Thread Kai Tietz
Jan Hubicka wrote on 11.07.2007 02:02:13:

   
   I am on that tricky thing ;) I think I need in i386.c an global 
variable 
   ix86_amd64_abi which helds the the current function abi. This 
 means also 
   that I have to use instead of TARGET_64BIT_MS_ABI this variable.This 
var 
   may initioalized by init_cumulative_args and the overriden 
   REG_PARM_STACK_SPACE, OUTGOING_REG_PARM_STACK_SPACE, REGPARM_MAX, 
   SSE_REGPARM_MAX, STACK_BOUNDARY, etc.
  
  In order to get all cases right (ie switching ABIs and calling foreign
  function), you need more bookkeeping than this.  I am just in hurry to
  catch bus, but I will send you little guide tonight.
 
 Hi,
 so short overview. It seems to me that you have several cases:
 
  - to keep track of current function ABI, you need to add struct
machine_function field (i386.g) and update TARGET_64BIT_MS_ABI that
cares about current function ABI accordingly.
 
To deal correclty with call_used registers, I think you need to set
the bits at same time machine_function is initialized and add a
function to regalloc that will update the internal representaiton via
regset (grep for use of the macro).
 
For example prologue/epologue code cares about this current ABI.
 
  - to keep track of ABI used by currently expanded function call
CUMULATIVE_ARGS allows you to add extra info.  See how cum-nregs
is handled, you need to do pretty much the same and add cum argument
to functions called form cumulative arguments machinery where youneed 
them.
(as opposed to flipping the current abi above as you suggested).
 
There is one problem that RTL CALL instructions does not specify call
used registers that differ in between ABI.  They are all assumed to
use ones specified by call_used.
 
I think you can't do anything to declare SI/DI unused when calling
function from SYSV ABI with MS ABI convention.  We just lose code
quality a bit.
 
On the other hand you must specify them as clobbered when calling
SYSV ABI from MS ABI.  This needs to be done by adding extra variants
of call instruction pattern with the clobber. You might want to
impleement SYSV-MS direction only first and not worry about this for
start.
 
Note that when calling libcalls, you always want to use the efault
conventions so the libgcc match.
 
  - You need to keep track of cases function from one ABI calls functions
from different ABI.  This can be done by adding yet another bit into 
machine_function and simply set it when expanding the foreign call.
 
Some predicates (such as ix86_function_value_regno_p) cares about
if the reg can possibly be return value.  In the case both ABIs
coexist in single function, you need to be conservative here and
merge both possibilities.
 
  - You will need to update the calling convention of some of the
predicates you mentioned (such as I think 
OUTGOING_REG_PARM_STACK_SPACE)
to specify the function declaration they care about (so you know if
it is foreign call or not).  GCC middleend is probably not quite
ready to deal with so different ABIs intermixed at once.  This
include updating of calling conventions in all ports and should be
done first by separate patches. Not dificult, but tedious.
 
 I guess thats it.  I believe that if you don't do something of the
 above, some of cases will go wildly wrong... (this is not to discougrate
 you, just to explain why it is tricky :)
 
 Honza

I thank you very much for your great help. Currently I am stucked on 
x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear 
what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the 
ms_abi variant for sysv_abi as default too. But I think, it breaks 87 fpu 
stuff for this ABI !?!


Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.

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




Re: AMD64 ABI compatibility

2007-07-11 Thread Jan Hubicka
 
 I thank you very much for your great help. Currently I am stucked on 
 x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not clear 
 what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the 
 ms_abi variant for sysv_abi as default too. But I think, it breaks 87 fpu 
 stuff for this ABI !?!

x86_function_value_regno_p is tricky one.  Speaking strictly from
definition I think it should
 - for current SYSV ABI with no MS ABI function calls return set it
   returns for MS ABI (not including x87)
 - for current SYSV ABI or MS ABI with SYSV ABI function calls return set it
   returns for SYSV ABI (including x87)

However see the use in builtins.c - it expects that this function is
invariant for whole compilation unit, so implementing the above would
need updating builtins.c too.

The feature is used just seldomly - for the extra builtin expansion,
in combine.c for logic that won't fire for x87, in mode switching to
support the builtin_apply above and in rtlanal.c to avoid separating
the return value from call. With x87 register we should not be spoiled
here either, since x87 is quite symetric before regstack and restack will know
how to fix this up.

My best bet would be that making the function dependent on default ABI
is good enough.  You might add some comment that the function should
depend on current function ABI but builtins.c would need updating then.

Honza
 
 
 Cheers,
  i.A. Kai Tietz
 
 |  (\_/)  This is Bunny. Copy and paste Bunny
 | (='.'=) into your signature to help him gain
 | ()_() world domination.
 
 --
   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
 
 


Re: ICE building libgcc2.c for MIPS, too

2007-07-11 Thread Sandra Loosemore

Ian Lance Taylor wrote:

Sandra Loosemore [EMAIL PROTECTED] writes:


The error reported here

http://gcc.gnu.org/ml/gcc/2007-07/msg00339.html

is also happening when building for target mipsisa32r2-elfoabi on 
i686-pc-linux-gnu.


This should be fixed by revision 126536.  Sorry for the problems.


I'm now at revision 126547, and am getting a different ICE when building the 
same configuration:


libtool: compile: 
/scratch/sandra/mips32-mainline/obj/gcc-mainline-0-mipsisa32r2-elfoabi-i686-pc-linux-gnu/./gcc/xgcc 
-shared-libgcc 
-B/scratch/sandra/mips32-mainline/obj/gcc-mainline-0-mipsisa32r2-elfoabi-i686-pc-linux-gnu/./gcc 
-nostdinc++ 
-L/scratch/sandra/mips32-mainline/obj/gcc-mainline-0-mipsisa32r2-elfoabi-i686-pc-linux-gnu/mipsisa32r2-elfoabi/libstdc++-v3/src 
-L/scratch/sandra/mips32-mainline/obj/gcc-mainline-0-mipsisa32r2-elfoabi-i686-pc-linux-gnu/mipsisa32r2-elfoabi/libstdc++-v3/src/.libs 
-B/scratch/sandra/mips32-mainline/install/mipsisa32r2-elfoabi/bin/ 
-B/scratch/sandra/mips32-mainline/install/mipsisa32r2-elfoabi/lib/ -isystem 
/scratch/sandra/mips32-mainline/install/mipsisa32r2-elfoabi/include -isystem 
/scratch/sandra/mips32-mainline/install/mipsisa32r2-elfoabi/sys-include 
-I/scratch/sandra/mips32-mainline/obj/gcc-mainline-0-mipsisa32r2-elfoabi-i686-pc-linux-gnu/mipsisa32r2-elfoabi/libstdc++-v3/include/mipsisa32r2-elfoabi 
-I/scratch/sandra/mips32-mainline/obj/gcc-mainline-0-mipsisa32r2-elfoabi-i686-pc-linux-gnu/mipsisa32r2-elfoabi/libstdc++-v3/include 
-I/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/libsupc++ 
--sysroot=/scratch/sandra/mips32-mainline/install/mipsisa32r2-elfoabi 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual 
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 
--sysroot=/scratch/sandra/mips32-mainline/install/mipsisa32r2-elfoabi -c 
/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale_init.cc 
-o locale_init.o
/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc: In 
member function 'std::string std::locale::name() const':
/scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:143: 
internal compiler error: Aborted


-Sandra



Re: ODR violation for std::cout etc.

2007-07-11 Thread Gabriel Dos Reis
Paolo Carlini [EMAIL PROTECTED] writes:

| Michael Veksler wrote:
| 
|  What do you think?
| 
| I think that the current solution is very, very old, and heaven
| knows how many others didn't work at the time on some exotic
| platforms. I would suggest filing a PR and CCing Benjamin.

The current situation was the best compromise we arrived at in the
very old days of GCC-3.x.x -- see the archive for discussions.

I'd suspect that nowadays we have better ways of handling the
issues -- though I've not done any new investigation.

-- Gaby


Re: ICE building libgcc2.c for MIPS, too

2007-07-11 Thread Ian Lance Taylor
Sandra Loosemore [EMAIL PROTECTED] writes:

 I'm now at revision 126547, and am getting a different ICE when
 building the same configuration:

 /scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:
 In member function 'std::string std::locale::name() const':
 /scratch/sandra/mips32-mainline/src/gcc-mainline/libstdc++-v3/src/locale.cc:143:
 internal compiler error: Aborted

This is most likely unrelated.  If you would like to me to look at it,
please send me the .ii file.  Thanks.

Ian


Re: AMD64 ABI compatibility

2007-07-11 Thread Kai Tietz
Jan Hubicka wrote on 11.07.2007 14:01:54:

  
  I thank you very much for your great help. Currently I am stucked on 
  x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not 
clear 
  what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the 
  ms_abi variant for sysv_abi as default too. But I think, it breaks 87 
fpu 
  stuff for this ABI !?!
 
 x86_function_value_regno_p is tricky one.  Speaking strictly from
 definition I think it should
  - for current SYSV ABI with no MS ABI function calls return set it
returns for MS ABI (not including x87)
  - for current SYSV ABI or MS ABI with SYSV ABI function calls return 
set it
returns for SYSV ABI (including x87)
 
 However see the use in builtins.c - it expects that this function is
 invariant for whole compilation unit, so implementing the above would
 need updating builtins.c too.
 
 The feature is used just seldomly - for the extra builtin expansion,
 in combine.c for logic that won't fire for x87, in mode switching to
 support the builtin_apply above and in rtlanal.c to avoid separating
 the return value from call. With x87 register we should not be spoiled
 here either, since x87 is quite symetric before regstack and restackwill 
know
 how to fix this up.
 
 My best bet would be that making the function dependent on default ABI
 is good enough.  You might add some comment that the function should
 depend on current function ABI but builtins.c would need updating then.
 
 Honza

I noticed, that OUTGOING_REG_PARM_STACK_SPACE makes troubles too. What is 
about extending this macro by a FNDECL argument ? This would solve the 
problem and AFAICS the function declaration seems to be always present.

Cheers,
 i.A. Kai Tietz

|  (\_/)  This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| ()_() world domination.

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



Re: AMD64 ABI compatibility

2007-07-11 Thread Jan Hubicka
 Jan Hubicka wrote on 11.07.2007 14:01:54:
 
   
   I thank you very much for your great help. Currently I am stucked on 
   x86_function_value_regno_p (macro FUNCTION_VALUE_REGNO_P). It is not 
 clear 
   what's to do here for the FIRST_FLOAT_REG case. Maybe I could use the 
   ms_abi variant for sysv_abi as default too. But I think, it breaks 87 
 fpu 
   stuff for this ABI !?!
  
  x86_function_value_regno_p is tricky one.  Speaking strictly from
  definition I think it should
   - for current SYSV ABI with no MS ABI function calls return set it
 returns for MS ABI (not including x87)
   - for current SYSV ABI or MS ABI with SYSV ABI function calls return 
 set it
 returns for SYSV ABI (including x87)
  
  However see the use in builtins.c - it expects that this function is
  invariant for whole compilation unit, so implementing the above would
  need updating builtins.c too.
  
  The feature is used just seldomly - for the extra builtin expansion,
  in combine.c for logic that won't fire for x87, in mode switching to
  support the builtin_apply above and in rtlanal.c to avoid separating
  the return value from call. With x87 register we should not be spoiled
  here either, since x87 is quite symetric before regstack and restackwill 
 know
  how to fix this up.
  
  My best bet would be that making the function dependent on default ABI
  is good enough.  You might add some comment that the function should
  depend on current function ABI but builtins.c would need updating then.
  
  Honza
 
 I noticed, that OUTGOING_REG_PARM_STACK_SPACE makes troubles too. What is 
 about extending this macro by a FNDECL argument ? This would solve the 
 problem and AFAICS the function declaration seems to be always present.

Yes, this is what I would suggest.  There is little trickery here -
OUTGOING_REG_PARM_STACK_SPACE is used in calls.c where it is function
call specific and I think adding decl argument will just do the right
thing.

Other use is in definition of STACK_DYNAMIC_OFFSET use in function.c
This case however cares if REG_PARM_STACK_SPACE is present in currently
compiled function (that is if the current function has some call in MS
ABI mode).
I guess this can be dealt with adding
CURRENT_FUNCTOIN_OUTGOING_REG_PARM_STACK_SPACE that would DRT, but we need
to double check that defining it won't move all function arguments away
from top of stack breaking any calls to SYSV ABI mode in the same
function.

I am about to leave again, I will try to look into the implementation
later today (I am just about to leave now)

Honza
 
 Cheers,
  i.A. Kai Tietz
 
 |  (\_/)  This is Bunny. Copy and paste Bunny
 | (='.'=) into your signature to help him gain
 | ()_() world domination.
 
 --
   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
 


-fstrict-overflow example 4.2 status

2007-07-11 Thread Christian BRUEL

hello,

The example provided with the -fstrict-overflow description in the 
http://gcc.gnu.org/gcc-4.2/changes.html page doesn't optimize as described.


Is it only a documentation bug ? The example is optimized as expected on 
the trunk.


Regards,

-c


Re: ODR violation for std::cout etc.

2007-07-11 Thread Benjamin Kosnik

The current situation was the best compromise we arrived at in the
very old days of GCC-3.x.x -- see the archive for discussions.


Indeed. I would resist change just for change's sake, especially when
we have not seen a detailed bug report filed.


I'd suspect that nowadays we have better ways of handling the
issues -- though I've not done any new investigation.


I've been waiting to revisit this issue until we have correct
alignment support for template objects (std::aligned_storage, etc.)
in g++. Then, we can use array_allocator to deal with this stuff in a
much more transparent and C++ friendly way.

-benjamin


Re: -fstrict-overflow example 4.2 status

2007-07-11 Thread Ian Lance Taylor
Christian BRUEL [EMAIL PROTECTED] writes:

 The example provided with the -fstrict-overflow description in the
 http://gcc.gnu.org/gcc-4.2/changes.html page doesn't optimize as
 described.
 
 Is it only a documentation bug ? The example is optimized as expected
 on the trunk.

I only said that the compiler may turn it into an infinite loop.  It
was intended to be a dramatic example of what can happen in principle,
not a specific prediction of what gcc 4.2 will do.

I'm not opposed to changing the documentation if you have an
alternative proposal.

Ian


Re: abs insn with QI and HI mode

2007-07-11 Thread Jim Wilson
On Tue, 2007-07-10 at 10:35 +0100, Ying Yi wrote:
 Thanks very much for your email. Will gcc add the optimization support  
 in the future (method 1)? For method 2, if abs accept short/char, may  
 I give the function names as sabs and qabs? Gcc does already have cabs  
 as complex abs, doesn't it?

The function names I gave are mostly standard library names, specified,
by ISO C, POSIX, GNU libc, or whatever.  New functions sabs and qabs
would not be standard in that sense, and may conflict with user code,
which may be undesirable.  Names like __builtin_sabs and __builtin_qabs
would be better from that point of view.  The builtins.def file has a
number of different ways of defining builtin functions depending on
which command line options should enable/disable them, and whether or
not __builtin should be prepended.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com




Re: abs insn with QI and HI mode

2007-07-11 Thread Rask Ingemann Lambertsen
On Tue, Jul 10, 2007 at 10:35:01AM +0100, Ying Yi wrote:
 Hi Jim,

 To get your special char/short abs instructions, we need one of two things
 1) Optimization support to recognize a sign-extend followed by an abs,
 where the target has an abs instruction that operates on the
 pre-extended value.  We can then optimize away the sign extend
 instruction.  This optimization support apparently does not exist at
 the moment, perhaps because no one has needed it before.
 
 Thanks very much for your email. Will gcc add the optimization support  
 in the future (method 1)?

   Please don't top post. Thanks.

   Shameless plug: Get trunk revision 126251 or later and compile with
-fdump-rtl-combine-details, then look at the dump file. There is a good
chance that combine is already looking for such an instruction.

-- 
Rask Ingemann Lambertsen


Andreas Krebbel appointed s390 co-maintainer

2007-07-11 Thread David Edelsohn
I am pleased to announce that the GCC Steering Committee has
appointed Andreas Krebbel as s390 port co-maintainer.

Please join me in congratulating Andreas on his new role.
Andreas, please update your listing in the MAINTAINERS file.

Happy hacking!
David



Re: ODR violation for std::cout etc.

2007-07-11 Thread Gabriel Dos Reis
Benjamin Kosnik [EMAIL PROTECTED] writes:

| I've been waiting to revisit this issue until we have correct
| alignment support for template objects (std::aligned_storage, etc.)
| in g++. Then, we can use array_allocator to deal with this stuff in a
| much more transparent and C++ friendly way.

I'm in full agreement with that position.

-- Gaby


[Fwd: error in libfortran on cygwin]

2007-07-11 Thread Bobby McNulty





This is i686-pc-cygwin.

The error is that tzp is unknown in system_clock.c.

Here is the output from make

___



make[3]: Entering directory `/home/bobby/gcc/o/i686-pc-cygwin/libgfortran'

if /bin/sh ./libtool --tag=CC --mode=compile 
/home/bobby/gcc/o/./gcc/xgcc -B/hom


e/bobby/gcc/o/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ 
-B/usr/local/i686-pc-cygwi


n/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem 
/usr/local/i686-pc-cy


gwin/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc43/libgfortran -I.  
-iquote..


/../../gcc43/libgfortran/io -I../../../gcc43/libgfortran/../gcc 
-I../../../gcc43


/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE  -std=gnu99 -Wall 
-Wstric


t-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra 
-Wwrite-strings


-O2 -O2  -MT system_clock.lo -MD -MP -MF .deps/system_clock.Tpo -c -o 
system_


clock.lo `test -f 'intrinsics/system_clock.c' || echo 
'../../../gcc43/libgfortra


n/'`intrinsics/system_clock.c; \

   then mv -f .deps/system_clock.Tpo .deps/system_clock.Plo; 
else rm -f


.deps/system_clock.Tpo; exit 1; fi

libtool: compile:  /home/bobby/gcc/o/./gcc/xgcc 
-B/home/bobby/gcc/o/./gcc/ -B/us


r/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem 
/usr/local


/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include 
-DHAVE_CO


NFIG_H -I. -I../../../gcc43/libgfortran -I. 
-iquote../../../gcc43/libgfortran/io


-I../../../gcc43/libgfortran/../gcc 
-I../../../gcc43/libgfortran/../gcc/config


-I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes 
-Wmissing-proto


types -Wold-style-definition -Wextra -Wwrite-strings -O2 -O2 -MT 
system_clock.lo


-MD -MP -MF .deps/system_clock.Tpo -c 
../../../gcc43/libgfortran/intrinsics/sys


tem_clock.c  -DDLL_EXPORT -DPIC -o .libs/system_clock.o

../../../gcc43/libgfortran/intrinsics/system_clock.c: In function 
'system_clock_


4':

../../../gcc43/libgfortran/intrinsics/system_clock.c:68: error: storage 
size of


'tzp' isn't known

../../../gcc43/libgfortran/intrinsics/system_clock.c:68: warning: unused 
variabl


e 'tzp'

../../../gcc43/libgfortran/intrinsics/system_clock.c: In function 
'system_clock_


8':

../../../gcc43/libgfortran/intrinsics/system_clock.c:131: error: storage 
size of


'tzp' isn't known

../../../gcc43/libgfortran/intrinsics/system_clock.c:131: warning: 
unused variab


le 'tzp'

make[3]: *** [system_clock.lo] Error 1

make[3]: Leaving directory `/home/bobby/gcc/o/i686-pc-cygwin/libgfortran'

make[2]: *** [all] Error 2

make[2]: Leaving directory `/home/bobby/gcc/o/i686-pc-cygwin/libgfortran'

make[1]: *** [all-target-libgfortran] Error 2

make[1]: Leaving directory `/home/bobby/gcc/o'

make: *** [all] Error 2



[EMAIL PROTECTED] ~/gcc/o

$



Test gcc.c-torture/execute/align-3.c

2007-07-11 Thread Steve Ellcey

The test gcc.c-torture/execute/align-3.c is failing on most of my
platforms, including IA64 HP-UX and Linux.  The test consists of:

  void func(void) __attribute__((aligned(256)));

  void func(void)
  {
  }

  int main()
  {
if (((long)func  0xFF) != 0)
  abort ();
if (__alignof__(func) != 256)
  abort ();
return 0;
  }

The problem I am having is with the first test, checking that the
address of func is aligned.  The problem is that using func in this way
on IA64 gives me the address of the function descriptor, not the address
of the function itself.  And while the function address does appear to
be aligned on a 256 byte boundry, the function descriptor has its normal
8 byte alignment.  My question is, should function descriptors have the
same alignment as functions or is this just an invalid test on systems
that use function descriptors?

Steve Ellcey
[EMAIL PROTECTED]


Re: Test gcc.c-torture/execute/align-3.c

2007-07-11 Thread Geoff Keating


On 11/07/2007, at 4:48 PM, Steve Ellcey wrote:



The test gcc.c-torture/execute/align-3.c is failing on most of my
platforms, including IA64 HP-UX and Linux.  The test consists of:

 void func(void) __attribute__((aligned(256)));

 void func(void)
 {
 }

 int main()
 {
   if (((long)func  0xFF) != 0)
 abort ();
   if (__alignof__(func) != 256)
 abort ();
   return 0;
 }

The problem I am having is with the first test, checking that the
address of func is aligned.  The problem is that using func in this  
way
on IA64 gives me the address of the function descriptor, not the  
address

of the function itself.  And while the function address does appear to
be aligned on a 256 byte boundry, the function descriptor has its  
normal
8 byte alignment.  My question is, should function descriptors have  
the

same alignment as functions or is this just an invalid test on systems
that use function descriptors?


I knew there was a reason that first test wouldn't work on some  
platform, it seemed too good to be true.


The compiler understands that a pointer-to-function need not actually  
have the same low bits clear as the address of the function itself, so  
it's OK for the descriptor to not be aligned as much as the function  
to which it points.


Feel free to either (a) #ifdef out the first part of the test on IA64,  
or (b) delete the first part of the test altogether.


RFH: GPLv3

2007-07-11 Thread Mark Mitchell
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.

However, here are the things that have now been decided:

1. The compiler proper (e.g., files used only in cc1, cc1plus, the
driver, etc.) should all be converted to GPLv3 ASAP.

Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?

2. GCC 4.2.1 will be the last GPLv2 release.  The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.

3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
  What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch.  The GCC mainline will then be GCC 4.4.

It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception.  Therefore,
no changes to

It has also not yet been decided whether backports of bug-fixes from
GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
will result in the patched compilers being GPLv3.  If you have thoughts
about that, you might wish to contact the FSF.

Thanks,

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


[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550

2007-07-11 Thread ebotcazou at gcc dot gnu dot org


--- Comment #1 from ebotcazou at gcc dot gnu dot org  2007-07-11 06:12 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-11 06:12:12
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713



[Bug fortran/31823] [4.2 regression] COMPLEX not documented

2007-07-11 Thread brooks at gcc dot gnu dot org


--- Comment #5 from brooks at gcc dot gnu dot org  2007-07-11 06:25 ---
Subject: Bug 31823

Author: brooks
Date: Wed Jul 11 06:25:47 2007
New Revision: 126538

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126538
Log:
Backport from trunk:
PR fortran/31823
* intrinsic.texi (CMPLX): Document result kind.
(COMPLEX): Add documentation.


Modified:
branches/gcc-4_2-branch/gcc/fortran/ChangeLog
branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823



[Bug fortran/31823] [4.2 regression] COMPLEX not documented

2007-07-11 Thread brooks at gcc dot gnu dot org


--- Comment #6 from brooks at gcc dot gnu dot org  2007-07-11 06:34 ---
Fixed, as per the above commit.


-- 

brooks at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823



[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'

2007-07-11 Thread burnus at gcc dot gnu dot org


--- Comment #3 from burnus at gcc dot gnu dot org  2007-07-11 06:38 ---
Working: 2007-07-09-r126478
Failing: 2007-07-10-r126510

I believe it is due to the patch
 r126509 | pault | 2007-07-10 07:11:00 +0200 (Di, 10 Jul 2007) | 28 lines
PR 32634 [...]
* module.c (write_generic): Write the local name of the
interface.
but I might be wrong and it is one of:
 r126486 | dfranke | 2007-07-09 16:56:49 +0200 (Mon, 09 Jul 2007) | 14 lines
 r126493 | kargl | 2007-07-09 21:41:37 +0200 (Mon, 09 Jul 2007) | 6 lines
 r126496 | fxcoudert | 2007-07-10 00:00:52 +0200 (Tue, 10 Jul 2007) | 6 lines

The error message is:

  USE util,ONLY: sort
   1
Error: Symbol 'sort' referenced at (1) not found in module 'util'


Reduced test case:

MODULE kinds
  INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 )
END MODULE kinds

MODULE util
  USE kinds,   ONLY: dp
  INTERFACE sort
 MODULE PROCEDURE sort2
  END INTERFACE
CONTAINS
  SUBROUTINE sort2 ( )
  END SUBROUTINE sort2
END MODULE util

MODULE graphcon
  USE util,ONLY: sort
END MODULE graphcon


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727



[Bug bootstrap/32726] ICE when compiling emit-rtl.c

2007-07-11 Thread dorit at gcc dot gnu dot org


--- Comment #1 from dorit at gcc dot gnu dot org  2007-07-11 06:43 ---
(In reply to comment #0)
 r126521 on ppc64-linux
 bootstrap fails with

r126512 passed bootstrap on powerpc64, so I guess the problem was introduced
somewhere in between


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726



[Bug bootstrap/32726] ICE when compiling emit-rtl.c

2007-07-11 Thread eres at il dot ibm dot com


--- Comment #2 from eres at il dot ibm dot com  2007-07-11 06:51 ---
The problem seems to be fixed.

See - http://gcc.gnu.org/ml/gcc/2007-07/msg00352.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726



[Bug c++/32687] Invalid code generation for reading signed negative bitfield value (g++ optimization)

2007-07-11 Thread siarhei dot siamashka at gmail dot com


--- Comment #2 from siarhei dot siamashka at gmail dot com  2007-07-11 
07:06 ---
Tried this test with gcc 4.2.0, it also works correctly. So looks like the
problem only shows up in gcc 4.1.x


-- 

siarhei dot siamashka at gmail dot com changed:

   What|Removed |Added

  Known to work|3.4.6 4.3.0 |3.4.6 4.2.0 4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32687



[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.

2007-07-11 Thread rguenther at suse dot de


--- Comment #7 from rguenther at suse dot de  2007-07-11 08:32 ---
Subject: Re:  [4.2/4.3 Regression] Wrong code generation.
 Alias and C++ virtual bases problem.

On Tue, 10 Jul 2007, dberlin at dberlin dot org wrote:

 On 10 Jul 2007 15:32:51 -, rguenther at suse dot de
 [EMAIL PROTECTED] wrote:
 
 
  --- Comment #5 from rguenther at suse dot de  2007-07-10 15:32 ---
  Subject: Re:  [4.2/4.3 Regression] Wrong code generation.
   Alias and C++ virtual bases problem.
 
  On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote:
 
   --- Comment #4 from ramana dot radhakrishnan at celunite dot com  
   2007-07-10 15:14 ---
   (In reply to comment #3)
Fixed with take3.diff.
   
  
   Did you forget to attach take3.diff ?
 
  No, that was a hint to Danny ;)
 
 
 You never told me whether omnetpp/xalanbmc were still failing with it or not 
 :)

Doh!  Yes, they did.  You never got around sending me the variant with
more asserts either ;)

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716



[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'

2007-07-11 Thread dfranke at gcc dot gnu dot org


--- Comment #4 from dfranke at gcc dot gnu dot org  2007-07-11 08:33 ---
No error up to and including r126496. That leaves only Paul's patch ...


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727



[Bug fortran/31608] wrong types in character array/scalar binop

2007-07-11 Thread rguenther at suse dot de


--- Comment #14 from rguenther at suse dot de  2007-07-11 08:36 ---
Subject: Re:  wrong types in character array/scalar binop

On Wed, 10 Jul 2007, pinskia at gcc dot gnu dot org wrote:

 --- Comment #13 from pinskia at gcc dot gnu dot org  2007-07-10 23:36 
 ---
 I think this was fixed with
 http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01471.html
 
 aka PR32140.

No, it's still there.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608



[Bug tree-optimization/32721] CCP removes volatile qualifiers.

2007-07-11 Thread rguenther at suse dot de


--- Comment #4 from rguenther at suse dot de  2007-07-11 08:45 ---
Subject: Re:  CCP removes volatile qualifiers.

On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote:

 (In reply to comment #2)
  As the decl is volatile as well this is clearly a bogus optimization.
  
 
 Putting a breakpoint on evaluate_stmt in tree-ssa-ccp.c shows that stmt_ann of
 the stmt does not have has_volatile_ops set to true. 
 
 
 (gdb) p stmt 
 (gdb) pt
  gimple_modify_stmt 0xb7d4fee0 side-effects
 arg 0 ssa_name 0xb7d4aed4
 type pointer_type 0xb7d44bd0 type integer_type 0xb7d44b64 int
 sizes-gimplified unsigned SI
 size integer_cst 0xb7caa460 constant invariant 32
 unit size integer_cst 0xb7caa24c constant invariant 4
 align 32 symtab 0 alias set -1 canonical type 0xb7d44bd0
 visited var var_decl 0xb7d5005c spinlock0 def_stmt
 gimple_modify_stmt 0xb7d4fee0
 version 1
 arg 1 addr_expr 0xb7d481c0 type pointer_type 0xb7d44bd0
 constant invariant
 arg 0 array_ref 0xb7cb5084 type integer_type 0xb7d44b64 int
 arg 0 var_decl 0xb7d5 spinlock
 arg 1 integer_cst 0xb7d4fec4 constant invariant 0
 try.c:5
 (gdb) (gdb) p *(stmt-base-ann)
 $17 = {common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, vdecl = {
 common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, 
 out_of_ssa_tag = 0, base_var_processed = 0, used = 0, 
 need_phi_state = NEED_PHI_STATE_NO, in_vuse_list = 1, in_vdef_list = 0, 
 is_heapvar = 0, call_clobbered = 1, noalias_state = NO_ALIAS_GLOBAL, 
 mpt = 0xb7cb6804, symbol_mem_tag = 0x0, partition = 0, base_index = 0, 
 current_def = 0x0, subvars = 0x0, escape_mask = 3084210192}, fdecl = {
 common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, 
 reference_vars_info = 0xb7eed528}, stmt = {common = {type = STMT_ANN, 
   aux = 0x0, value_handle = 0x0}, bb = 0xb7eed528, operands = {
   def_ops = 0xb7cb6804, use_ops = 0x0, vdef_ops = 0x0, vuse_ops = 0x0, 
   stores = 0x0, loads = 0x0}, addresses_taken = 0xb7d55010, uid = 0, 
 references_memory = 0, modified = 0, has_volatile_ops = 0, 
 makes_clobbering_call = 0}}
 
 Shouldn't has_volatile_ops get set to true in this case because the stmt
 essentially has one volatile operand here ? 

No, this assignment just assigns pointers (the pointers are not volatile,
just the thing they point to is).  Basically volatile ops is set only
on statements reading/writing memory.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721



[Bug fortran/32627] [ISO Bind C] Accept c_f_pointer for TYPE

2007-07-11 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2007-07-11 08:46 ---
Also
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/index.html
fails with the same error.
(One needs to change g95) into g95|gfortran) in configure.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32627



[Bug fortran/31608] wrong types in character array/scalar binop

2007-07-11 Thread jv244 at cam dot ac dot uk


--- Comment #15 from jv244 at cam dot ac dot uk  2007-07-11 08:52 ---
FYI, testcase is standard conforming code AFAICT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608



[Bug middle-end/32725] Unnecessary reg-reg moves

2007-07-11 Thread rask at sygehus dot dk


--- Comment #1 from rask at sygehus dot dk  2007-07-11 08:53 ---
I think (1) and (2) is just the register allocator being stupid. This sort of
thing can happen when the %rax at (1) was a different pseudo register than the
%rax at (2). The register allocator is supposed to be able to tie such pseudo
registers, but it does not take a lot to mess that up.
You should use -dp when posting asm output intended for human readers (although
in this case, I don't think you need to repost the asm output just to include
the -dp output).

movq%rax, %rbx  # 95*movdi_1_rex64/2[length = 6]
andq%r8, %rbx   # 25*anddi_1_rex64/2[length = 3]
movq%rbx, %rax  # 96*movdi_1_rex64/2[length = 6]

Notice that the movq insns have much higher insn uids than the andq insn. I.e.
they were most likely emitted in a later pass.
(And those movq insn lenghts are wrong, they should be 3 instead of 6.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725



[Bug c++/32560] [4.3 regression] ICE on invalid declaration in template

2007-07-11 Thread paolo at gcc dot gnu dot org


--- Comment #2 from paolo at gcc dot gnu dot org  2007-07-11 09:18 ---
Subject: Bug 32560

Author: paolo
Date: Wed Jul 11 09:18:39 2007
New Revision: 126542

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126542
Log:
/cp
2007-07-11  Paolo Carlini  [EMAIL PROTECTED]

PR c++/32560
* parser.c (cp_parser_make_indirect_declarator): When the
the code argument is ERROR_MARK return cp_error_declarator.

/testsuite
2007-07-11  Paolo Carlini  [EMAIL PROTECTED]

PR c++/32560
* g++.dg/template/decl3.C: New. 

Added:
trunk/gcc/testsuite/g++.dg/template/decl3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32560



[Bug c++/32560] [4.3 regression] ICE on invalid declaration in template

2007-07-11 Thread pcarlini at suse dot de


--- Comment #3 from pcarlini at suse dot de  2007-07-11 09:19 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32560



[Bug tree-optimization/32589] [4.3 regression] exp_dbug.adb:981: error: invalid array index

2007-07-11 Thread ebotcazou at gcc dot gnu dot org


--- Comment #10 from ebotcazou at gcc dot gnu dot org  2007-07-11 09:43 
---
Subject: Bug 32589

Author: ebotcazou
Date: Wed Jul 11 09:43:25 2007
New Revision: 126545

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126545
Log:
PR tree-optimization/32589
* doc/tree-ssa.texi (Rough GIMPLE Grammar): Add missing rule.
* tree-gimple.c (is_gimple_min_invariant): Clarify head comment.
* tree-ssa-propagate.c (valid_gimple_expression_p): New
predicate, extracted from...
(set_rhs): ...here.  Call it for the expression on entry.
* tree-ssa-propagate.h (valid_gimple_expression_p): Declare.
* tree-ssa-sccvn.c: Include tree-ssa-propagate.h.
(simplify_binary_expression): Use valid_gimple_expression_p
to validate the simplification.
* Makefile.in (tree-ssa-sccvn.o): Depends on tree-ssa-propagate.h.


Added:
trunk/gcc/testsuite/gnat.dg/invariant_index.adb
trunk/gcc/testsuite/gnat.dg/invariant_index.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/doc/tree-ssa.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-gimple.c
trunk/gcc/tree-ssa-propagate.c
trunk/gcc/tree-ssa-propagate.h
trunk/gcc/tree-ssa-sccvn.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589



[Bug tree-optimization/32589] [4.3 regression] exp_dbug.adb:981: error: invalid array index

2007-07-11 Thread ebotcazou at gcc dot gnu dot org


--- Comment #11 from ebotcazou at gcc dot gnu dot org  2007-07-11 09:46 
---
The compiler now bootstraps, but the library still doesn't build.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589



[Bug fortran/31608] wrong types in character array/scalar binop

2007-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #16 from rguenth at gcc dot gnu dot org  2007-07-11 09:55 
---
Trying to reduce the testcase, the following ICEs:

contains
  Character (len=20) Function Up (string)
Character(len=*) string
Up =
 transfer(merge(transfer(string,x,len(string)),
   string, .true.), x)
return
  end function Up
end


./f951 -quiet achar_4.f90
achar_4.f90: In function 'up':
achar_4.f90:9: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:4525
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608



[Bug fortran/31608] wrong types in character array/scalar binop

2007-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #17 from rguenth at gcc dot gnu dot org  2007-07-11 10:00 
---
Reduced testcase:

contains
  Character (len=20) Function Up (string)
Character(len=*) string
Up = transfer(achar(iachar(transfer(string,x,1))), x)
return
  end function Up
end


char.3 = (*(char[0:][1:1] *) atmp.0.data)[S.2][1]{lb: 1 sz: 1};
(*(char[0:][1:1] *) atmp.1.data)[S.2] = char.3;

the first line is correct, the second is not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608



[Bug fortran/31608] wrong types in character array/scalar binop

2007-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #18 from rguenth at gcc dot gnu dot org  2007-07-11 10:13 
---
Built from

#0  build4_stat (code=ARRAY_REF, tt=0x2b468e0df750, arg0=0x2b468e0e4880, 
arg1=0x2b468e0e7000, arg2=0x0, arg3=0x0)
at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3170
#1  0x00497ae4 in gfc_build_array_ref (base=0x2b468e0e4880, 
offset=0x2b468e0e7000)
at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans.c:317
#2  0x0049eab7 in gfc_conv_scalarized_array_ref (se=0x7fff1d4d8400, 
ar=0x0)
at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-array.c:2227
#3  0x004a5b0c in gfc_conv_expr_descriptor (se=0x7fff1d4d8860, 
expr=0x1395c70, ss=0x1397540)
at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-array.c:4583
#4  0x004a703e in gfc_conv_array_parameter (se=0x7fff1d4d8860, 
expr=0x1395c70, ss=0x1397540, g77=1)
at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-array.c:4887
#5  0x004d0cd2 in gfc_conv_intrinsic_transfer (se=0x7fff1d4d8be0, 
expr=0x1395a10)
at /space/rguenther/src/svn/pointer_plus/gcc/fortran/trans-intrinsic.c:3195

but I'm lost where to fix this up.  Fortran FE functions are poorly documented.
It's unclear whether the descriptors are wrong or not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608



[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph

2007-07-11 Thread pixel at mandriva dot com


--- Comment #4 from pixel at mandriva dot com  2007-07-11 10:23 ---
i forgot to say it doesn't occur without -O, and occurs with -O, -O2

/usr/lib/gcc/i586-mandriva-linux-gnu/4.2.1/cc1 -O fail.c
 _create
Analyzing compilation unitPerforming interprocedural optimizations
Assembling functions:
 _create
Execution times (seconds)
 callgraph construction:   0.14 ( 1%) usr   0.01 ( 0%) sys   0.14 ( 0%) wall   
   0 kB ( 0%) ggc
 callgraph optimization:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 ipa reference :   0.07 ( 0%) usr   0.02 ( 0%) sys   0.10 ( 0%) wall   
 428 kB ( 1%) ggc
 preprocessing :   0.27 ( 1%) usr   0.23 ( 2%) sys   0.68 ( 2%) wall   
8293 kB (25%) ggc
 lexical analysis  :   0.13 ( 1%) usr   0.60 ( 4%) sys   0.84 ( 3%) wall   
   0 kB ( 0%) ggc
 parser:   0.64 ( 3%) usr   0.43 ( 3%) sys   0.84 ( 3%) wall  
18586 kB (57%) ggc
 tree find ref. vars   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
1905 kB ( 6%) ggc
 tree PTA  :  15.92 (86%) usr  10.73 (72%) sys  26.67 (80%) wall   
   5 kB ( 0%) ggc
 tree alias analysis   :   0.91 ( 5%) usr   2.77 (19%) sys   3.65 (11%) wall   
   0 kB ( 0%) ggc
 tree SSA incremental  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall   
   0 kB ( 0%) ggc
 tree SRA  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 expand:   0.10 ( 1%) usr   0.00 ( 0%) sys   0.11 ( 0%) wall   
   7 kB ( 0%) ggc
 varconst  :   0.05 ( 0%) usr   0.02 ( 0%) sys   0.01 ( 0%) wall   
 643 kB ( 2%) ggc
 global alloc  :   0.00 ( 0%) usr   0.01 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 symout:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall   
   0 kB ( 0%) ggc
 TOTAL :  18.5714.8433.41 
32596 kB



ps: the verbose output is a little garbled, this trivial patch on 
branches/gcc-4_2-branch fixes it:

--- gcc/cgraphunit.c(revision 126511)
+++ gcc/cgraphunit.c(working copy)
@@ -1544,7 +1544,7 @@

   timevar_push (TV_CGRAPHOPT);
   if (!quiet_flag)
-fprintf (stderr, Performing interprocedural optimizations\n);
+fprintf (stderr, \nPerforming interprocedural optimizations\n);

   cgraph_function_and_variable_visibility ();
   if (cgraph_dump_file)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723



[Bug middle-end/30482] complex division by 0

2007-07-11 Thread paolo at gcc dot gnu dot org


--- Comment #2 from paolo at gcc dot gnu dot org  2007-07-11 10:24 ---
Subject: Bug 30482

Author: paolo
Date: Wed Jul 11 10:23:56 2007
New Revision: 126546

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126546
Log:
2007-07-11  Paolo Carlini  [EMAIL PROTECTED]

PR middle-end/30482
* c-opts.c (c_common_post_options): Do not change flag_complex_method
conditional to flag_isoc99.
(c_common_init_options): Do it here, unconditionally.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-opts.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482



[Bug middle-end/30482] complex division by 0

2007-07-11 Thread pcarlini at suse dot de


--- Comment #3 from pcarlini at suse dot de  2007-07-11 10:24 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30482



[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550

2007-07-11 Thread ebotcazou at gcc dot gnu dot org


--- Comment #2 from ebotcazou at gcc dot gnu dot org  2007-07-11 10:29 
---
Subject: Bug 32713

Author: ebotcazou
Date: Wed Jul 11 10:29:17 2007
New Revision: 126547

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126547
Log:
PR tree-optimization/32713
* tree-ssa-sccvn.c (copy_reference_ops_from_ref): Handle REAL_CST.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-sccvn.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713



[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550

2007-07-11 Thread ebotcazou at gcc dot gnu dot org


--- Comment #3 from ebotcazou at gcc dot gnu dot org  2007-07-11 10:31 
---
The Ada compiler is alive again everywhere.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713



[Bug fortran/31608] wrong types in character array/scalar binop

2007-07-11 Thread jv244 at cam dot ac dot uk


--- Comment #19 from jv244 at cam dot ac dot uk  2007-07-11 10:25 ---
(In reply to comment #16)
 Trying to reduce the testcase, the following ICEs:

PR 31610 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608



[Bug tree-optimization/32477] ice for legal code with -O2 -ftree-vectorize

2007-07-11 Thread irar at il dot ibm dot com


--- Comment #5 from irar at il dot ibm dot com  2007-07-11 10:49 ---
Fixed.


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32477



[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8

2007-07-11 Thread tbm at cyrius dot com


--- Comment #8 from tbm at cyrius dot com  2007-07-11 12:02 ---
Created an attachment (id=13884)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13884action=view)
-fdump-tree-original, no flag


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357



[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8

2007-07-11 Thread tbm at cyrius dot com


--- Comment #9 from tbm at cyrius dot com  2007-07-11 12:02 ---
Created an attachment (id=13885)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13885action=view)
-fdump-tree-original, -fdefault-integer-8


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357



[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8

2007-07-11 Thread tbm at cyrius dot com


--- Comment #10 from tbm at cyrius dot com  2007-07-11 12:03 ---
 Could you (or some other interested party) compile t.f90 with
 -fdump-tree-original, both with and without -fdefault-integer-8, and post the
 t.f90.003t.original file produced in each case? This would help us understand
 where the problem is, without having access to a powerpc machine.

Done, on a MIPS (big-endian) box.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357



[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8

2007-07-11 Thread fxcoudert at gcc dot gnu dot org


--- Comment #11 from fxcoudert at gcc dot gnu dot org  2007-07-11 12:29 
---
The call to MVBITS is translated as a function call:
_gfortran_mvbits_i8 (C.913, C.914, C.915, i, C.916);
where all C.* (and i) variables are int8, while the library prototype for the
function is:
_gfortran_mvbits_i8 (const GFC_INTEGER_8 *from, const GFC_INTEGER_4
*frompos,
  const GFC_INTEGER_4 *len, GFC_INTEGER_8 *to, const GFC_INTEGER_4
*topos)

We need to make a choice between these two, and decided whether all arguments
have the same type (my preferred choice) or if some have a fixed type. In all
cases, uses of MVBITS with different mixed kinds should be audited, for there
might be a few other inconsistencies lurking here.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-15 19:19:03 |2007-07-11 12:29:59
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357



[Bug c++/32674] [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class

2007-07-11 Thread lmillward at gcc dot gnu dot org


-- 

lmillward at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674



[Bug tree-optimization/32722] [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop

2007-07-11 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2007-07-11 13:14 ---
Created an attachment (id=13886)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13886action=view)
reduced testcase

I suppose it needs some minimal DECL_UID, this is as small as I can get it
(automated).  Fails in verify_ssa compiling with -O2 -fno-tree-store-copy-prop
--param ggc-min-expand=0 --param ggc-min-heapsize=0.

tree-ssa-structalias.3.min.i:1098: error: definition in block 5 follows the use
for SSA_NAME: D.4370_29 in statement:
D.4369_26 = D.4370_29;
tree-ssa-structalias.3.min.i:1098: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722



[Bug fortran/32380] misaligned stores don't get vectorized

2007-07-11 Thread irar at il dot ibm dot com


--- Comment #2 from irar at il dot ibm dot com  2007-07-11 14:50 ---
I don't get any dependence test failures on current mainline. I think they were
solved by Zdenek's rewrite of data-refs' analysis, since I can still see those
failures on autovect-branch (with old data-refs' analysis):

unal.f:222: note: not vectorized: can't determine dependence between  
csfsavloc.savfrc[D.2175_919] and csfsavloc.savfrc[D.2388_922]
unal.f:159: note: not vectorized: can't determine dependence between
aux01loc.fm11[D.2175_330] and aux01loc.fm11[D.2175_330]
unal.f:172: note: not vectorized: can't determine dependence between
aux01loc.ft11[D.2175_439] and aux01loc.ft11[D.2175_439]

On the mainline unal.f:222 gets vectorized now, and unal.f:159 and unal.f:172
are not vectorized because unsupported unaligned stores:

unal.f:222: note: LOOP VECTORIZED.(get_loop_exit_condition
unal.f:198: note: LOOP VECTORIZED.

unal.f:209: note: not vectorized: unsupported unaligned store.
unal.f:159: note: not vectorized: unsupported unaligned store.
unal.f:172: note: not vectorized: unsupported unaligned store.
unal.f:138: note: not vectorized: unsupported unaligned store.
unal.f:127: note: not vectorized: unsupported unaligned store.

With loop distribution we could vectorize these loops using peeling to handle
misaligned stores (multiple stores make peeling for alignment insufficient
here).
Misaligned stores support is on the top of our TODO list in Wiki (see
http://gcc.gnu.org/wiki/VectorizationTasks)...

I am adding missed-optimization keyword and changing the summary.

Thanks,
Ira


-- 

irar at il dot ibm dot com changed:

   What|Removed |Added

 CC||irar at il dot ibm dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2007-07-11 14:50:36
   date||
Summary|reports unaligned store   |misaligned stores don't get
   |and can't determine |vectorized
   |dependence  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380



[Bug c++/29297] Segmentation fault on invalid use of `::'

2007-07-11 Thread pcarlini at suse dot de


--- Comment #2 from pcarlini at suse dot de  2007-07-11 15:02 ---
Can't reproduce with current mainline / 4_2-branch / 4_1-branch, on
x86_64-linux.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29297



[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args

2007-07-11 Thread scovich at gmail dot com


--- Comment #2 from scovich at gmail dot com  2007-07-11 15:03 ---
(In reply to comment #1)
 Confirmed, not a regression.
 

Also affects 4.3. Changing target


-- 

scovich at gmail dot com changed:

   What|Removed |Added

Version|4.1.2   |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661



[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args

2007-07-11 Thread scovich at gmail dot com


--- Comment #3 from scovich at gmail dot com  2007-07-11 15:10 ---
This bug also causes _mm_cvtsi128_si64x() (which calls
__builtin_ia32_vec_ext_v2di) to emit suboptimal code.

// g++-4.3-070710 -mtune=core2 -O3 -S -dp
#include emmintrin.h
long vector2long(__m128i* src) { return _mm_cvtsi128_si64x(*src); }

Becomes

_Z11vector2longPU8__vectorx:
.LFB529:
movdqa  (%rdi), %xmm0   # 6 *movv2di_internal/2 [length = 3]
movd%xmm0, %rax # 25*movdi_1_rex64/14   [length = 4]
ret # 28return_internal [length = 1]

This might be related to bug 32708 (and therefore have a similar fix?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661



[Bug c++/23472] [hammer] __attribute__((constructor)) called twice with -funit-at-a-time

2007-07-11 Thread matz at gcc dot gnu dot org


--- Comment #4 from matz at gcc dot gnu dot org  2007-07-11 15:37 ---
Nope.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23472



[Bug c/32728] g++: Internal error: Terminated (program cc1plus)

2007-07-11 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32728



[Bug c/32728] New: g++: Internal error: Terminated (program cc1plus)

2007-07-11 Thread sn4jc at yahoo dot com
g++: Internal error: Terminated (program cc1plus)
Please submit a full bug report.
make[4]: *** [sql_yacc.o] Error 1
make[4]: Leaving directory `/usr/src/mysql-5.0.41/sql'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/usr/src/mysql-5.0.41/sql'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/src/mysql-5.0.41/sql'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/usr/src/mysql-5.0.41'
make: *** [install] Error 2


-- 
   Summary: g++: Internal error: Terminated (program cc1plus)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sn4jc at yahoo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32728



[Bug middle-end/32729] New: Loop unrolling not performed with large constant loop bound

2007-07-11 Thread scovich at gmail dot com
Consider the following functions:

// g++ -mtune=core2 -O3 -S -dp
void loop(int* dest, int* src, int count) {
  for(int i=0; i  count; i++)
dest[i] = src[i];
}
void loop_few(int* dest, int* src) { loop(dest, src, 8); }
void loop_many(int* dest, int* src) { loop(dest, src, 64); }

loop() unrolls 8x, as expected. loop_few() peels completely, as expected.
However, loop_many() neither peels nor unrolls. 

_Z9loop_manyPiS_:
xorl%edx, %edx  # 34*movdi_xor_rex64[length = 2]
.L47:
movl(%rsi,%rdx,4), %eax # 11*movsi_1/1  [length = 3]
movl%eax, (%rdi,%rdx,4) # 12*movsi_1/2  [length = 3]
incq%rdx# 13*adddi_1_rex64/1[length = 3]
cmpq$64, %rdx   # 15cmpdi_1_insn_rex64/1[length = 4]
jne .L47# 16*jcc_1  [length = 2]
rep ; ret   # 35return_internal_long[length = 1]

Ideally the optimizer would unroll 8x, then notice that (count%8==0) and
eliminate the partial unroll code. However, even a stock unroll would be better
than nothing.


-- 
   Summary: Loop unrolling not performed with large constant loop
bound
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729



[Bug middle-end/32729] Loop unrolling not performed with large constant loop bound

2007-07-11 Thread scovich at gmail dot com


--- Comment #1 from scovich at gmail dot com  2007-07-11 16:36 ---
(In reply to comment #0)
 // g++ -mtune=core2 -O3 -S -dp
Oops... that doesn't actually unroll loop() all, though it still peels
loop_few().

Adding -funroll-loops (supposedly enabled by -O3?) unrolls loop()
Adding -funroll-all-loops does nothing

Nested loops also have issues:

void nested_loop(int* dest, int* src) {
  for(int i=0; i  2; i++)
for(int j=0; j  2; j++)
  dest[4*i+j] = src[4*j+i];
}

becomes

_Z11nested_loopPiS_:
.LFB533:
xorl%edx, %edx  # 39*movdi_xor_rex64[length = 2]
.L47:
movl(%rsi), %ecx# 13*movsi_1/1  [length = 2]
movl%ecx, (%rdi,%rdx,4) # 14*movsi_1/2  [length = 3]
movl16(%rsi), %eax  # 15*movsi_1/1  [length = 3]
addq$4, %rsi# 17*adddi_1_rex64/1[length = 4]
movl%eax, 4(%rdi,%rdx,4)# 16*movsi_1/2  [length = 4]
addq$4, %rdx# 18*adddi_1_rex64/1[length = 4]
cmpq$8, %rdx# 20cmpdi_1_insn_rex64/1[length = 4]
jne .L47# 21*jcc_1  [length = 2]
rep ; ret   # 40return_internal_long[length = 1]


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729



[Bug middle-end/32729] Regression: Loop unrolling not performed with large constant loop bound

2007-07-11 Thread scovich at gmail dot com


--- Comment #2 from scovich at gmail dot com  2007-07-11 16:37 ---
Regression: gcc-4.1.2 outputs the expected code for all test cases


-- 

scovich at gmail dot com changed:

   What|Removed |Added

Summary|Loop unrolling not performed|Regression: Loop unrolling
   |with large constant loop|not performed with large
   |bound   |constant loop bound


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729



[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8

2007-07-11 Thread kargl at gcc dot gnu dot org


--- Comment #12 from kargl at gcc dot gnu dot org  2007-07-11 17:01 ---
(In reply to comment #11)
 
 We need to make a choice between these two, and decided whether all arguments
 have the same type (my preferred choice) or if some have a fixed type. In all
 cases, uses of MVBITS with different mixed kinds should be audited, for there
 might be a few other inconsistencies lurking here.
 

FROM and TO are integer and these must have the same kind type parameter.
The other arguments are simply specified to be of type integer.  However,
these are restricted by BITSIZE(FROM).  INTEGER*4 is clearly large enough.
So, we could walk the argument in iresolve.c(gfc_resolve_mvbits) and
forcefully convert the remaining args to INTEGER*4.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357



[Bug tree-optimization/32720] No coalesce ssa_names

2007-07-11 Thread rosana07a at gmail dot com


--- Comment #8 from rosana07a at gmail dot com  2007-07-11 17:32 ---
Works with 4.2.1 ' making this a regression

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu
--disable-nls --disable-checking --disable-werror --disable-multilib
--disable-libunwind-exceptions --disable-decimal-float --enable-shared
--enable-threads=posix --enable-bootstrap --enable-__cxa_atexit
--enable-libgcc-math --enable-languages=c,c++,fortran --with-cpu=pentium3
--with-system-zlib --enable-clocale=gnu
Thread model: posix
gcc version 4.2.1 20070704 (prerelease)
 /usr/libexec/gcc/i686-pc-linux-gnu/4.2.1/f951 lexlin.f90 -quiet -dumpbase
lexlin.f90 -mtune=pentium3 -auxbase lexlin -O2 -version -I
/usr/lib/gcc/i686-pc-linux-gnu/4.2.1/finclude -o lexlin.s
GNU F95 version 4.2.1 20070704 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.2.1 20070704 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /usr/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o lexlin.o lexlin.s
GNU assembler version 2.17.50.0.16 (i686-pc-linux-gnu) using BFD version
(Linux/GNU Binutils) 2.17.50.0.16.20070511


-- 

rosana07a at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.3.0
  Known to work||4.2.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720



[Bug c++/32108] [4.2/4.3 regression] ICE with __label__ outside of block scope

2007-07-11 Thread pcarlini at suse dot de


--- Comment #2 from pcarlini at suse dot de  2007-07-11 18:00 ---
Yes, seems doable.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32108



[Bug c++/32730] New: std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com
string.find returns results when it should not:

x=4294967295 Found:a test
x=4294967294 Found:a test
x=4294967293 Found:a test
x=4294967292 Not found
x=4294967291 Not found
x=4294967290 Not found
x=4294967289 Not found
x=4294967288 Not found
x=4294967287 Not found
x=4294967286 Not found

Also happens on gcc4.1.2 FreeBSD gcc2.95.2 Unixware 7.1 and gcc4.1.1 Linux 64


[~]$ g++ -v --save-temps -Wall -ansi -pedantic str3.cpp
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
 /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE
str3.cpp -mtune=generic -ansi -Wall -pedantic -fpch-preprocess -o str3.ii
ignoring nonexistent directory
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../i386-redhat-linux/include
#include ... search starts here:
#include ... search starts here:
 /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1

/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/i386-redhat-linux
 /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../include/c++/4.1.1/backward
 /usr/local/include
 /usr/lib/gcc/i386-redhat-linux/4.1.1/include
 /usr/include
End of search list.
 /usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1plus -fpreprocessed str3.ii -quiet
-dumpbase str3.cpp -mtune=generic -ansi -auxbase str3 -Wall -pedantic -ansi
-version -o str3.s
GNU C++ version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux)
compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa6f91b930c2d3bef702d56afc079b20
 as -V -Qy -o str3.o str3.s
GNU assembler version 2.17.50.0.6-2.el5 (i386-redhat-linux) using BFD version
2.17.50.0.6-2.el5 20061020
 /usr/libexec/gcc/i386-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m elf_i386
--hash-style=gnu -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1
-L/usr/lib/gcc/i386-redhat-linux/4.1.1/../../.. str3.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i386-redhat-linux/4.1.1/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crtn.o

#include iostream
#include string
#include climits

int main(int argc, char *argv[])
{
   std::string a(this is a test);

   std::string b(a t);

   for(unsigned long x=ULONG_MAX; xULONG_MAX-10; --x)
   {
  std::string::size_type y=a.find(b, x);

  if(y==std::string::npos)
  {
 std::cout  x=  x   Not found\n;
  }
  else
  {
 std::cout  x=  x   Found:  a.substr(y)  std::endl;
  }
   }

   return 0;
}


-- 
   Summary: std::string.find(x, std::string::npos) searchs from
begining of string
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730



[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com


--- Comment #1 from gnu at bluedreamer dot com  2007-07-11 18:10 ---
Created an attachment (id=13887)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13887action=view)
Source file

Example source that causes bug


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730



[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com


--- Comment #2 from gnu at bluedreamer dot com  2007-07-11 18:11 ---
Created an attachment (id=13888)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13888action=view)
From --save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730



[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread gnu at bluedreamer dot com


--- Comment #3 from gnu at bluedreamer dot com  2007-07-11 18:11 ---
Created an attachment (id=13889)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13889action=view)
From --save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730



[Bug libstdc++/31401] string find behaves strange when searching from npos

2007-07-11 Thread pcarlini at suse dot de


--- Comment #7 from pcarlini at suse dot de  2007-07-11 18:20 ---
*** Bug 32730 has been marked as a duplicate of this bug. ***


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 CC||gnu at bluedreamer dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401



[Bug c++/32730] std::string.find(x, std::string::npos) searchs from begining of string

2007-07-11 Thread pcarlini at suse dot de


--- Comment #4 from pcarlini at suse dot de  2007-07-11 18:20 ---


*** This bug has been marked as a duplicate of 31401 ***


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32730



[Bug libfortran/32731] New: pack/unpack with kind=1 or kind=2 mask

2007-07-11 Thread tkoenig at gcc dot gnu dot org
$ cat pack.f90 
program main
  real, dimension(2,2) :: a
  a = 0
  print *,pack(a,logical(a0,kind=1))
end program main
$ gfortran pack.f90  ./a.out
Fortran runtime error: Funny sized logical array
$ cat unpack.f90 
program main
  logical(kind=1),dimension(2,2) :: mask
  mask = .true.
  print *,unpack((/1,2,3,4/),mask,0)
end program main
$ gfortran unpack.f90  ./a.out
Fortran runtime error: Funny sized logical array


-- 
   Summary: pack/unpack with kind=1 or kind=2 mask
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731



[Bug libfortran/32731] pack/unpack with kind=1 or kind=2 mask

2007-07-11 Thread tkoenig at gcc dot gnu dot org


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-11 18:38:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731



[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args

2007-07-11 Thread uros at gcc dot gnu dot org


--- Comment #4 from uros at gcc dot gnu dot org  2007-07-11 18:43 ---
Subject: Bug 32661

Author: uros
Date: Wed Jul 11 18:42:44 2007
New Revision: 126557

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126557
Log:
PR target/32661
* config/i386/sse.md (*sse2_storeq_rex64): Handle 64bit mem-reg moves.
(*vec_extractv2di_1_sse2): Disable for TARGET_64BIT.
(*vec_extractv2di_1_rex64): New insn pattern.

testsuite/ChangeLog:

PR target/32661
* gcc.target/i386/pr32661-1.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr32661-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661



[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args

2007-07-11 Thread ubizjak at gmail dot com


--- Comment #5 from ubizjak at gmail dot com  2007-07-11 18:47 ---
(In reply to comment #3)

 This might be related to bug 32708 (and therefore have a similar fix?)

Yes, DImode moves are implemented/fixed by the patch above. Your example now
compiles to:

movq(%rdi), %rax
ret

Other examples are shown in
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01077.html.

SImode moves will be a bit harder, because shufps insn pattern is involved in
the vector expansion.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ubizjak at gmail dot com
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2007-
   ||07/msg01077.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-07-07 09:25:01 |2007-07-11 18:47:20
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661



[Bug rtl-optimization/32725] Unnecessary reg-reg moves

2007-07-11 Thread ubizjak at gmail dot com


--- Comment #2 from ubizjak at gmail dot com  2007-07-11 19:12 ---
This is due to reload. It is trying to solve following pattern

(insn:HI 25 24 28 2 pr32725.c:14 (parallel [
(set (reg:DI 75)
(and:DI (reg:DI 71)
(reg:DI 74)))
(clobber (reg:CC 17 flags))
]) 299 {*anddi_1_rex64} (expr_list:REG_DEAD (reg:DI 74)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

to following register constraints:

(define_insn *adddi_1_rex64
  [(set (match_operand:DI 0 nonimmediate_operand =r,rm,r)
(plus:DI (match_operand:DI 1 nonimmediate_operand %0,0,r)
 (match_operand:DI 2 x86_64_general_operand rme,re,le)))
   (clobber (reg:CC FLAGS_REG))]

But it produces following mess:

(insn 95 24 25 2 pr32725.c:14 (set (reg:DI 3 bx [75])
(reg:DI 0 ax [74])) 82 {*movdi_1_rex64} (nil))

(insn:HI 25 95 96 2 pr32725.c:14 (parallel [
(set (reg:DI 3 bx [75])
(and:DI (reg:DI 3 bx [75])
(reg:DI 37 r8 [71])))
(clobber (reg:CC 17 flags))
]) 299 {*anddi_1_rex64} (nil))

(insn 96 25 33 2 pr32725.c:14 (set (reg:DI 0 ax)
(reg:DI 3 bx [75])) 82 {*movdi_1_rex64} (nil))


Ideally, output reg should be matched to dead reg 74 (due to % modifier) and
this would fix the whole sequence.

Perhaps a reload expert will be interested in this PR ;)


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |rtl-optimization
 Ever Confirmed|0   |1
   Keywords||ra
   Last reconfirmed|-00-00 00:00:00 |2007-07-11 19:12:37
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725



[Bug rtl-optimization/21202] Extra register moves generated with long long

2007-07-11 Thread ubizjak at gmail dot com


--- Comment #5 from ubizjak at gmail dot com  2007-07-11 19:20 ---
Fixed in 4.3.0.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21202



[Bug rtl-optimization/32725] Unnecessary reg-reg moves

2007-07-11 Thread bonzini at gnu dot org


--- Comment #3 from bonzini at gnu dot org  2007-07-11 19:49 ---
First, I'm not a reload expert. :-)  But it does not look like a reload bug (or
at least it is easily worked around in the machine description, methinks). 

regmove should have changed that but it does not probably because the final
constraint does not have a duplicate operand.  Actually, I think you want to
look at anddi_1_rex64, not adddi_1_rex64:

  [(set (match_operand:DI 0 nonimmediate_operand =r,rm,r,r)
(and:DI (match_operand:DI 1 nonimmediate_operand %0,0,0,qm)
(match_operand:DI 2 x86_64_szext_general_operand
Z,re,rm,L)))
   (clobber (reg:CC FLAGS_REG))]

The final constraint is for when and is used to create a zero-extending moves
(L matches constants 0xFF and 0x).  I would say that you have to 1) define
a predicate which has the same behavior as L and 2) split that alternative out
of the three anddi patterns that use it (grep for '\L\') into a separate
insn.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725



[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-11 Thread ebotcazou at gcc dot gnu dot org


--- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-07-11 20:10 
---
 Can someone paste the output of debug_generic_stmt (to) and
 debug_tree(to) at the point of failure?

(gdb) p debug_tree(to)
 var_decl 0x557f7114 vn_top.181
type void_type 0x55716804 void sizes-gimplified visited VOID
align 8 symtab 0 alias set 36 canonical type 0x55716804
pointer_to_this pointer_type 0x55716870
used ignored VOID file ../c87b26b.adb line 4
align 8
$4 = void
(gdb) p debug_generic_stmt(to)
vn_top.181


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705



[Bug target/32661] __builtin_ia32_vec_ext suboptimal for pointer/ref args

2007-07-11 Thread scovich at gmail dot com


--- Comment #6 from scovich at gmail dot com  2007-07-11 20:27 ---
(In reply to comment #5)
 SImode moves will be a bit harder, because shufps insn pattern is involved in
 the vector expansion.

IIRC, shufps takes 3 cycles on Core2
(http://www.agner.org/optimize/instruction_tables.pdf), even without the
operand type mismatch (does that still exist?). That's =4 cycles.

Storing the vector to stack and load the desired entry would take =4 cycles,
even without Intel's store-load optimizations, and I imagine the optimizer
would be able to deal with it better.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32661



[Bug rtl-optimization/32725] Unnecessary reg-reg moves

2007-07-11 Thread rask at sygehus dot dk


--- Comment #4 from rask at sygehus dot dk  2007-07-11 20:45 ---
In reply to comment #2:
Reload is unable to use a register with a REG_DEAD note for an output reload.
Look at the functions find_reload_regs(), order_regs_for_reload() and
find_reg() and pay attention to how they use chain-dead_or_set and
bad_spill_regs. Several years ago, the reg sets chain-live_throughout and
chain-dead_or_set were instead chain-live_before and chain-live_after and it
would have been easy to fix something like this. I think.
But IMHO, this is something which local-alloc or global-alloc should get right
and not leave to reload.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725



[Bug middle-end/32729] Regression: Loop unrolling not performed with large constant loop bound

2007-07-11 Thread rakdver at gcc dot gnu dot org


--- Comment #3 from rakdver at gcc dot gnu dot org  2007-07-11 20:47 ---
Something c++ specific, when compiled by gcc, the loop is unrolled just fine.


-- 

rakdver at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-07-11 20:47:54
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729



[Bug middle-end/32729] Regression: Loop unrolling not performed with large constant loop bound

2007-07-11 Thread rakdver at gcc dot gnu dot org


--- Comment #4 from rakdver at gcc dot gnu dot org  2007-07-11 20:56 ---
The following patch fixes the problem; I am not quite sure why this check is
there.

Index: cfghooks.c
===
*** cfghooks.c  (revision 126547)
--- cfghooks.c  (working copy)
*** tidy_fallthru_edges (void)
*** 838,845 
  bool
  can_duplicate_block_p (basic_block bb)
  {
-   edge e;
-
if (!cfg_hooks-can_duplicate_block_p)
  internal_error (%s does not support can_duplicate_block_p,
cfg_hooks-name);
--- 838,843 
*** can_duplicate_block_p (basic_block bb)
*** 847,858 
if (bb == EXIT_BLOCK_PTR || bb == ENTRY_BLOCK_PTR)
  return false;

-   /* Duplicating fallthru block to exit would require adding a jump
-  and splitting the real last BB.  */
-   e = find_edge (bb, EXIT_BLOCK_PTR);
-   if (e  (e-flags  EDGE_FALLTHRU))
- return false;
-
return cfg_hooks-can_duplicate_block_p (bb);
  }

--- 845,850 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32729



[Bug fortran/32732] New: [Bind C] Character scalars are passed as arrays

2007-07-11 Thread burnus at gcc dot gnu dot org
|  subroutine foo(a) bind(c)
|character(len=1,kind=c_char), value :: a

Has a single, scalar argument a; in C notation:
| void foo(char a)

gfortran, however, uses
| void foo(char a[]) 
with length one.

This causes problems on IA-64 HP-UX, see thread starting at
http://gcc.gnu.org/ml/fortran/2007-07/msg00210.html

(If a is a scalar, one needs to audit also all character uses to make sure
that one does use it as such (and does not compile Fortran if(a /= 5) into C
if(*a != 5) as a is not a pointer.)



Additionally, If the function is called, the length is additionally passed to
the function:
| call foo(a)
produces:
| foo(a, 1) // 'a' array, not zero terminated
instead of
| foo('a')

As the length arguments come always last and are not used, this seems to be
harmless, but there might be platforms or scenarios where they may cause
problems.


-- 
   Summary: [Bind C] Character scalars are passed as arrays
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
OtherBugsDependingO 32630
 nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732



[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664

2007-07-11 Thread jaydub66 at gmail dot com


--- Comment #4 from jaydub66 at gmail dot com  2007-07-11 21:39 ---
Paul,
I tested your patch, and indeed it does fix the problem for me. I also checked
it for regressions, and it doesn't seem to break anthing.
Cheers,
Janus


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682



[Bug libfortran/32731] pack/unpack with kind=1 or kind=2 mask

2007-07-11 Thread tkoenig at gcc dot gnu dot org


--- Comment #1 from tkoenig at gcc dot gnu dot org  2007-07-11 21:41 ---
Created an attachment (id=13890)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13890action=view)
proposed patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32731



[Bug fortran/32035] 'anonymous' may be used uninitialized in this function

2007-07-11 Thread steven at gcc dot gnu dot org


--- Comment #7 from steven at gcc dot gnu dot org  2007-07-11 21:42 ---
The proposed patch (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01098.html)
breaks library compatibility. Is this intentional?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035



[Bug ada/32733] New: g-spipat.adb:1597: error: definition in block 11 does not dominate use in block 12

2007-07-11 Thread cato at df dot lth dot se
Ada (revision 126547) fails bootstrap on i386-unknown-netbsdelf3.1:
/gcctmp/agcc070711/build/./gcc/xgcc -B/gcctmp/agcc070711/build/./gcc/
-B/usr/local/i386-unknown-netbsdelf3.1/bin/
-B/usr/local/i386-unknown-netbsdelf3.1/lib/ -isystem
/usr/local/i386-unknown-netbsdelf3.1/include -isystem
/usr/local/i386-unknown-netbsdelf3.1/sys-include -c -g -O2  -W -Wall
-gnatpg  g-spipat.adb -o g-spipat.o
g-spipat.adb: In function 'GNAT.SPITBOL.PATTERNS.XMATCHD':
g-spipat.adb:1302: warning: 'anonymous' may be used uninitialized in this
function
g-spipat.adb:1302: note: 'anonymous' was declared here
g-spipat.adb:5221: warning: 'S' may be used uninitialized in this function
g-spipat.adb:5221: warning: 'GNAT.SPITBOL.PATTERNS.XMATCHD.L_70.T2464B' may be
used uninitialized in this function
g-spipat.adb:5002: warning: 'ASSIGN_ONM' may be used uninitialized in this
function
g-spipat.adb:4959: warning: 'LENGTH' may be used uninitialized in this function
g-spipat.adb:4955: warning: 'NODE' may be used uninitialized in this function
g-spipat.adb:1306: warning: 'STOP' may be used uninitialized in this function
g-spipat.adb:1306: note: 'STOP' was declared here
g-spipat.adb:1305: warning: 'START' may be used uninitialized in this function
g-spipat.adb:1305: note: 'START' was declared here
g-spipat.adb: In function 'GNAT.SPITBOL.PATTERNS.ALTERNATE':
g-spipat.adb:1597: error: definition in block 11 does not dominate use in block
12
for SSA_NAME: NMT.17854_68 in statement:
NMT.17854_209 = PHI NMT.17854_150(7), NMT.17854_68(8), NMT.17854_68(11),
NMT.17854_68(12)
PHI argument
NMT.17854_68
for PHI node
NMT.17854_209 = PHI NMT.17854_150(7), NMT.17854_68(8), NMT.17854_68(11),
NMT.17854_68(12)
+===GNAT BUG DETECTED==+
| 4.3.0 20070711 (experimental) (i386-unknown-netbsdelf3.1) GCC error: |
| verify_ssa failed|
| Error detected around g-spipat.adb:1597  |
[...]

 ./xgcc -B./ -v
Reading specs from ./specs
Target: i386-unknown-netbsdelf3.1
Configured with: ../gcc/configure --enable-languages=c,ada
Thread model: posix
gcc version 4.3.0 20070711 (experimental)

The source tree has the following patch applied to fix an unrelated bootstrap
problem on NetBSD:
   http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02159.html


-- 
   Summary: g-spipat.adb:1597: error: definition in block 11 does
not dominate use in block 12
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cato at df dot lth dot se
 GCC build triplet: i386-unknown-netbsdelf3.1
  GCC host triplet: i386-unknown-netbsdelf3.1
GCC target triplet: i386-unknown-netbsdelf3.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733



[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation

2007-07-11 Thread paolo at gcc dot gnu dot org


--- Comment #7 from paolo at gcc dot gnu dot org  2007-07-11 21:52 ---
Subject: Bug 31027

Author: paolo
Date: Wed Jul 11 21:52:04 2007
New Revision: 126558

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126558
Log:
2007-07-11  Paolo Carlini  [EMAIL PROTECTED]

PR c++/31027
* g++.dg/inherit/virtual4.C: New.

Added:
trunk/gcc/testsuite/g++.dg/inherit/virtual4.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027



[Bug fortran/32035] 'anonymous' may be used uninitialized in this function

2007-07-11 Thread fxcoudert at gcc dot gnu dot org


--- Comment #8 from fxcoudert at gcc dot gnu dot org  2007-07-11 21:54 
---
I think it was decided that until 4.3 is released, we don't care about
libgfortran ABI stability
(http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00927.html)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035



[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation

2007-07-11 Thread paolo at gcc dot gnu dot org


--- Comment #8 from paolo at gcc dot gnu dot org  2007-07-11 21:54 ---
Subject: Bug 31027

Author: paolo
Date: Wed Jul 11 21:54:36 2007
New Revision: 126559

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126559
Log:
2007-07-11  Paolo Carlini  [EMAIL PROTECTED]

PR c++/31027
* g++.dg/inherit/virtual4.C: New.

Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/virtual4.C
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027



[Bug c++/31027] [4.1 regression] Compiler segfaults in simple virtual inheritance situation

2007-07-11 Thread pcarlini at suse dot de


--- Comment #9 from pcarlini at suse dot de  2007-07-11 21:56 ---
Doesn't fail anymore in mainline and 4_2-branch.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

Summary|[4.1/4.2/4.3 regression]|[4.1 regression] Compiler
   |Compiler segfaults in simple|segfaults in simple virtual
   |virtual inheritance |inheritance situation
   |situation   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027



Re: [Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-11 Thread Daniel Berlin

The only way i can see this happening is if you have a truly
uninitialized variable, or there is something we have missed.

Does this function have cfun-static_chain_decl being used, and we
have a copy of that here?

It is theoretically safe to call set_ssa_to_val with to == vn_top, but
it's probably a bug somewhere, and i'd rather eliminate the bug cases
before turning it off.

On 11 Jul 2007 20:10:10 -, ebotcazou at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:



--- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-07-11 20:10 
---
 Can someone paste the output of debug_generic_stmt (to) and
 debug_tree(to) at the point of failure?

(gdb) p debug_tree(to)
 var_decl 0x557f7114 vn_top.181
type void_type 0x55716804 void sizes-gimplified visited VOID
align 8 symtab 0 alias set 36 canonical type 0x55716804
pointer_to_this pointer_type 0x55716870
used ignored VOID file ../c87b26b.adb line 4
align 8
$4 = void
(gdb) p debug_generic_stmt(to)
vn_top.181


--


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705




[Bug tree-optimization/32705] [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

2007-07-11 Thread dberlin at dberlin dot org


--- Comment #6 from dberlin at gcc dot gnu dot org  2007-07-11 22:20 ---
Subject: Re:  [4.3 regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022

The only way i can see this happening is if you have a truly
uninitialized variable, or there is something we have missed.

Does this function have cfun-static_chain_decl being used, and we
have a copy of that here?

It is theoretically safe to call set_ssa_to_val with to == vn_top, but
it's probably a bug somewhere, and i'd rather eliminate the bug cases
before turning it off.

On 11 Jul 2007 20:10:10 -, ebotcazou at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:


 --- Comment #5 from ebotcazou at gcc dot gnu dot org  2007-07-11 20:10 
 ---
  Can someone paste the output of debug_generic_stmt (to) and
  debug_tree(to) at the point of failure?

 (gdb) p debug_tree(to)
  var_decl 0x557f7114 vn_top.181
 type void_type 0x55716804 void sizes-gimplified visited VOID
 align 8 symtab 0 alias set 36 canonical type 0x55716804
 pointer_to_this pointer_type 0x55716870
 used ignored VOID file ../c87b26b.adb line 4
 align 8
 $4 = void
 (gdb) p debug_generic_stmt(to)
 vn_top.181


 --


 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705



[Bug c++/32106] [4.3 regression] ICE after name-clash between struct and namespace

2007-07-11 Thread reichelt at gcc dot gnu dot org


--- Comment #2 from reichelt at gcc dot gnu dot org  2007-07-11 22:21 
---
Just for the record:
The bug disappeared between 2007-06-23 and 2007-07-02.

I'd guess this was fixed by

2007-07-01  Ollie Wild  [EMAIL PROTECTED]

* name-lookup.c (ambiguous_decl): Fix case when new-value is hidden.
(select_decl): Remove function.
(unqualified_namespace_lookup): Populate binding by calling
ambiguous_decl.  Remove select_decl call.
(lookup_qualified_name): Remove select_decl call.
* decl.c (lookup_and_check_tag): Check for ambiguous references.
* parser.c (cp_parser_elaborated_type_specifier): Skip redundant error
generation when name lookup is ambiguous.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106



[Bug tree-optimization/19910] [4.2/4.3 regression] ICE with -ftree-loop-linear

2007-07-11 Thread reichelt at gcc dot gnu dot org


--- Comment #14 from reichelt at gcc dot gnu dot org  2007-07-11 22:28 
---
Btw, the bug disappeared on mainline between 2007-05-13 and 2007-05-26.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910



[Bug c++/32106] [4.3 regression] ICE after name-clash between struct and namespace

2007-07-11 Thread pcarlini at suse dot de


--- Comment #3 from pcarlini at suse dot de  2007-07-11 22:37 ---
Thanks Volker.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32106



[Bug c++/32232] [4.1 Regression] ICE in resolve_overloaded_unification

2007-07-11 Thread reichelt at gcc dot gnu dot org


--- Comment #6 from reichelt at gcc dot gnu dot org  2007-07-11 23:04 
---
Mark, I don't think the fix for this PR is complete, because the following
simplified testcase (which previously ICE'd) should compile IMHO:

=
templatetypename struct A
{
  A operator(void (*)(A));
};

templatetypename T AT operator(AT, const AT);

templatetypename T void foo(AT);

void bar()
{
  Aint()  (1, fooint);
}
=

But it is rejected with the following error message:

bug.cc: In function 'void bar()':
bug.cc:12: error: no match for 'operator' in 'Aint()  (0, fooint)'
bug.cc:3: note: candidates are: A template-parameter-1-1  A
template-parameter-1-1 ::operator(void (*)(A template-parameter-1-1
)) [with template-parameter-1-1 = int]

An even smaller testcase for this problem is the following:

=
struct A
{
  A operator(void (*)(A));
};

templatetypename void foo(A);

void bar()
{
  A()  (1, fooint);
}
=

bug.cc: In function 'void bar()':
bug.cc:10: error: no match for 'operator' in 'A()  (0, fooint)'
bug.cc:3: note: candidates are: A A::operator(void (*)(A))

The code compiles fine, if I remove the 0,.

Btw, there's another glitch in the error message:
The code contains (1, fooint), which is printed as (0, fooint)
in the error message.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232



[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations

2007-07-11 Thread dougkwan at google dot com


--- Comment #4 from dougkwan at google dot com  2007-07-11 23:15 ---
Created an attachment (id=13891)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13891action=view)
Patch for fixing byte swap optimization.

I have tested this patch on i486-linux-gnu (C/C++ test suite only, full
bootstrap to be done). The problem was reported on m68k initially but I checked
that it also appeared on i486. The patched have been tested to work on
i486-linux-gnu and powerpc64-unknown-linux-gnu.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749



  1   2   >