[Bug bootstrap/6669] Irix6.5 ada bootstrap fail in ada/targparm.adb

[steven at gcc dot gnu dot org]

--- Comment #22 from steven at gcc dot gnu dot org  2008-02-12 07:10 ---
Zap.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WONTFIX


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

[Bug debug/31412] inf loop/long compile time, time spent in var-tracking.c

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2008-02-12 06:44 ---
PR 35065 has a testcase that exhibits this same bug in the current pre-4.3.0
sources.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||35065
  nThis||
 Status|WAITING |NEW
   Last reconfirmed|2007-04-03 13:24:54 |2008-02-12 06:44:30
   date||


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

[Bug c++/35097] [4.3 regression] ICE with attribute and template specialization

[jason at gcc dot gnu dot org]

--- Comment #3 from jason at gcc dot gnu dot org  2008-02-12 06:42 ---
Fixed.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway

[jason at gcc dot gnu dot org]

--- Comment #17 from jason at gcc dot gnu dot org  2008-02-12 06:41 ---
Fixed for 4.3.0 and 4.2.4.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/33916] [4.2 Regression] Default constructor fails to initialize array members

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2008-02-12 06:41 ---
Fixed for 4.2.4 by reverting part of Mark's patch for PR 29039.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/29039] [4.0/4.1 Regression] implicitly defined constructor for class with reference member

[jason at gcc dot gnu dot org]

--- Comment #6 from jason at gcc dot gnu dot org  2008-02-12 06:39 ---
I reverted Mark's patch for 4.2.4 because it caused PR 33916.  This bug is
fixed in 4.3.0 by the patch for 33916, which seems too complex to risk
backporting.


-- 


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

[Bug c++/29039] [4.0/4.1 Regression] implicitly defined constructor for class with reference member

[jason at gcc dot gnu dot org]

--- Comment #5 from jason at gcc dot gnu dot org  2008-02-12 06:38 ---
Subject: Bug 29039

Author: jason
Date: Tue Feb 12 06:37:34 2008
New Revision: 132254

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132254
Log:
PR c++/34094
* decl2.c (cp_write_global_declarations): Don't write out static
data members with DECL_IN_AGGR_P set.

PR c++/33916
* Revert:
2006-10-17  Mark Mitchell  <[EMAIL PROTECTED]>
PR c++/29039
* typeck2.c (build_functional_cast): Don't zero-initialize
non-PODs; instead, call their constructors.

Removed:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/init/ctor8.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/decl2.c
branches/gcc-4_2-branch/gcc/cp/typeck2.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/33916] [4.2 Regression] Default constructor fails to initialize array members

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2008-02-12 06:38 ---
Subject: Bug 33916

Author: jason
Date: Tue Feb 12 06:37:34 2008
New Revision: 132254

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132254
Log:
PR c++/34094
* decl2.c (cp_write_global_declarations): Don't write out static
data members with DECL_IN_AGGR_P set.

PR c++/33916
* Revert:
2006-10-17  Mark Mitchell  <[EMAIL PROTECTED]>
PR c++/29039
* typeck2.c (build_functional_cast): Don't zero-initialize
non-PODs; instead, call their constructors.

Removed:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/init/ctor8.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/decl2.c
branches/gcc-4_2-branch/gcc/cp/typeck2.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/34094] [4.2/4.3 Regression] Undefined static data member in anonymous namespace can acquire a definition anyway

[jason at gcc dot gnu dot org]

--- Comment #16 from jason at gcc dot gnu dot org  2008-02-12 06:38 ---
Subject: Bug 34094

Author: jason
Date: Tue Feb 12 06:37:34 2008
New Revision: 132254

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132254
Log:
PR c++/34094
* decl2.c (cp_write_global_declarations): Don't write out static
data members with DECL_IN_AGGR_P set.

PR c++/33916
* Revert:
2006-10-17  Mark Mitchell  <[EMAIL PROTECTED]>
PR c++/29039
* typeck2.c (build_functional_cast): Don't zero-initialize
non-PODs; instead, call their constructors.

Removed:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/init/ctor8.C
Modified:
branches/gcc-4_2-branch/gcc/cp/ChangeLog
branches/gcc-4_2-branch/gcc/cp/decl2.c
branches/gcc-4_2-branch/gcc/cp/typeck2.c
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35097] [4.3 regression] ICE with attribute and template specialization

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2008-02-12 06:35 ---
Subject: Bug 35097

Author: jason
Date: Tue Feb 12 06:34:59 2008
New Revision: 132253

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132253
Log:
PR c++/35097
* pt.c (tsubst): Don't look up a template typedef in an explicit
specialization.

Added:
trunk/gcc/testsuite/g++.dg/ext/attrib31.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c


-- 


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

[Bug c++/35167] Problem with non-type template parameter and name lookup in template.

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2008-02-12 06:26 ---
Not a bug: The name of a member (static or not) without class qualification
can not be used in an address-of expression or decay to a pointer as 
desired in the current context:

5.19/2:
  Other expressions are considered  constant-expressions  only  for  the
  purpose  of non-local static object initialization
  (_basic.start.init_).  Such constant expressions shall evaluate to one
  of the following:
  --  a null pointer value (_conv.ptr_),
  --  a null member pointer value (_conv.mem_),
  --  an arithmetic constant expression,
  --  an address constant expression,
  [...]

5.19/4
  An address constant expression is a pointer to an  lvalue  designating
  an object of static storage duration, a string literal (_lex.string_),
  or a function.  The pointer shall be  created  explicitly,  using  the
  unary & operator, or implicitly using a non-type template parameter of
  pointer type, or  using  an  expression  of  array  (_conv.array_)  or
  function  (_conv.func_)  type.

5.3.1/2
  The result of the unary & operator is a pointer to its  operand.   The
  operand  shall  be an lvalue or a qualified-id.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/35097] [4.3 regression] ICE with attribute and template specialization

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-06 12:23:46 |2008-02-12 04:32:50
   date||


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

[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3

[bugzilla-gcc at thewrittenword dot com]

--- Comment #2 from bugzilla-gcc at thewrittenword dot com  2008-02-12 
03:52 ---
(In reply to comment #1)
> ld is running at this time so I doubt this is a GCC bug.

The Pid it is referring to ("Pid 18929 received a SIGSEGV for stack growth
failure.") is /opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc. I ran the command
under tusc (similar to truss(1) on Solaris or strace(1) on Redhat) and there is
no call to ld.


-- 


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

[Bug bootstrap/6669] Irix6.5 ada bootstrap fail in ada/targparm.adb

[david dot billinghurst at riotinto dot com]

--- Comment #21 from david dot billinghurst at riotinto dot com  2008-02-12 
02:48 ---
Subject: RE:  Irix6.5 ada bootstrap fail in ada/targparm.adb

I no longer have a mips-sgi-irix server or have any interest in this
bug.  I am happy for it to be closed.


NOTICE
This e-mail and any attachments are private and confidential and may contain
privileged information. If you are not an authorised recipient, the copying or
distribution of this e-mail and any attachments is prohibited and you must not
read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.


-- 


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

[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.

[nightstrike at gmail dot com]

--- Comment #1 from nightstrike at gmail dot com  2008-02-12 02:39 ---
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00350.html


-- 


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

[Bug middle-end/35170] Suspected value range propagation [VRP] failure with ? :

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-12 01:54 ---
> /tmp/message.c:24: warning: control reaches end of non-void function

this warning happens before VRP anyways.

This is related to PR 14495 (or really the same).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
  GCC build triplet| x86_64-unknown-linux-gnu   |x86_64-unknown-linux-gnu
   GCC host triplet| x86_64-unknown-linux-gnu   |x86_64-unknown-linux-gnu
 GCC target triplet| x86_64-unknown-linux-gnu   |x86_64-unknown-linux-gnu


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

[Bug c/35170] New: Suspected value range propagation [VRP] failure with ? :

[dps at simpson dot demon dot co dot uk]

There is at least one simple case that the value range deduction apparently
fails to cover. The compiler generates a message about control reaching
possibly the end of a non-void function given the source file:

#include 

int ns_strcmp(const char *a, const char *b)
{
int i;
i= (a==NULL) ? 0 : 1;
i |= (b==NULL) ? 0 : 2;
switch(i)
{
case 0: /* a=NULL, b=NULL */
return 0;   /* a=b */
/* NOT REACHED */
case 1: /* a=NULL, b!=NULL */
return -1;  /* ab */
/* NOT REACHED */
case 3: /* a!=NULL, b!=NULL */
return strcmp(a, b);/* Use strcmp */
/* NOT REACHED */
}
/* NOT REACHED */
}

Reaching the end of the function is clearly impossible because i must be 0, 1
after  i=(a==NULL) ? 0 : 1 and 0, 1, 2, 3 or after the i |= (b==NULL) ? 0 : 2.
It would be nice if value range propagation could deduce that i>=0 and i<=3,
after which it would be sufficient to notice that all the possible values are
covered in the switch to deduce that the control can not reach beyond the
switch.

However gcc seems to miss this fact, even with -O3, and the generated assembly
seems to include coverage of both i<0 and i>3. Replacing |= with += does not
eliminate the warning about control possibly reaching the end of a non-void
function.

It would be even nicer if I could replace 2 with 4 and adjust the case values
accordingly and still not get a warning but that would require propagation of
more than a single value range. My processor is an AMD Athlon(tm) 64 X2 Dual
Core Processor 4400+, although I suspect the logic that misses the relevant
information is target independent.

I can avoid the warning by handling the last case after the switch.

host$ Linux dps 2.6.24 #9 SMP PREEMPT Sat Feb 2 18:17:42 GMT 2008 x86_64
GNU/Linux
host$ gcc --version
gcc (GCC) 4.3.0 20080209 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

host$ gcc -c -O3 -Wall /tmp/message.c  
/tmp/message.c: In function ‘ns_strcmp’:
/tmp/message.c:24: warning: control reaches end of non-void function


-- 
   Summary: Suspected value range propagation [VRP] failure with ? :
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dps at simpson dot demon dot co dot uk
 GCC build triplet:  x86_64-unknown-linux-gnu
  GCC host triplet:  x86_64-unknown-linux-gnu
GCC target triplet:  x86_64-unknown-linux-gnu


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

[Bug target/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-02-12 01:37 ---
(In reply to comment #4)
> We fixed the mmintrin.h issues by using inline when __GNUC_STDC_INLINE__, and
> static inline otherwise in our tree.

The other way is to use the gnu_inline attribute always which case I am turning
this into a target issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |target
  GCC build triplet|i686-apple-darwin9  |
   GCC host triplet|i686-apple-darwin9  |
 GCC target triplet|i686-apple-darwin9  |i?86-*-*


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

[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-02-12 01:36 ---
ld is running at this time so I doubt this is a GCC bug.


-- 


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

[Bug target/34526] no-altivec ABI should be fixed or no longer be the default

[janis at gcc dot gnu dot org]

--- Comment #10 from janis at gcc dot gnu dot org  2008-02-12 01:35 ---
I'm still plugging away at this since I keep thinking of more things I might
have broken.  I've got some good new tests for the testsuite now that check how
arguments and return values are actually passed for powerpc64-linux -m32 and
-m64.  I also have little tests, not for the testsuite, to check that I haven't
broken argument and return passing for AIX and Darwin by comparing generated
assembly with and without my patch.  For those I've only tried 32-bit code and
need to find out how to configure to build a cross cc1 for 64-bit code.  There
are lots of other powerpc targets I'd like to check; any suggestions for target
triples for which to build cross cc1?


-- 


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

[Bug c/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[mrs at apple dot com]

--- Comment #4 from mrs at apple dot com  2008-02-12 01:28 ---
We fixed the mmintrin.h issues by using inline when __GNUC_STDC_INLINE__, and
static inline otherwise in our tree.


-- 


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

[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[alexandre dot nunes at gmail dot com]

--- Comment #7 from alexandre dot nunes at gmail dot com  2008-02-12 00:45 
---
> It is not what you think it is. ;)
> 
> movl%edx, -536821760
> 
> means:
> 
> (set (mem:SI (const_int -536821760 [0xe000c000]))(reg/v:SI 1 dx))
> 
> IOW, put %edx to constant address.
> 

It actually makes sense, this arch has no spare registers to play with :-)


-- 


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

[Bug tree-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360

[alexandre dot nunes at gmail dot com]

--- Comment #33 from alexandre dot nunes at gmail dot com  2008-02-12 00:32 
---
I compiled gcc 4.3 for arm-unknown-elf (today's trunk, not sure about the rev).
Compiling three in three firmware images gave me size regressions with -Os;
with -O2, gcc 4.3 produces smaller code than 4.2.3:

# Increased about 3.1%
#nam gcc v  fl code size
img1 4.2.3 -Os 4786
img1 4.3.- -Os 4936


# Increased about 1.3%
img2 4.2.3 -Os 3372
img2 4.3.- -Os 3416


# Decreased (!) about 3,3%
img3 4.2.3 -O2  13892
img3 4.3.- -O2  13436

# Increased about 4,4%
img3 4.2.3 -Os  12348
img3 4.3.0 -Os  12892


-- 

alexandre dot nunes at gmail dot com changed:

   What|Removed |Added

 CC||alexandre dot nunes at gmail
   ||dot com


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

[Bug c++/9050] Can't explicitly specialize C++ constructor templates

[manu at gcc dot gnu dot org]

--- Comment #9 from manu at gcc dot gnu dot org  2008-02-11 23:43 ---
(In reply to comment #8)
> This bug is present in gcc 3.4.3. Was ever fixed or forgotten forever?

[EMAIL PROTECTED]:~$ ~/132202/build/gcc/cc1plus --version
GNU C++ (GCC) version 4.3.0 20080209 (experimental) [trunk revision 132202]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20080209 (experimental) [trunk revision
132202], GMP version 4.2.2, MPFR version 2.3.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

[EMAIL PROTECTED]:~$ ~/132202/build/gcc/cc1plus src/pr9050.C
 void Y::foo(T) [with T = bool] void Y::foo(T) [with T = int] Y::Y(T) [with T =
bool] Y::Y(T) [with T = bool] Y::Y(T) [with T = bool]
src/pr9050.C: At global scope:
src/pr9050.C:11: error: ‘Y’ is not a template
src/pr9050.C:11: error: expected unqualified-id before ‘int’
src/pr9050.C:11: error: expected `)' before ‘int’

Not fixed.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
   Last reconfirmed|2006-09-03 21:39:40 |2008-02-11 23:43:25
   date||


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

[Bug c++/35138] [4.3 Regression] g++ rejects valid code

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-02-11 23:11 ---
cp_parser_class_name since PR20293 errors unconditionally even during tentative
parse.  Mark, is there a way to get a silent tentative parse of the optional
nested name specifier plus typename?  Or is trying to parse it tentatively
as pseudo-dtor followed by parsing it as id-expression/member access if the
former just never going to work?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at gcc dot gnu dot org


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

[Bug target/35073] illegal opcode movw for mcu avr3

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2008-02-11 22:50 
---
You can also try the patch set for binutils 2.18 at the WinAVR project's CVS:
. Under the "patches" module.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||eric dot weddington at atmel
   ||dot com


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

[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-02-11 22:20 ---
(In reply to comment #5)
> I tested on i686 (-march=athlon-xp -O2) with gcc 4.3 revision 132072 (older
> than the one I tried at arm), and it seems to misbehave there.
> 
> I'm not sure tought of the implications, since that's a superscalar cpu and
> these things are too complicated to my mind, perhaps it's faster that way
> because of an eventual alignment, etc... But it seems buggy to me :-)

It is not what you think it is. ;)

movl%edx, -536821760

means:

(set (mem:SI (const_int -536821760 [0xe000c000]))(reg/v:SI 1 dx))

IOW, put %edx to constant address.


-- 


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

[Bug c++/9050] Can't explicitly specialize C++ constructor templates

[vlad dot sharanhovich at gmail dot com]

--- Comment #8 from vlad dot sharanhovich at gmail dot com  2008-02-11 
22:19 ---
This bug is present in gcc 3.4.3. Was ever fixed or forgotten forever?


-- 

vlad dot sharanhovich at gmail dot com changed:

   What|Removed |Added

 CC||vlad dot sharanhovich at
   ||gmail dot com


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

[Bug target/35071] bad instruction `do_itt eq'

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2008-02-11 21:40 ---

Perhaps Paul could provide some insight. :)

$ svn blame ieee754-df.S ieee754-df.S | grep do_itt
120408 pbrook   do_itt  eq
120408 pbrook   do_itt  eq


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pbrook at gcc dot gnu dot
   ||org


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

[Bug target/35071] bad instruction `do_itt eq'

[alexandre dot nunes at gmail dot com]

--- Comment #3 from alexandre dot nunes at gmail dot com  2008-02-11 21:34 
---
(In reply to comment #2)
> (In reply to comment #1)
> > I've seem the same error building for arm-elf. Perhaps I need a newer
> > (experimental) binutils?
> 
> Just a wild guess, could this be a typo?
> 
> [EMAIL PROTECTED] arm]$ grep do_itt *
> ieee754-df.S:   do_itt  eq
> ieee754-sf.S:   do_itt  eq
> 

I guessed the same and changed it, allowing it to compile. Whether or not
that's good, I don't know, but I'll keep the tree alive in the case I need to
recompile it :-)


-- 


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

[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[alexandre dot nunes at gmail dot com]

--- Comment #5 from alexandre dot nunes at gmail dot com  2008-02-11 21:31 
---
I tested on i686 (-march=athlon-xp -O2) with gcc 4.3 revision 132072 (older
than the one I tried at arm), and it seems to misbehave there.

I'm not sure tought of the implications, since that's a superscalar cpu and
these things are too complicated to my mind, perhaps it's faster that way
because of an eventual alignment, etc... But it seems buggy to me :-)


-- 


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

[Bug target/35071] bad instruction `do_itt eq'

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2008-02-11 21:23 ---
(In reply to comment #1)
> I've seem the same error building for arm-elf. Perhaps I need a newer
> (experimental) binutils?

Just a wild guess, could this be a typo?

[EMAIL PROTECTED] arm]$ grep do_itt *
ieee754-df.S:   do_itt  eq
ieee754-sf.S:   do_itt  eq

However, we have:

lib1funcs.asm:.macro do_it cond, suffix=""

and many references to "do_it" macro in asm sources.


-- 


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

[Bug middle-end/35141] ARM: Constant generation inside a loop: Missed optimization opportunity

[alexandre dot nunes at gmail dot com]

--- Comment #4 from alexandre dot nunes at gmail dot com  2008-02-11 21:10 
---
(In reply to comment #2)
> Also using a volatile pointer may prevent optimization, so don't use it if
> not strictly needed (or at least don't expect optimized code).
> 
> Can you try 4.3 as suggested?
> 

Ok, PR35071 was the only blocker. I did a bad thing in order to bypass it (it
only affected a non-default [for me] target on my multilib config) and get the
whole thing to compile, and the result is:


whatever:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr3, [r0, #0]@ zero_extendqisi2
cmp r3, #0
bxeqlr
mov r2, #-536870912
add r2, r2, #49152
.L3:
str r3, [r2, #0]
ldrbr3, [r0, #1]!   @ zero_extendqisi2
cmp r3, #0
bne .L3
bx  lr


... which seems correct to me. (my build was from svn trunk, current date
20080211, unknow revision number [my build system got rid of .svn subdirs]).


No chance of a 4.2.x backport ? :-)


-- 


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

[Bug bootstrap/35169] New: SIGSEGV for stack growth failure while building 4.2.3

[bugzilla-gcc at thewrittenword dot com]

I am attempting to build 4.2.3 on HP-UX 11.23/IA.
  $ bzip2 -dc gcc-4.2.3.tar.bz2 | tar xf -
  $ mkdir gcc-4.2.3-objdir
  $ cd gcc-4.2.3-objdir
  $ /opt/build/china/gcc423/ia64-hp-hpux11.23/bin/as -v
  GNU assembler version 2.18 (ia64-hp-hpux11.23) using BFD version (GNU
Binutils) 2.18
  $ CC=cc bash /opt/build/china/gcc-4.2.3/configure --with-included-gettext
--enable-shared --with-gnu-as
--with-as=/opt/build/china/gcc423/ia64-hp-hpux11.23/bin/as
--enable-languages="c"
  ...
  $ gmake bootstrap
  ...
/opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc
-B/opt/build/china/gcc-4.2.3-objdir/./gcc/ -B/usr/local/ia64-hp-hpux11.23/bin/
-B/usr/local/ia64-hp-hpux11.23/lib/ -isystem
/usr/local/ia64-hp-hpux11.23/include -isystem
/usr/local/ia64-hp-hpux11.23/sys-include -O2  -O2 -g  -DIN_GCC   
-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I/opt/build/china/gcc-4.2.3/gcc
-I/opt/build/china/gcc-4.2.3/gcc/ -I/opt/build/china/gcc-4.2.3/gcc/../include
-I./../intl -I/opt/build/china/gcc-4.2.3/gcc/../libcpp/include 
-I/opt/build/china/gcc-4.2.3/gcc/../libdecnumber -I../libdecnumber -DSHARED -c
/opt/build/china/gcc-4.2.3/gcc/config/floatunsitf.c -o libgcc/./floatunsitf_s.o
/opt/build/china/gcc-4.2.3/gcc/config/floatunsitf.c:8: warning: no previous
prototype for '__floatunsitf'
{ /usr/ccs/bin/nm -pg libgcc/./__divxf3_s.o libgcc/./__divdf3_s.o
libgcc/./__divsf3_s.o libgcc/./__divdi3_s.o libgcc/./__moddi3_s.o
libgcc/./__udivdi3_s.o libgcc/./__umoddi3_s.o libgcc/./__divsi3_s.o
libgcc/./__modsi3_s.o libgcc/./__udivsi3_s.o libgcc/./__umodsi3_s.o
libgcc/./__save_stack_nonlocal_s.o libgcc/./__nonlocal_goto_s.o
libgcc/./__restore_stack_nonlocal_s.o libgcc/./__trampoline_s.o
libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o
libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o
libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o
libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o
libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o
libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o
libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o
libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o
libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o
libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o
libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o
libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o
libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o
libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o
libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o
libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o
libgcc/./quadlib_s.o libgcc/./floatunsitf_s.o; echo %%; \
  cat /opt/build/china/gcc-4.2.3/gcc/config/ia64/libgcc-ia64.ver \
| sed -e '/^[   ]*#/d' \
  -e 's/^%\(if\|else\|elif\|endif\|define\)/#\1/' \
| /opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc
-B/opt/build/china/gcc-4.2.3-objdir/./gcc/ -B/usr/local/ia64-hp-hpux11.23/bin/
-B/usr/local/ia64-hp-hpux11.23/lib/ -isystem
/usr/local/ia64-hp-hpux11.23/include -isystem
/usr/local/ia64-hp-hpux11.23/sys-include -O2  -O2 -g  -DIN_GCC   
-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g 
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I/opt/build/china/gcc-4.2.3/gcc
-I/opt/build/china/gcc-4.2.3/gcc/ -I/opt/build/china/gcc-4.2.3/gcc/../include
-I./../intl -I/opt/build/china/gcc-4.2.3/gcc/../libcpp/include 
-I/opt/build/china/gcc-4.2.3/gcc/../libdecnumber -I../libdecnumber  -E
-xassembler-with-cpp -; \
} | awk -f /opt/build/china/gcc-4.2.3/gcc/mkmap-flat.awk  >
libgcc/./tmp-libgcc.map

Pid 18929 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz. 
mv 'libgcc/./tmp-libgcc.map' libgcc/./libgcc.map
/opt/build/china/gcc-4.2.3-objdir/./gcc/xgcc
-B/opt/build/china/gcc-4.2.3-objdir/./gcc/ -B/usr/local/ia64-hp-hpux11.23/bin/
-B/usr/local/ia64-hp-hpux11.23/lib/ -isystem
/usr/local/ia64-hp-hpux11.23/include -isystem
/usr/local/ia64-hp-hpux11.23/sys-include -O2  -O2 -g  -DIN_GCC   
-DUSE_LIBUNWIND_EXCEPTIONS -W -Wall -Wwrite-str

[Bug target/35071] bad instruction `do_itt eq'

[alexandre dot nunes at gmail dot com]

--- Comment #1 from alexandre dot nunes at gmail dot com  2008-02-11 20:12 
---
I've seem the same error building for arm-elf. Perhaps I need a newer
(experimental) binutils?


-- 


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

[Bug c/34000] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[lennox at cs dot columbia dot edu]

--- Comment #3 from lennox at cs dot columbia dot edu  2008-02-11 19:51 
---
A discussion on comp.std.c

indicates that this is indeed a constraint violation; the poster thinks that
system headers should be fixed.

I don't think it would be possible to write a fixincludes fix to turn static
inlines into GNU89 or C99 extern inlines, however, so I think suppressing the
pedwarn for system headers is the best option.


-- 

lennox at cs dot columbia dot edu changed:

   What|Removed |Added

Summary|GCC pedwarns about use of   |GCC pedwarns about use of
   |static inline functions in  |static inline functions from
   |extern inline functions |system headers in extern
   ||inline functions


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

[Bug target/35073] illegal opcode movw for mcu avr3

[Rudolf dot Leitgeb at gmx dot at]

--- Comment #6 from Rudolf dot Leitgeb at gmx dot at  2008-02-11 19:25 
---
I just tried the suggested patch against binutils 2.18, gcc 4.2.3 still does
not compile. Also, the suggested patch does not apply cleanly against 2.18,
although this only affects a .texi file which is not needed for compilation. It
does indicate, though, that the patch wa snot meant for binutils 2.18 but some
preversion of binutils 2.19 instead.

I hope this new version comes of binutils out soon, since 2.18 doesn't know of
a platform avr35 :-( Hence gcc 4.2.3 uses avr3 which causes touble.

Note: I don't fully understand why the patch doesn't work. I clearly see a line
which defines the AVR3 platform to support MOVW, I did a make clean && make &&
make install of the manually patched binutils before trying gcc again (also
with make clean && configure --target=avr && make)

Maybe I have to wait for binutils 2.19 before this gets cleared up ...


-- 


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

[Bug c++/35167] Problem with non-type template parameter and name lookup in template.

[v dot haisman at sh dot cvut dot cz]

--- Comment #1 from v dot haisman at sh dot cvut dot cz  2008-02-11 19:19 
---
Created an attachment (id=15131)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15131&action=view)
The test case.


-- 


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

[Bug c++/35167] New: Problem with non-type template parameter and name lookup in template.

[v dot haisman at sh dot cvut dot cz]

Hi, 
GCC 4.3 (4.3.0 20080201 (experimental) (GCC)) rejects the code with the
following error:

g++43 -W -Wall -o tt tt.cxx
tt.cxx:28: warning: unused parameter 'argv'
tt.cxx: In member function 'int Test::set(T) [with T = char]':
tt.cxx:31:   instantiated from here
tt.cxx:22: error: 'static void Test::Put(T&, const T&) [with T = char]'
cannot appear in a constant-expression

But Comeau's test drive accepts it with or without Test:: prefix.


-- 
   Summary: Problem with non-type template parameter and name lookup
in template.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: v dot haisman at sh dot cvut dot cz
 GCC build triplet: i386-portbld-freebsd6.3
  GCC host triplet: i386-portbld-freebsd6.3
GCC target triplet: i386-portbld-freebsd6.3


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[dgregor at gcc dot gnu dot org]

--- Comment #7 from dgregor at gcc dot gnu dot org  2008-02-11 18:59 ---
Fixed on mainline


-- 

dgregor at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/35113] [4.3 Regression] g++.dg/ext/vector13.C doesn't work

[dgregor at gcc dot gnu dot org]

--- Comment #6 from dgregor at gcc dot gnu dot org  2008-02-11 18:59 ---
Subject: Bug 35113

Author: dgregor
Date: Mon Feb 11 18:58:16 2008
New Revision: 132242

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132242
Log:
2008-02-11  Douglas Gregor  <[EMAIL PROTECTED]>

   PR c++/35113
   * tree.c (cp_build_qualified_type_real): When building a
   cv-qualified array type, build it as a unique type with
   build_cplus_array_type_1 and then adopt the unqualified type's
   main variant.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c


-- 


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

[Bug target/34780] Bootstrapping libstdc++-v3 failed

[hunor at cs dot bme dot hu]

--- Comment #7 from hunor at cs dot bme dot hu  2008-02-11 17:50 ---
I got the same error on i686-pc-linux-gnu with revision 132237. The -Werror is
indeed the result of --enable-maintainer-mode:

libstdc++-v3/acinclude.m4:
...
  if test x"$USE_MAINTAINER_MODE" = xno; then
WERROR=''
  else
WERROR='-Werror'
  fi
...

libstdc++-v3/fragment.am:
...
WARN_CXXFLAGS = \
$(WARN_FLAGS) $(WERROR) -fdiagnostics-show-location=once
...

libstdc++-v3/src/Makefile.am:
...
AM_CXXFLAGS = \
-fno-implicit-templates \
$(WARN_CXXFLAGS) \
$(OPTIMIZE_CXXFLAGS) \
$(CONFIG_CXXFLAGS)
...

libstdc++-v3/libsupc++/Makefile.am:
...
AM_CXXFLAGS = \
-fno-implicit-templates \
$(LIBSUPCXX_PICFLAGS) \
$(WARN_CXXFLAGS) \
$(OPTIMIZE_CXXFLAGS) \
$(CONFIG_CXXFLAGS)
...

Otherwise, the warning is correct:
gcc/unwind-pe.h:
...
static unsigned int
size_of_encoded_value (unsigned char encoding)
...

is indeed unused in libstdc++-v3/libsupc++/eh_call.cc. It should be static
inline or __attribute__((unused)), or alternatively
libstdc++-v3/libsupc++/eh_call.cc could define NO_SIZE_OF_ENCODED_VALUE before
including the header.


-- 

hunor at cs dot bme dot hu changed:

   What|Removed |Added

 CC||hunor at cs dot bme dot hu


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

[Bug target/35073] illegal opcode movw for mcu avr3

[Rudolf dot Leitgeb at gmx dot at]

--- Comment #5 from Rudolf dot Leitgeb at gmx dot at  2008-02-11 17:48 
---
Subject: Re:  illegal opcode movw for mcu avr3

Please note, that this bug is also apparent in the production
version of gcc 4.2.3. This is the specific reason why I posted
a supposed copy of the original bug report: the original bug
report mentioned version 4.3, and I was unable to add version 4.2.3
to the list of affected gcc releases.

Hopefully I can get around to try out the patch tonight. Please
note that while it's perfectly acceptable for a snapshot release
like gcc 4.3 to require patched binutils, this should not happen
for a standard release version of gcc IMHO. AFAIK there is no
binutils production release newer than 2.18 at the moment.

Cheers,

Rudi

Am 11.02.2008 um 18:17 schrieb corsepiu at gcc dot gnu dot org:

>
>
> --- Comment #4 from corsepiu at gcc dot gnu dot org  2008-02-11  
> 17:17 ---
> The binutils patch mentioned in comment#2 seems to fix this issue.
>
> Today's gcc-trunk using binutils-2.18 with the patch applied  
> doesn't expose
> this breakdown anymore.
>
> => The cause for this breakdown was using insufficient binutils.
>Bootstrapping/building gcc-4.3 for the avr requires binutils >  
> 2.18.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35073
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.


-- 


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

[Bug fortran/34143] alloc_comp_constructor.f90 fails with -fdefault-integer-8

[pault at gcc dot gnu dot org]

--- Comment #12 from pault at gcc dot gnu dot org  2008-02-11 17:48 ---
(In reply to comment #11)

OK I have a fix, up to a wrinkle that raises a standard question:

alloc_comp_constructor.f90 now compiles and runs OK but aborts because the
bounds are changed by the implicit conversion when -fdefault-integer-8 is used.

All that the standard says, as far as I can tell is that the descriptor be
copied.  In fact, Erik and I had temporaries renormalised to unity lbounds; I
am begining to think that this is incorrect.  If so, the bounds checks in the
testcase will fail, as they are doing with the implicit conversion.

Cheers

Paul


-- 


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

[Bug target/35073] illegal opcode movw for mcu avr3

[corsepiu at gcc dot gnu dot org]

--- Comment #4 from corsepiu at gcc dot gnu dot org  2008-02-11 17:17 
---
The binutils patch mentioned in comment#2 seems to fix this issue.

Today's gcc-trunk using binutils-2.18 with the patch applied doesn't expose
this breakdown anymore.

=> The cause for this breakdown was using insufficient binutils.
   Bootstrapping/building gcc-4.3 for the avr requires binutils > 2.18.


-- 


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

[Bug target/35073] illegal opcode movw for mcu avr3

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-02-11 16:44 ---
This seems confirmed


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-11 16:44:30
   date||


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

[Bug c++/35117] Vectorization on power PC

[dberlin at gcc dot gnu dot org]

--- Comment #29 from dberlin at gcc dot gnu dot org  2008-02-11 16:29 
---
Vectorization is not magic.
I'm also not sure where you got the idea that vectorization = magic speedup
There is no real "expected performance gain" on memory bound applications
because the processor spends all of it's time waiting on the memory subsystem,
not calculating things.


-- 


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

[Bug middle-end/35130] OpenMP: Private variable passed to subroutine

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
  Component|fortran |middle-end
   Last reconfirmed|2008-02-10 15:37:46 |2008-02-11 16:11:27
   date||


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

[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[schwab at suse dot de]

--- Comment #6 from schwab at suse dot de  2008-02-11 15:46 ---
The same change is causing an ICE on ia64.

internal compiler error: in rws_insn_set, at config/ia64/ia64.c:5336


-- 

schwab at suse dot de changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug c++/35159] g++ inoperable with no error message

[ktietz at gcc dot gnu dot org]

--- Comment #2 from ktietz at gcc dot gnu dot org  2008-02-11 14:57 ---
It is 4.3.0. I modified the bug report for that.

Cheers, Kai


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

Version|unknown |4.3.0


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

[Bug c++/35159] g++ inoperable with no error message

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-11 14:51 ---
which gcc version?


-- 


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

[Bug target/35073] illegal opcode movw for mcu avr3

[joel at gcc dot gnu dot org]

--- Comment #2 from joel at gcc dot gnu dot org  2008-02-11 14:49 ---
Sent privately... wanted to log this .. untested at this point.

Please excuse me, I could not reply earlier.

Use patch for binutils:
http://sourceware.org/ml/binutils/2008-01/msg00037.html

Anatoly.


-- 


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

[Bug ada/34469] Many ACATS failures not in 4.2.2 [regression]

[joel at gcc dot gnu dot org]

--- Comment #4 from joel at gcc dot gnu dot org  2008-02-11 14:47 ---
Better information on more current version in 35143

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


-- 

joel at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #17 from joel at gcc dot gnu dot org  2008-02-11 14:47 ---
*** Bug 34469 has been marked as a duplicate of this bug. ***


-- 


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

[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #16 from joel at gcc dot gnu dot org  2008-02-11 14:43 ---
ACATS Results for various combinations.  SPARC and PowerPC are the primary ones
we have tested on for years.  This was actually the first full set of automated
runs on i386 using qemu.  Suggestions on the high number of failures relative
to the other SPARC and PowerPC is appreciated.

SVN sparc-rtems4.9 -
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00732.html
SVN powerpc-rtems4.9 -
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00733.html
SVN i386-rtems4.9 - http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00730.html
4.2.3 powerpc-rtems4.9 -
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg00731.html


-- 


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

[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #15 from joel at gcc dot gnu dot org  2008-02-11 14:25 ---
ChangeLog entry for gcc-svn-ada-20080211.diff.  

2008-02-11  Joel Sherrill <[EMAIL PROTECTED]>

PR ada/35143
* env.c: Add __rtems__ to if defined.
* s-osinte-rtems.adb: Add To_Target_Priority.  Fix formatting.
* s-osinte-rtems.ads: Add To_Target_Priority prototype and
PTHREAD_SCOPE_PROCESS/PTHREAD_SCOPE_SYSTEM constants.  Add
pragma Convention as required.
* gsocket.h: Make compile in and out of RTS.
* Makefile.in: Add system-rtems.ads.  Build DEC extensions.
Use g-soccon-rtems.ads.
* g-soccon-rtems.ads, system-rtems.ads: New files.


-- 


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

[Bug ada/35143] [4.3 regression] Serious regression on ACATS results since 4.2.3

[joel at gcc dot gnu dot org]

--- Comment #14 from joel at gcc dot gnu dot org  2008-02-11 14:24 ---
Created an attachment (id=15130)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15130&action=view)
SVN RTEMS Patch

This patch greatly improves the results of the ACATS for SVN on PowerPC and
SPARC.  Please apply.


-- 


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

[Bug c++/35117] Vectorization on power PC

[victork at gcc dot gnu dot org]

--- Comment #28 from victork at gcc dot gnu dot org  2008-02-11 14:21 
---
>   As for the last email, Victor:
>   1. Using a smaller number of iterations, doesnt help me. This is not what 
> the
> real world code runs.

Looks like in your example the memory subsystem is a performance bottleneck.
Vectorization alone does not help. Probably you need to think how to partition
your arrays to fit the data cache.

>   2. new/malloc almost didnt do anything maybe a gain of 20%

With data allocated my malloc compiler is able to prove independence
statically. So, it would be better to alocate memory by malloc.

>   3. The difference between 1.738sec and 0.781sec can either be a 2 times
> performance gain or simply a 1 second gain that would remain 1 second for more
> intensive calculations. Therefore I cant use/rely on the test you did.

See an example in my previous comment. It is about 2.4 times performance gain.
-- Victor


-- 


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

[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-02-11 14:16 ---
Regression since http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128864


-- 


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

[Bug c++/35117] Vectorization on power PC

[eyal at geomage dot com]

--- Comment #27 from eyal at geomage dot com  2008-02-11 14:00 ---
Hi,
  I am a bit lost and appriciate your guidelines. Up till now, after all those
emails, I still have no clue as to why such a simple test case doesnt work. As
far as I understood the vectorization should have shown between 2 to 4 times
faster. With all the suggestions here I still didnt get more then 20-30%
performance gain. 
  I would appriciate if someone from the vectorization team could come up with
detailed explaination as to how to make the vectorization do whats promised. 

  As for the last email, Victor:
  1. Using a smaller number of iterations, doesnt help me. This is not what the
real world code runs.
  2. new/malloc almost didnt do anything maybe a gain of 20%
  3. The difference between 1.738sec and 0.781sec can either be a 2 times
performance gain or simply a 1 second gain that would remain 1 second for more
intensive calculations. Therefore I cant use/rely on the test you did.


-- 


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

[Bug c++/35117] Vectorization on power PC

[victork at gcc dot gnu dot org]

--- Comment #26 from victork at gcc dot gnu dot org  2008-02-11 13:41 
---
Probably, the small difference between vectorized and non-vectorized versions
can be explained by the fact that big arrays do not fit the memory cache.
Here is the version of the original program which shows that more than twice
difference is remained for long runs as well if arrays are decreased to fit the
cache:

#include 
#include 
#include 

typedef float ARRTYPE;
int main ( int argc, char *argv[] )
{
int m_nSamples = atoi( argv[1] );
int itBegin = atoi( argv[2] );
int itEnd = atoi( argv[3] );
int iSizeMain = atoi( argv[ 4 ] );
ARRTYPE *pSum1 = (ARRTYPE*) malloc (sizeof(ARRTYPE) *10);
ARRTYPE *pSum = (ARRTYPE*) malloc (sizeof(ARRTYPE) *10);
for ( int it = 0; it < 10; it++ )
{
pSum[ it ] = it / itBegin;
pSum1[ it ] = itBegin / ( it + 1 );
}
ARRTYPE *pVec1 = (ARRTYPE*) malloc (sizeof(ARRTYPE) *10);

for ( int i = 0, j = 0; i < m_nSamples - 5; i++ )
{
for( int it = itBegin; it < itEnd; it++ )
pVec1[ it ] += pSum[ it ] + pSum1[ it ];
}
free( pVec1 );
}

[EMAIL PROTECTED]:~> $g -O3 -fdump-tree-vect-details -fno-tree-vectorize -m64 -o
mnovec m.c
[EMAIL PROTECTED]:~> $g -O3 -fdump-tree-vect-details -ftree-vectorize -maltivec
-m64 -o mvec m.c

[EMAIL PROTECTED]:~> time ./mnovec 40 1 29720 1000

real0m24.493s
user0m24.483s
sys 0m0.007s
[EMAIL PROTECTED]:~> time ./mvec 40 1 29720 1000

real0m10.777s
user0m10.771s
sys 0m0.005s

-- Victor


-- 


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

[Bug c++/35117] Vectorization on power PC

[irar at il dot ibm dot com]

--- Comment #25 from irar at il dot ibm dot com  2008-02-11 13:35 ---
(In reply to comment #21)
> (In reply to comment #14)
> > Giving it another thought, this is not necessary an alias analysis issue, 
> > even
> > that it fails to tell that the pointers not alias. Since in this case the
> > pointers do differ, the runtime test should take the flow to the vectorized
> > loop. Maybe the test is too strict. I'll look into this on Sunday.
> 
> Hi,
>  Any update on this matter?
> 
> thanks
> eyal
> 

Yes, I asked Victor to look into this, since he implemented versioning for
aliasing in the vectorizer.

Ira


-- 


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

[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-02-11 13:26 ---
BTW, it fails even when all "+r"'s are replaced with "+&r"'s, though that
doesn't
make the testcase more valid.


-- 


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

[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-02-11 12:49 ---
Why?  When there are multiple output register constraints, that says they must
be allocated in different output registers.  The first asm is a silly way to
write the same as "=r" (d0), "=r" (d1), "=r" (d2), as the original values are
never referenced in the asm.


-- 


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

[Bug c++/35117] Vectorization on power PC

[victork at gcc dot gnu dot org]

--- Comment #24 from victork at gcc dot gnu dot org  2008-02-11 12:23 
---
Hi,

Here are some more of my observations.
1. For some unclear reason there is indeed no much difference between
vectorized and non-vectorized versions for long runs like "time ./TestNoVec
92200 8 89720 1000", but the difference is much more apparent for more short
runs:

[EMAIL PROTECTED]:~> time ./mnovec 3 8 29720 1000
real0m1.738s
user0m1.723s
sys 0m0.004s

[EMAIL PROTECTED]:~> time ./mvec 3 8 29720 1000
real0m0.781s
user0m0.778s
sys 0m0.003s

2. If you replace the new() by malloc() it helps to static dependence analysis
to prove independence between pSum, pSum1 and pVec1 at compile time, so the
run-time versioning is not required.

3. If we leave allocation of buffers by new(), then compiler uses "versioning
for alias" and this forces the use of versioning for alignment used to prove
right alignment of store to pVec1. This is less optimal than loop peeling,
since the vectorized version of loop is executed only for values of itBegin
which is multiple of 4. 

Here is the vesion of your program I used to get above results:

#include 
#include 
#include 

typedef float ARRTYPE;
int main ( int argc, char *argv[] )
{
int m_nSamples = atoi( argv[1] );
int itBegin = atoi( argv[2] );
int itEnd = atoi( argv[3] );
int iSizeMain = atoi( argv[ 4 ] );
ARRTYPE *pSum1 = (ARRTYPE*) malloc (sizeof(ARRTYPE) *10);
ARRTYPE *pSum = (ARRTYPE*) malloc (sizeof(ARRTYPE) *10);
for ( int it = 0; it < m_nSamples; it++ )
{
pSum[ it ] = it / itBegin;
pSum1[ it ] = itBegin / ( it + 1 );
}
ARRTYPE *pVec1 = (ARRTYPE*) malloc (sizeof(ARRTYPE) *m_nSamples);

for ( int i = 0, j = 0; i < m_nSamples - 5; i++ )
{
for( int it = itBegin; it < itEnd; it++ )
pVec1[ it ] += pSum[ it ] + pSum1[ it ];
}
free( pVec1 );
}

[EMAIL PROTECTED]:~> $g -O3 -fno-tree-vectorize -m64 -o mnovec m.c
[EMAIL PROTECTED]:~> $g -O3 -fdump-tree-vect-details -ftree-vectorize -maltivec
-m64 -o mvec m.c
[EMAIL PROTECTED]:~> time ./mnovec 3 1 29720 1000

real0m1.754s
user0m1.750s
sys 0m0.003s
[EMAIL PROTECTED]:~> time ./mvec 3 1 29720 1000

real0m0.781s
user0m0.778s
sys 0m0.003s


-- Victor


-- 


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

[Bug objc/35165] New: Massive failures of objc on i686-apple-darwin9

[dominiq at lps dot ens dot fr]

I see massive failures of objc on i686-apple-darwin9:

=== objc Summary for unix ===

# of expected passes2894
# of unexpected failures84
# of expected failures  7
# of unresolved testcases   75
# of unsupported tests  2

=== objc Summary for unix/-m64 ===

# of expected passes799
# of unexpected failures569
# of expected failures  7
# of unresolved testcases   465
# of unsupported tests  2

=== objc Summary ===

# of expected passes3693
# of unexpected failures653
# of expected failures  14
# of unresolved testcases   540
# of unsupported tests  4
/opt/gcc/i686-darwin/gcc/xgcc  version 4.3.0 20080210 (experimental) (GCC)

Many of these failures come from:

Executing on host: /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/
/opt/gcc/gcc-4.3-work/gcc/testsuite/objc/execute/bycopy-1.m  -w  -O0 
-fnext-runtime  -lobjc -lm   -o
/opt/gcc/i686-darwin/gcc/testsuite/objc/bycopy-1.x6(timeout = 300)
In file included from
/opt/gcc/gcc-4.3-work/gcc/testsuite/objc/execute/bycopy-1.m:7:^M
/usr/include/objc/Protocol.h:46: error: expected ';' before '__attribute__'^M
/usr/include/objc/Protocol.h:50: error: expected ';' before '__attribute__'^M
/usr/include/objc/Protocol.h:54: error: expected ';' before '__attribute__'^M
/usr/include/objc/Protocol.h:55: error: expected ';' before '__attribute__'^M
compiler exited with status 1

These failures do not appear in Darwin8 and I get:

[ibook-dhum] dominiq/test% grep "/usr/include/objc/Protocol.h:46: error:
expected" /opt/gcc/i686-darwin/gcc/testsuite/objc/objc.log | wc
 3181908   24476

The faulty lines in /usr/include/objc/Protocol.h start with a '-' sign as in:

- (const char *)name OBJC2_UNAVAILABLE;

but similar constructs appear (and were accepted) in Darwin8.


-- 
   Summary: Massive failures of objc on i686-apple-darwin9
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |4.3.0


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

[Bug tree-optimization/35164] New: [4.3 regression] Unable to coalesce ab SSA_NAMEs

[jakub at gcc dot gnu dot org]

On x86_64 with -O2 the following testcase ICEs with:
D.11907_556(ab) and  D.11907_14(ab)
rh432296.C: In function `void foo(std::vector, std::allocator > >&)':
rh432296.C:52: internal compiler error: SSA corruption
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

That looks similar to the inlining AB problem Jan fixed, but this is with
current trunk.

Sorry for the left-over #include , didn't get to minimize this more
yet.
#include 

struct A
{
  A ();
  virtual ~A ();
  inline void incRef ();
  inline void decRef ();
  virtual void free () {}
  int m_refCount;
};
void A::incRef () { m_refCount++; }
void A::decRef () { if (!m_refCount) { free (); return; } m_refCount--; }
template  struct B;
struct C : public A
{
  static C *alloc ();
};
template 
struct B
{
  typedef T DataT;
  B () : ptr (T::alloc ()) { }
  B (const B& a) : ptr (a.get ()) { incRef (); }
  B (T *a_ptr) : ptr (a_ptr) { incRef (); }
  ~B () { decRef (); }
  B& operator= (const B& a) { if (a.get () != this->get ()) { decRef (); ptr
= a.get (); incRef (); } return *this; }
  template
  operator B () const { return B (ptr); }
  template
  operator B () const { return B (ptr); }
  T* operator-> () const { return ptr; }
  T* get () const { return ptr; }
  void decRef () const { if (ptr != 0) ptr->decRef (); }
  void incRef () const { if (ptr != 0) ptr->incRef (); }
  T *ptr;
};
struct D : public C
{
  template 
  inline void foo (const B & x) { d.resize (1); d[0] = x; }
  std::vector > d;
};
struct E : public C
{
  static E *alloc ();
};
struct F : public D
{
  static F *alloc ();
};
void foo (std::vector > & x)
{
  for (int i = 0; i < 2; ++i)
{
  B l;
  B m;
  l->foo (m);
  x.push_back (l);
}
}


-- 
   Summary: [4.3 regression] Unable to coalesce ab SSA_NAMEs
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-02-11 11:53 ---
Hmm, I think the inline-asm is missing an early clobber too.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug middle-end/33780] different results between O3 and O0

[jv244 at cam dot ac dot uk]

--- Comment #6 from jv244 at cam dot ac dot uk  2008-02-11 11:25 ---
(In reply to comment #5)
> Or are you complaining that we constant fold integer powers as if they were
> non-integer powers

Richard,

I think I'm suggesting more a enhancement than a bug fix. Some good quality
compiler like IBM's xlf90 guarantee bit-wise identical results at all
optimisation levels, unless one specifies -qno-strict (which is included by
default). My idea was/is that optimization independent results are (on the
right hardware, i.e. not x87) also provided by gcc, unless one specifies
-ffast-math. The above testcase is the only one I found in our 500kLOC
simulation package that changed results as I changed optimisation levels, so I
think it is valuable to make the underlying optimisation depending on a compile
time flag (which is included in -ffast-math).

>From a Fortran language point of view the compiler is free to use any
implementation to compute a**i, including one that varies with optimisation
level or context.


-- 


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

[Bug c/35163] folding comparison loses cast

[steven at gcc dot gnu dot org]

--- Comment #1 from steven at gcc dot gnu dot org  2008-02-11 10:44 ---
CCing fold guru.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-11 10:44:42
   date||


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

[Bug c++/35077] [4.3 regression] ICE with attribute in broken class declaration

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2008-02-11 09:31 ---
Fixed.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/35163] New: folding comparison loses cast

[Tom dot de dot Vries at Nxp dot com]

test.c:
...
int main() {

  signed char a = -30;

  /* a == sE2 (-30 signed char) */

  signed char b = -31;

  /* b == sE1 (-31 signed char) */

  int r = a <= (unsigned short)b;

  /* (unsigned short)b == uFFE1 (65505 unsigned short) */

  /*
r 
  == 
a <= (unsigned short)b
  == 
sE2 <= uFFE1
  == arithmetic conversion, rule integral promotion
sFFE2 <= sFFE1 
  == 
-30 <= 65505 
  == 
1
  */

  /* gcc evaluates r to 0 instead */

  return r;

}
...

The problem seems to occur during a call to
fold-const.c:fold_widened_comparison(), which calls tree.c:get_unwidened():
...
/* Return OP, stripped of any conversions to wider types as much as is safe.
   Converting the value back to OP's type makes a value equivalent to OP.

   If FOR_TYPE is nonzero, we return a value which, if converted to
   type FOR_TYPE, would be equivalent to converting OP to type FOR_TYPE.

   If FOR_TYPE is nonzero, unaligned bit-field references may be changed to the
   narrowest type that can hold the value, even if they don't exactly fit.
   Otherwise, bit-field references are changed to a narrower type
   only if they can be fetched directly from memory in that type.

   OP must have integer, real or enumeral type.  Pointers are not allowed!

   There are some cases where the obvious value we could return
   would regenerate to OP if converted to OP's type,
   but would not extend like OP to wider types.
   If FOR_TYPE indicates such extension is contemplated, we eschew such values.
   For example, if OP is (unsigned short)(signed char)-1,
   we avoid returning (signed char)-1 if FOR_TYPE is int,
   even though extending that to an unsigned short would regenerate OP,
   since the result of extending (signed char)-1 to (int)
   is different from (int) OP.  */

tree
get_unwidened (tree op, tree for_type)
...

get_unwidened() is called with op == (int)(unsigned short)-31sc and for_type ==
signed char.

get unwidened() returns -31sc. However, 'Converting the value back to OP's type
makes a value equivalent to OP' would mean convert (int)-31sc == (int)(unsigned
short)-31sc, which is not correct: 

(int)-31sc == (int)(unsigned short)-31sc
  <==>
(int)-31sc == (int)65505us
  <==>
-31si == 65505si
  <==>
FALSE


-- 
   Summary: folding comparison loses cast
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Tom dot de dot Vries at Nxp dot com


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

[Bug c++/35077] [4.3 regression] ICE with attribute in broken class declaration

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2008-02-11 09:29 ---
Subject: Bug 35077

Author: paolo
Date: Mon Feb 11 09:28:48 2008
New Revision: 132237

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132237
Log:
cp/
2008-02-11  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35077
* decl.c (groktypename): Check grokdeclarator return.

testsuite/
2008-02-11  Paolo Carlini  <[EMAIL PROTECTED]>

PR c++/35077
* g++.dg/template/crash78.C: New.

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


-- 


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

[Bug target/23322] [4.1/4.2/4.3 regression] performance regression

[hubicka at gcc dot gnu dot org]

--- Comment #30 from hubicka at gcc dot gnu dot org  2008-02-11 09:23 
---
On britten there is also no noticeable effect on SPECfp score.


-- 


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

[Bug tree-optimization/33992] [4.3 Regression] Miscompiles function with inlining, breaks profiledbootstrap

[ubizjak at gmail dot com]

--- Comment #40 from ubizjak at gmail dot com  2008-02-11 08:59 ---
Richi, thanks for the fix.

Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/35162] New: Documentation incorrect for -fcx-limited-range

[jb at gcc dot gnu dot org]

The documentation for -fcx-limited-range states:

@item -fcx-limited-range
@opindex fcx-limited-range
When enabled, this option states that a range reduction step is not
needed when performing complex division.  The default is
@option{-fno-cx-limited-range}, but is enabled by @option{-ffast-math}.

This option controls the default setting of the ISO C99
@code{CX_LIMITED_RANGE} pragma.  Nevertheless, the option applies to
all languages.

However, -fcx-limited-range (and the CX_LIMITED_RANGE pragma) affect
multiplication and absolute value as well as division, since it's not only
range reduction but also handling of FP exceptions. See Section 7.3.4 and Annex
G in the C99 standard (assuming the FCD is close to the actual standard). 

At least for multiplication, it seems the actual code is correct, i.e. a call
to mulsc in libgcc is done without -fcx-limited-range, so I guess it's only the
documentation that needs to be updated.


-- 
   Summary: Documentation incorrect for -fcx-limited-range
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org


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

[Bug testsuite/35047] some vectorisation tests fail with --with-arch=core2 or on i386-apple-darwin8.11.1

[ubizjak at gmail dot com]

--- Comment #18 from ubizjak at gmail dot com  2008-02-11 08:56 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug testsuite/35047] some vectorisation tests fail with --with-arch=core2 or on i386-apple-darwin8.11.1

[uros at gcc dot gnu dot org]

--- Comment #17 from uros at gcc dot gnu dot org  2008-02-11 08:55 ---
Subject: Bug 35047

Author: uros
Date: Mon Feb 11 08:54:33 2008
New Revision: 132235

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132235
Log:
PR testsuite/35047
* gcc.dg/compat/vector-2_x.c: Add -mno-mmx for x86 targets.
* gcc.dg/compat/vector-2_y.c: Ditto.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/pr33992.c
trunk/gcc/testsuite/gcc.dg/compat/vector-2_x.c
trunk/gcc/testsuite/gcc.dg/compat/vector-2_y.c


-- 


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

[Bug fortran/35161] New: Bind(C): Procedures with different interface and same C binding label

[burnus at gcc dot gnu dot org]

I think it is formally valid to have multiple times the same C binding label
(at least for procedures). At least I cannot find anything in the standard
which says otherwise.

Currently, both gfortran and NAG f95 reject the following program while g95 and
ifort accept it.

See also question posted at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b1e8c8d0af9d16e8/
(when writing this, the question was not yet answered)

NAG f95:
Error: aaa.f90: Duplicate binding label 'xxx' for external procedure XXX_1 and
external procedure XXX_2

gfortran:
Error: Binding label 'xxx' in interface body at (1) collides with the global
entity 'xxx' at (2)

interface xxx
integer function xxx_1( y ) bind( c, name = "xxx" )
use iso_c_binding
real(c_float), intent(inout) :: y
end function
integer function xxx_2( y ) bind( c, name = "xxx" )
use iso_c_binding
real(c_float), intent(inout), dimension(*) :: y
end function
end interface
end


-- 
   Summary: Bind(C): Procedures with different interface and same C
binding label
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug inline-asm/35160] [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2008-02-11 08:33 ---
Silent miscompilation of nss.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1
   Target Milestone|--- |4.3.0


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

[Bug inline-asm/35160] New: [4.3 regression] CSE introduces sharing of the same pseudo/hard reg between different output regs in inline asm

[jakub at gcc dot gnu dot org]

On x86_64 with -O1 and higher, 4.3 miscompiles:
extern void abort (void);

void
__attribute__((noinline))
foo (unsigned long *y)
{
   unsigned long b[3], c0, c1, c2, d0, d1, d2;
   d0 = 0; d1 = 0; d2 = 0; c0 = c1 = c2 = 0;

   __asm__ ("movl $7, %k0; movl $8, %k1; movl $9, %k2"
: "+r" (d0), "+r" (d1), "+r" (d2));
   __asm__ ("movq %3, %0; movq %4, %1; movq %5, %2"
: "+r" (c0), "+r" (c1), "+r" (c2), "+r" (d0), "+r" (d1), "+r"
(d2));
   y[0] = c0;
   y[1] = c1;
   y[2] = c2;
}

int
main (void)
{
  unsigned long y[3];
  foo (y);
  if (y[0] != 7 || y[1] != 8 || y[2] != 9)
abort ();
  return 0;
}
First CSE pass assigns the same pseudo to different output regs.  It would be
fine if those were input only registers.
Happens both with "+r" and "=r" ... "0" syntax.


-- 
   Summary: [4.3 regression] CSE introduces sharing of the same
pseudo/hard reg between different output regs in inline
asm
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug tree-optimization/33992] [4.3 Regression] Miscompiles function with inlining, breaks profiledbootstrap

[rguenth at gcc dot gnu dot org]

--- Comment #39 from rguenth at gcc dot gnu dot org  2008-02-11 08:27 
---
Subject: Bug 33992

Author: rguenth
Date: Mon Feb 11 08:27:00 2008
New Revision: 132234

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132234
Log:
2008-02-11  Uros Bizjak  <[EMAIL PROTECTED]>
Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/33992
* tree-ssa-loop-im.c (rewrite_bittest): Fixup the type of
the zero we compare against.

* gcc.c-torture/execute/pr33992.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr33992.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c


-- 


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