[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2008-02-27 09:09 ---
Subject: Bug 35368

Author: jakub
Date: Wed Feb 27 09:09:05 2008
New Revision: 132704

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132704
Log:
PR c++/35368
* rtti.c: Include c-pragma.h.
(push_abi_namespace, pop_abi_namespace): New functions.
(build_dynamic_cast_1, tinfo_base_init, get_pseudo_ti_index,
create_tinfo_types, emit_support_tinfos): Use them.
* Make-lang.in (cp/rtti.o): Depend on $(C_PRAGMA_H).

* g++.dg/ext/visibility/typeinfo2.C: New test.
* g++.dg/ext/visibility/typeinfo3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/visibility/typeinfo2.C
trunk/gcc/testsuite/g++.dg/ext/visibility/typeinfo3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/Make-lang.in
trunk/gcc/cp/rtti.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/24985] Line info in diagnostics is very unfriendly

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2008-02-27 09:00 ---
This just needs someone with the time and willingness to implement it.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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

[Bug c++/35387] New: __PRETTY_FUNCTION__ produces inconsistent output

[d dot frey at gmx dot de]

Minimal example program:

#include 
#include 

template< typename T > struct A;

template< typename T, typename U > struct A< std::pair< T, U > >
{
  static void f()
  {
std::cout << __PRETTY_FUNCTION__ << std::endl;
  }
};

int main()
{
  A< std::pair< int, int > >::f();
}


Output of __PRETTY_FUNCTION__ from this program:

static void A >::f() [with T = int, U = int]

Problem:

_T1 and _T2 are printed as the pair's parameter names, but it then say T=int
and U=int.

Additional information:

This only seems to occur with partial specialization.


-- 
   Summary: __PRETTY_FUNCTION__ produces inconsistent output
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de


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

[Bug middle-end/34971] bitfield rotates are folded and expanded wrong

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-27 09:50 ---
Subject: Bug 34971

Author: rguenth
Date: Wed Feb 27 09:50:04 2008
New Revision: 132706

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

PR middle-end/34971
* expr.c (expand_expr_real_1): Assert on rotates that operate
on partial modes.
* fold-const.c (fold_binary): Use the types precision, not the
bitsize of the mode if folding rotate expressions.  Build rotates
only for full modes.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr34971.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/35387] __PRETTY_FUNCTION__ produces inconsistent output

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-27 09:35 ---
It uses the names as in the std::pair template declaration, so you could argue
this is correct.


-- 


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

[Bug c++/35368] [4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-02-27 09:31 ---
Fixed on 4.3/4.4, I believe the problem can't be reproduced on earlier branches
unless you have hjl's patch backported.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.1.3 4.2.3 4.3.0   |4.3.0 4.4.0
 Resolution||FIXED
Summary|[4.1/4.2/4.3/4.4 Regression]|[4.3/4.4 Regression] With
   |With #pragma visibility,|#pragma visibility, `vtable
   |`vtable for |for
   |__cxxabiv1::__class_type_inf|__cxxabiv1::__class_type_inf
   |o' is emitted as a hidden-  |o' is emitted as a hidden-
   |visibility relocation   |visibility relocation


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

[Bug c++/35368] [4.1/4.2/4.3/4.4 Regression] With #pragma visibility, `vtable for __cxxabiv1::__class_type_info' is emitted as a hidden-visibility relocation

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2008-02-27 09:27 ---
Subject: Bug 35368

Author: jakub
Date: Wed Feb 27 09:26:24 2008
New Revision: 132705

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132705
Log:
PR c++/35368
* rtti.c: Include c-pragma.h.
(push_abi_namespace, pop_abi_namespace): New functions.
(build_dynamic_cast_1, tinfo_base_init, get_pseudo_ti_index,
create_tinfo_types, emit_support_tinfos): Use them.
* Make-lang.in (cp/rtti.o): Depend on $(C_PRAGMA_H).

* g++.dg/ext/visibility/typeinfo2.C: New test.
* g++.dg/ext/visibility/typeinfo3.C: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo2.C
branches/gcc-4_3-branch/gcc/testsuite/g++.dg/ext/visibility/typeinfo3.C
Modified:
branches/gcc-4_3-branch/gcc/cp/ChangeLog
branches/gcc-4_3-branch/gcc/cp/Make-lang.in
branches/gcc-4_3-branch/gcc/cp/rtti.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/35373] [4.4 Regression] bootstraping on powerpc-apple-darwin9 fails with revision 132578

[eres at il dot ibm dot com]

--- Comment #1 from eres at il dot ibm dot com  2008-02-27 10:03 ---
Same error was received on powerpc64-linux, trunk r132684

configured with:
--with-cpu=default32  --enable-checking --enable-bootstrap


-- 


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

[Bug preprocessor/35379] -MT generates a target string too long over two lines

[uriah at mobiletornado dot com]

--- Comment #2 from uriah at mobiletornado dot com  2008-02-27 09:41 ---
Subject: RE:  -MT generates a target string too long
 over two lines

Hello,
Actually I've encountered an error with Microsoft nmake... I've tried to
reproduce it with make, but it seemed to work OK.
It still seems to me a bug that a very long line is prepended with a
backslash and spaces, but it may indeed be something very slight.
Uriah 

-Original Message-
From: rwild at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 26, 2008 4:48 PM
To: [EMAIL PROTECTED]
Subject: [Bug preprocessor/35379] -MT generates a target string too long
over two lines



--- Comment #1 from rwild at gcc dot gnu dot org  2008-02-26 14:48
---
> (the redundant spaces may interfere with make operation, apparently)

Can you show in which way they interfere?  If they cause an error, then post
it, please.  Which make implementation?


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||Ralf dot Wildenhues at gmx
   ||dot de


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

--- You are receiving this mail because: --- You reported the bug,
or are watching the reporter.


-- 


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

[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression

[thomas dot orgis at awi dot de]

--- Comment #3 from thomas dot orgis at awi dot de  2008-02-27 10:12 ---
Well, that's good to hear that this is already fixed.
Though it may be nit-picky to note that there isn't a 4.3 gfortran binary
package on the page you pointed out but only 4.2 and trunk (4.4) ;-)
I'll see when the sytem I am using here will be upgraded to 4.3 ... may take
some time (well, a release of 4.3 would also help;-).
For now I am glad that I found the real problem, have to continue with my work.

Thanks.


-- 


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

[Bug middle-end/34971] bitfield rotates are folded and expanded wrong

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-27 09:50 ---
I'll apply this for 4.3.1 as well.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.4.0


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

[Bug c++/35388] New: [Alpha OSF V5.1] error compiling dealII SPEC CPU 2006 benchmark

[dario at unizar dot es]

Trying to compile 447.dealII benchmark from SPEC CPU 2006 v 1.0 in an Alpha
machine I get the following error:

 g++ -v -save-temps -c -o vector.long_double.o -DSPEC_CPU -DNDEBUG  -Iinclude
-DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3 -O3 -static -mcpu=ev6 -mtune=ev6 
-D__V40_OBJ_COMPAT -DCOMPAT_43-DSPEC_CPU_LP64 -DSPEC_CPU_TABLE_WORKAROUND
-Dunix -DDEAL_II_NAMESP_TEMPL_FRIEND_BUG2 -D__USE_STD_IOSTREAM 
vector.long_double.cc
Using built-in specs.
Target: alphaev68-dec-osf5.1b
Configured with: ../gcc-4.2.3/configure --prefix=/Soft/Arch/gcc/4.2.3
--enable-languages=c,c++,java,fortran --with-gmp=/Soft/Arch/gmp/4.2.2
--with-mpfr=/Soft/Arch/mpfr/2.3.1
Thread model: posix
gcc version 4.2.3

/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../libexec/gcc/alphaev68-dec-osf5.1b/4.2.3/cc1plus
-E -quiet -v -Iinclude -iprefix
/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../lib/gcc/alphaev68-dec-osf5.1b/4.2.3/
-DSPEC_CPU -DNDEBUG -DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3
-D__V40_OBJ_COMPAT -DCOMPAT_43 -DSPEC_CPU_LP64 -DSPEC_CPU_TABLE_WORKAROUND
-Dunix -DDEAL_II_NAMESP_TEMPL_FRIEND_BUG2 -D__USE_STD_IOSTREAM
vector.long_double.cc -mcpu=ev6 -mtune=ev6 -O3 -fpch-preprocess -o
vector.long_double.ii
ignoring nonexistent directory
"/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../alphaev68-dec-osf5.1b/include"
ignoring duplicate directory
"/Soft/Arch/gcc/4.2.3/lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../include/c++/4.2.3"
ignoring duplicate directory
"/Soft/Arch/gcc/4.2.3/lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../include/c++/4.2.3/alphaev68-dec-osf5.1b"
ignoring duplicate directory
"/Soft/Arch/gcc/4.2.3/lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../include/c++/4.2.3/backward"
ignoring duplicate directory
"/Soft/Arch/gcc/4.2.3/lib/gcc/alphaev68-dec-osf5.1b/4.2.3/include"
ignoring nonexistent directory
"/Soft/Arch/gcc/4.2.3/lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../alphaev68-dec-osf5.1b/include"
#include "..." search starts here:
#include <...> search starts here:
 include

/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../include/c++/4.2.3

/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../include/c++/4.2.3/alphaev68-dec-osf5.1b

/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../lib/gcc/alphaev68-dec-osf5.1b/4.2.3/../../../../include/c++/4.2.3/backward

/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../lib/gcc/alphaev68-dec-osf5.1b/4.2.3/include
 /usr/local/include
 /Soft/Arch/gcc/4.2.3/include
 /usr/include
End of search list.

/usr/local/Share/Soft/tru64-alpha/SR/gcc/4.2.3/bin/../libexec/gcc/alphaev68-dec-osf5.1b/4.2.3/cc1plus
-fpreprocessed vector.long_double.ii -quiet -dumpbase vector.long_double.cc
-mcpu=ev6 -mtune=ev6 -auxbase-strip vector.long_double.o -O3 -version -o
vector.long_double.s
GNU C++ version 4.2.3 (alphaev68-dec-osf5.1b)
compiled by GNU C version 4.2.3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 09fd32afbe1151943aeb89d00899f6fa
include/lac/vector.templates.h: In member function 'Number
Vector::linfty_norm() const [with Number = long double]':
include/lac/vector.templates.h:372: internal compiler error: in
iv_analyze_expr, at loop-iv.c:911


-- 
   Summary: [Alpha OSF V5.1] error compiling dealII SPEC CPU 2006
benchmark
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dario at unizar dot es
  GCC host triplet: OSF1 V5.1 2650 alpha alpha unknown Tru64
GCC target triplet: alphaev68-dec-osf5.1b


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

[Bug c++/35388] [Alpha OSF V5.1] error compiling dealII SPEC CPU 2006 benchmark

[dario at unizar dot es]

--- Comment #1 from dario at unizar dot es  2008-02-27 10:24 ---
Created an attachment (id=15235)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15235&action=view)
preprocessed file


-- 


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

[Bug c++/35389] New: error in norm() of STL

[ywei at qualcomm dot com]

There is something wrong with the norm() in STL to get the norm2 of complex
numbers.

Suppose we have complex x(8,1), the norm of x should be 8*8 + 1*1 = 65,
but norm(x) returns 64, which is incorrect.

If we do complex x(8,1), there is no problem, norm(x) does return 65.

The issue is not limited to version 4.2.1. It is observed in other versions as
well.


-- 
   Summary: error in norm() of STL
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ywei at qualcomm dot com


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2008-02-27 10:35 
---
Actually, after looking more in depth at the front-end code, we do a fairly
good job of supporting the use of f2c calling conventions for Fortran 95 code
(it's mainly handled by the use of sym->attr.always_explicit, which does the
trick very nicely. Following on that, I found that there is one place this use
of sym->attr.always_explicit is missing, and that's where the bug is triggered.
The following patch fixes it:

Index: trans-expr.c
===
--- trans-expr.c(revision 132578)
+++ trans-expr.c(working copy)
@@ -513,7 +513,8 @@
   /* Dereference scalar hidden result.  */
  if (gfc_option.flag_f2c && sym->ts.type == BT_COMPLEX
  && (sym->attr.function || sym->attr.result)
- && !sym->attr.dimension && !sym->attr.pointer)
+ && !sym->attr.dimension && !sym->attr.pointer
+ && !sym->attr.always_explicit)
se->expr = build_fold_indirect_ref (se->expr);

   /* Dereference non-character pointer variables. 


-- 

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
   Keywords||patch
   Last reconfirmed|2008-01-19 12:43:02 |2008-02-27 10:35:14
   date||
   Target Milestone|--- |4.4.0


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

[Bug c++/35388] [Alpha OSF V5.1] error compiling dealII SPEC CPU 2006 benchmark

[dario at unizar dot es]

--- Comment #2 from dario at unizar dot es  2008-02-27 10:25 ---
Created an attachment (id=15236)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15236&action=view)
assembler file


-- 


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

[Bug middle-end/35390] New: ~~n != n in some cases

[takeshi dot mouri dot net at green dot ocn dot ne dot jp]

the preprocessed file:
unsigned
foo (int n)
{
  return ~((unsigned)~n);
}

The above code is compiled to:
;; Function foo (foo)
;; enabled by -tree-original


{
  return (unsigned int) ~n;
}

This should be "return (unsigned int) n".


-- 
   Summary: ~~n != n in some cases
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: takeshi dot mouri dot net at green dot ocn dot ne dot jp
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug ada/34799] [Ada] Assertion fails when no component clause is given for generic record member

[sam at gcc dot gnu dot org]

--- Comment #2 from sam at gcc dot gnu dot org  2008-02-27 11:57 ---
Fixed in SVN trunk


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/22255] Reset on shared file causes Use_Error.

[sam at gcc dot gnu dot org]

--- Comment #4 from sam at gcc dot gnu dot org  2008-02-27 12:13 ---
Subject: Bug 22255

Author: sam
Date: Wed Feb 27 12:12:14 2008
New Revision: 132708

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132708
Log:
gcc/ada/
PR ada/22255
* s-fileio.adb (Reset): Do not raise Use_Error if mode isn't changed.

gcc/testsuite/
PR ada/22255
* gnat.dg/test_direct_io.adb: New file.

Added:
trunk/gcc/testsuite/gnat.dg/test_direct_io.adb
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/s-fileio.adb
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/35390] ~~n != n in some cases

[takeshi dot mouri dot net at green dot ocn dot ne dot jp]

--- Comment #1 from takeshi dot mouri dot net at green dot ocn dot ne dot 
jp  2008-02-27 11:53 ---
The regression is located at revision 129128.


-- 

takeshi dot mouri dot net at green dot ocn dot ne dot jp changed:

   What|Removed |Added

  Known to fail||4.3.0
  Known to work||4.1.1


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

[Bug ada/22255] Reset on shared file causes Use_Error.

[sam at gcc dot gnu dot org]

--- Comment #5 from sam at gcc dot gnu dot org  2008-02-27 12:13 ---
Fixed in SVN trunk


-- 

sam at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug ada/34799] [Ada] Assertion fails when no component clause is given for generic record member

[sam at gcc dot gnu dot org]

--- Comment #1 from sam at gcc dot gnu dot org  2008-02-27 11:54 ---
Subject: Bug 34799

Author: sam
Date: Wed Feb 27 11:53:55 2008
New Revision: 132707

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132707
Log:
gcc/ada/
PR ada/34799
* sem_ch13.adb (Analyze_Record_Representation_Clause): Check
that underlying type is present.

gcc/testsuite/
PR ada/34799
* gnat.dg/specs/pr34799.ads: New test.


Added:
trunk/gcc/testsuite/gnat.dg/specs/pr34799.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/sem_ch13.adb
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/35385] gfortran does not support the COCO preprocessor

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-27 11:59:37
   date||


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

[Bug c++/35387] __PRETTY_FUNCTION__ produces inconsistent output

[d dot frey at gmx dot de]

--- Comment #2 from d dot frey at gmx dot de  2008-02-27 12:02 ---
I understand where the names come from, but that doesn't make the message
correct. Consider the specialization in the example program to use <_T2,_T1>
(note the reversed order) and an instantiation with , the resulting
message is:

static void A >::f() [with _T2 = int, _T1 = double]

which is *really* misleading. Since it's actually vice versa.

Additionally I just found out that the same problem also occurs within error
and warning messages from the compiler, so it's not limited to
__PRETTY_FUNCTION__. I triggered a warning for an unused variable, which reads:

foo.cpp: In static member function ‘static void A >::f()
[with T = int, U = int]’:
foo.cpp:17:   instantiated from here
foo.cpp:10: warning: unused variable ‘i’

Regards, Daniel


-- 


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

[Bug other/28322] GCC new warnings and compatibility

[manu at gcc dot gnu dot org]

--- Comment #12 from manu at gcc dot gnu dot org  2008-02-27 12:34 ---
Patches for older branches have been posted here:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01357.html

I hope they are useful and don't break anything ;-)

If there is nothing else to do in this PR, I will close it in a few days.


-- 


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

[Bug c++/35389] error in norm() of STL

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-02-27 12:43 ---
This works for me.  Please provide a testcase that fails.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug middle-end/35390] [4.3/4.4 Regression] ~~n != n in some cases

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-27 12:36 ---
extern void abort (void);

unsigned int foo (int n)
{
  return ~((unsigned int)~n);
}

int main()
{
  if (foo(0) != 0)
abort ();
  return 0;
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work|4.1.1   |4.1.1 4.2.2


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

[Bug middle-end/35390] [4.3/4.4 Regression] ~~n != n in some cases

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-27 12:32 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-02-27 12:32:42 |2008-02-27 12:32:52
   date||


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

[Bug middle-end/35390] [4.3/4.4 Regression] ~~n != n in some cases

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-27 12:32 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-02-27 12:32:42
   date||
Summary|~~n != n in some cases  |[4.3/4.4 Regression] ~~n !=
   ||n in some cases
   Target Milestone|--- |4.3.0


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

[Bug c++/35389] error in norm() of STL

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-27 12:43 ---
I used:

#include 
#include 
#include 

int main()
{
  std::complex x(8, 1);
  std::cout << std::norm(x) << std::endl;
}


-- 


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

[Bug c++/35387] __PRETTY_FUNCTION__ produces inconsistent output

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2008-02-27 13:00 ---
Confirmed. This is a diagnostics bug. (And perhaps a duplicate).

Thanks for the report. If you would like to contribute a patch, please read 
http://gcc.gnu.org/contribute.html


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2008-02-27 13:00:51
   date||


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

[Bug other/28322] GCC new warnings and compatibility

[manu at gcc dot gnu dot org]

--- Comment #14 from manu at gcc dot gnu dot org  2008-02-27 13:42 ---
(In reply to comment #13)
> Thanks a lot for taking the time to write a patch for this. I do have one
> question: if I'm reading the patch correctly, this postpones warnings about
> unrecognised options not just for -Wno-* but also for -fno-* and -mno-*. Was
> that deliberate?

Hum. You are right. I don't think we want to ignore -fno-* and -mno-* options
since we don't have a way to detect whether they are unimportant (like we do
with -Wno-* options). I'll fix that.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |manu at gcc dot gnu dot org
   |dot org |
 Status|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-02-27 13:42:28
   date||


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

[Bug c++/35391] New: gcc fails to compile file in icewm (icewm.org)

[T dot Mittelstaedt at cadenas dot de]

cd /localbuild/icewm-1.2.35/src/
g++ -fpermissive -Wall -Wpointer-arith -Wconversion -Wwrite-strings -Winline
-Woverloaded-virtual -W -fno-exceptions -fno-rtti -g -O2  -DHAVE_CONFIG_H
-DLIBDIR='"/usr/local/share/icewm"' -DCFGDIR='"/etc/icewm"'
-DLOCDIR='"/usr/local/share/locale"' -DKDEDIR='""' -DPACKAGE='"icewm"'
-DVERSION='"1.2.35"' -DHOSTOS='"Linux 2.6.17-10-generic"' -DHOSTCPU='"x86_64"'
-DEXEEXT='""' -DICEWMEXE='"icewm"' -DICEWMTRAYEXE='"icewmtray"'
-DICEWMBGEXE='"icewmbg"' -DICESMEXE='"icewm-session"' -DICEHELPEXE='"icehelp"'
-DICEHELPIDX='"/usr/local/share/doc/icewm-1.2.35/icewm.html"' -I/usr/include
-I/usr/include/freetype2 -I/usr/include-c yapp.cc 
yapp.cc:472: internal compiler error: in reference_to_unused, at
dwarf2out.c:10010
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

Compilation exited abnormally with code 1 at Wed Feb 27 14:00:04


Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2.2/configure --prefix=/opt2/gcc-4.2.2
--enable-version-specific-runtime-libs --enable-static --enable-shared
--enable-languages=c,c++,objc,obj-c++ --enable-threads=posix --enable-nls
--enable-__cxa_atexit --enable-libstdcxx-debug --enable-checking=release
Thread model: posix
gcc version 4.2.2


-- 
   Summary: gcc fails to compile file in icewm (icewm.org)
   Product: gcc
   Version: 4.2.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: T dot Mittelstaedt at cadenas dot de
 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=35391

[Bug c/35392] New: Warning "array subscript is above array bounds" in inline fct

[etienne_lorrain at yahoo dot fr]

$ gcc -V 4.3 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure linux gnu
Thread model: posix
gcc version 4.3.0 20080219 (prerelease) [gcc-4_3-branch revision 132456]
(Debian 4.3-20080219-1)
$ gcc -V 4.3 fs.i -funsigned-char -Os -Wall -S -o fs.S
fs.i: In function ‘DOS_analyse’:
fs.i:149: warning: array subscript is above array bounds

The warning is in a inline function, setting it non-inline make the warning
disappear - and I still have no clue where is the problem in this file fs.i:

typedef struct
{
  unsigned magic;
  unsigned short version;
  struct gujin_param_compilation_attrib
  {
unsigned short vga_support:1;
unsigned short big_malloc:1;
unsigned short bios_only:1;
unsigned short initrd_loader:1;
unsigned short vmlinuz_loader:1;
unsigned short reserved:11;
  } __attribute__ ((packed)) compilation_attrib;
  char dot_msg[4];
  char go_msg[8];
  char scanpath[16];
  unsigned short default_video_mode,
default_text_video_mode, default_graphic_video_mode;
  unsigned char min_nb_initrd;
  unsigned char stop_emulation;
  struct gujin_param_attrib
  {
unsigned verbose:1;
unsigned lock_bpp:1;
unsigned lock_text_graphic:1;
unsigned menu_with_disk:1;
unsigned menu_with_parttype:1;
unsigned menu_with_partition:1;
unsigned menu_with_initrd:1;
unsigned force_textmode:1;
unsigned force_bzimage_protocol:1;
unsigned force_probe_root:1;
unsigned IDE_in_BIOS_order:1;
unsigned ignore_kernel_option:1;
unsigned disk_write_enable:1;
unsigned hide_unhide_partitions:1;
unsigned VGA_interface:1;
unsigned download_ansi_font:1;
unsigned VESA_interface:1;
unsigned enable_VESA_hardwin:1;
unsigned VESA2_interface:1;
unsigned enable_joystick:1;
unsigned search_disk_mbr:1;
unsigned search_part_mbr:1;
unsigned keep_all_part_mbr:1;
unsigned search_el_torito:1;
unsigned search_topdir_kernel:1;
unsigned search_subdir_kernel:1;
unsigned probe_bios_floppy_disk:1;
unsigned probe_bios_hard_disk:1;
unsigned probe_ide_disk:1;
unsigned probe_cdrom:1;
unsigned probe_dos_disk:1;
unsigned write_disabled_written_once:1;
  } __attribute__ ((packed)) attrib;
  struct autoload_str
  {
unsigned char last_loaded;
unsigned char total_loadable;
unsigned char init_page;
unsigned char total_page;
  } __attribute__ ((packed)) autoload;
  unsigned char timeout_autoload;
  unsigned char kbdmap;
  signed char time_hour_offset, time_minute_offset;
  unsigned reserved2[4];
  char extra_cmdline[64];
  unsigned char cardname[32];
  unsigned char VGA_valid_mode[16];
  struct vga_mode_str
  {
unsigned isgraphic:1;
unsigned reserved:1;
unsigned number:7;
unsigned bpp:4;
unsigned height:11;
unsigned width_div8:8;
  } __attribute__ ((packed)) vga_mode[30];
  unsigned short partial_checksum __attribute__ ((aligned (2)));
} __attribute__ ((packed)) gujin_param_t;

void __ERROR (void);

extern char memory[];
extern inline void
_memcpy (void *dst, const void *src, unsigned size)
{
asm ("  cld # _memcpy modify %3 \n" "   rep movsb
%%ds:(%%esi),%%es:(%%edi) \n": "+c" (size), "+D" (dst), "+S" (src), "=m"
(*memory): "m" (*memory):"cc", "memory");

}

extern inline int
_memeql (const void *s1, const void *s2, unsigned nb)
{
asm ("cld; repe cmpsb %%es:(%%edi),%%ds:(%%esi) ": "+c" (nb), "+S" (s1), "+D"
(s2):"m" (*memory));

  return !nb;
}

extern inline const char *
_strnchr (const char *str, char c, unsigned size)
{
asm ("cld ; repne scasb %%es:(%%edi),%%al": "+c" (size), "+D" (str): "a" (c),
"X" (*str):"cc");

  return str - 1;
}

extern inline int
hexval (char c)
{
  extern const char *const itoa_array;
  extern const unsigned itoa_len;
  const char *ptr = _strnchr (itoa_array, c, itoa_len);

  if (*ptr == c)
return (ptr - itoa_array) & 0x0F;
  return -1;
}

extern inline void *
memcpy (void *dst, const void *src, const unsigned size)
{
  if (__builtin_constant_p (size))
{
  if (size == 1)
{
  ((unsigned char *) dst)[0] = ((const unsigned char *) src)[0];
  return dst;
}
  else if (size == 2)
{
  ((unsigned short *) dst)[0] = ((const unsigned short *) src)[0];
  return dst;
}
  else if (size == 3)
{
  ((unsigned short *) dst)[0] = ((const unsigned short *) src)[0];
  ((unsigned char *) dst)[2] = ((const unsigned char *) src)[2];
  return dst;
}
  else if (size == 4)
{
  ((unsigned *) dst)[0] = ((const unsigned *) src)[0];
  return dst;
}
  else if (size == 5)
{
  ((unsigned *) dst)[0] = ((const unsigned *) src)[0];
  ((unsigned char *) dst)[4] = ((const unsigned char *) src)[4];
  return dst;
}
  else if (size == 6)
{
  ((unsigned *) dst)[0] = ((const unsigned *) src)[0];
  ((unsigned short *) dst)[2] = 

[Bug c++/35391] gcc fails to compile file in icewm (icewm.org)

[T dot Mittelstaedt at cadenas dot de]

--- Comment #2 from T dot Mittelstaedt at cadenas dot de  2008-02-27 13:05 
---
gcc 4.1 compiles this file.

[EMAIL PROTECTED]:/localbuild/icewm-1.2.35/src$ /usr/X11R6/bin/gcc-4.1 -v
Reading specs from /usr/lib/gcc/x86_64-linux-gnu/4.1.2/specs
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)



-- 


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

[Bug c++/35391] gcc fails to compile file in icewm (icewm.org)

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-27 13:23 ---
This looks like a dup of PR31899 which was fixed for 4.2.3.  Please re-open if
that is not the case.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2008-02-27 13:18 ---
Subject: Bug 25290

Author: rguenth
Date: Wed Feb 27 13:17:17 2008
New Revision: 132710

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

PR middle-end/25290
* fold-const.c (fold_unary): Return the correct argument,
converted to the result type.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr35390.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug other/28322] GCC new warnings and compatibility

[pmaydell at chiark dot greenend dot org dot uk]

--- Comment #13 from pmaydell at chiark dot greenend dot org dot uk  
2008-02-27 13:32 ---
Thanks a lot for taking the time to write a patch for this. I do have one
question: if I'm reading the patch correctly, this postpones warnings about
unrecognised options not just for -Wno-* but also for -fno-* and -mno-*. Was
that deliberate?


-- 


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

[Bug c++/35391] gcc fails to compile file in icewm (icewm.org)

[T dot Mittelstaedt at cadenas dot de]

--- Comment #1 from T dot Mittelstaedt at cadenas dot de  2008-02-27 13:01 
---
Created an attachment (id=15237)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15237&action=view)
preprocessed source stripped of system includes via uninclude


-- 


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

[Bug rtl-optimization/34999] Fallthru crossing edges in partition_hot_cold_basic_blocks are not been fixed when the section ends with call insn

[revitale at gcc dot gnu dot org]

--- Comment #3 from revitale at gcc dot gnu dot org  2008-02-27 13:28 
---
Subject: Bug 34999

Author: revitale
Date: Wed Feb 27 13:27:56 2008
New Revision: 132711

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132711
Log:
Fix PR rtl-optimization/34999

Added:
trunk/gcc/testsuite/gcc.dg/tree-prof/pr34999.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/31899] [4.2 Regression] -g and using declaration causing ICE in reference_to_unused

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2008-02-27 13:23 
---
*** Bug 35391 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||T dot Mittelstaedt at
   ||cadenas dot de


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

[Bug middle-end/34971] bitfield rotates are folded and expanded wrong

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-27 14:14 ---
Fixed for 4.3.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work|4.4.0   |4.3.0 4.4.0
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug middle-end/35390] [4.3/4.4 Regression] ~~n != n in some cases

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-02-27 14:13 ---
Subject: Bug 35390

Author: rguenth
Date: Wed Feb 27 14:12:33 2008
New Revision: 132712

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

PR middle-end/35390
* fold-const.c (fold_unary): Return the correct argument,
converted to the result type.

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

PR middle-end/34971
* fold-const.c (fold_binary): Use the types precision, not the
bitsize of the mode if folding rotate expressions.  Build rotates
only for full modes.

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

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr34971.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr35390.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/35390] [4.3/4.4 Regression] ~~n != n in some cases

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2008-02-27 14:13 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.0   |


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

[Bug middle-end/35390] [4.3/4.4 Regression] ~~n != n in some cases

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-02-27 14:15 ---
Fi-xed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/34971] bitfield rotates are folded and expanded wrong

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-27 14:13 ---
Subject: Bug 34971

Author: rguenth
Date: Wed Feb 27 14:12:33 2008
New Revision: 132712

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

PR middle-end/35390
* fold-const.c (fold_unary): Return the correct argument,
converted to the result type.

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

PR middle-end/34971
* fold-const.c (fold_binary): Use the types precision, not the
bitsize of the mode if folding rotate expressions.  Build rotates
only for full modes.

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

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr34971.c
branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr35390.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/fold-const.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/33387] Fortran front-end should translate intrinsics by calling C99 function instead of libgfortran functions

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2008-02-27 14:32 
---
Subject: Bug 33387

Author: fxcoudert
Date: Wed Feb 27 14:32:02 2008
New Revision: 132713

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132713
Log:
PR fortran/33387

* trans.h: Remove prototypes for gfor_fndecl_math_exponent4,
gfor_fndecl_math_exponent8, gfor_fndecl_math_exponent10 and
gfor_fndecl_math_exponent16.
* f95-lang.c (build_builtin_fntypes): Add new function types.
(gfc_init_builtin_functions): Add new builtins for nextafter,
frexp, ldexp, fabs, scalbn and inf.
* iresolve.c (gfc_resolve_rrspacing): Don't add hidden arguments.
(gfc_resolve_scale): Don't convert type of second argument.
(gfc_resolve_set_exponent): Likewise.
(gfc_resolve_size): Don't add hidden arguments.
* trans-decl.c: Remove gfor_fndecl_math_exponent4,
gfor_fndecl_math_exponent8, gfor_fndecl_math_exponent10 and
gfor_fndecl_math_exponent16.
* trans-intrinsic.c (gfc_intrinsic_map): Remove intrinsics
for scalbn, fraction, nearest, rrspacing, set_exponent and
spacing.
(gfc_conv_intrinsic_exponent): Directly call frexp.
(gfc_conv_intrinsic_fraction, gfc_conv_intrinsic_nearest,
gfc_conv_intrinsic_spacing, gfc_conv_intrinsic_rrspacing,
gfc_conv_intrinsic_scale, gfc_conv_intrinsic_set_exponent): New
functions.
(gfc_conv_intrinsic_function): Use the new functions above.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans.h


-- 


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

[Bug fortran/33387] Fortran front-end should translate intrinsics by calling C99 function instead of libgfortran functions

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2008-02-27 14:33 
---
Fixed on mainline.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/35393] New: Deep templates get 40x slower when depth goes from 17 to 18.

[jacob at math dot jussieu dot fr]

Dear G++ developers,

*PLATFORM*

GCC 4.2.3, Intel Core 1 (32 bit), Kubuntu 8.04-alpha (Debian-based).

*DESCRIPTION OF THE PROBLEM*

When using nested templates such as
A, z>, t>, u>
the optimizer seems to give up some useful optimizations when the depth is
greater than 17.

I know that the C++ standard only requires the compiler to support depth<=17,
but it still is very useful to be able to use deeper recursive templates. Also,
that's what g++'s option -ftemplate-depth-N seems to control. Unfortunately, it
doesn't seem to have any effect here.

*TESTCASE*

See attachment to this bug report (test.cpp). This is a very simple example of
Expression Templates.

$ g++ -O3 -DDEPTH17 test.cpp -o test
$ time ./test
real0m1.810s
$ g++ -O3 -DDEPTH18 test.cpp -o test
$ time ./test
real1m9.941s
$ g++ -O3 -DDEPTH18 -ftemplate-depth-20 test.cpp -o test
$ time ./test
real1m10.751s

*A MORE GENERAL QUESTION*

I hit this bug while developing an expression-templates library for linear
algebra.

This bug might have little cousins. I have observed smaller performance issues
in cases where the template depth was lower than 17, but where more complicated
things were being done.

In test.cpp, what really matters for performance is that g++ realizes that it
needs not actually construct the objects of classes Sum and Int -- it only
needs to emit the code of the value() method.

My general question would be, is there a way to hint the g++ that a given class
is a "small" "helper" class whose objects need not be actually constructed?
Something like "inline" except it'd be for a class, not a function.

g++ already does this "inlining" perfectly unless too complex things are being
done. Is there some --param that I could try passing to g++ in order to make it
handle more complex situations?


-- 
   Summary: Deep templates get 40x slower when depth goes from 17 to
18.
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacob at math dot jussieu dot fr


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

[Bug c++/35393] Deep templates get 40x slower when depth goes from 17 to 18.

[jacob at math dot jussieu dot fr]

--- Comment #1 from jacob at math dot jussieu dot fr  2008-02-27 14:48 
---
Created an attachment (id=15238)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15238&action=view)
test case referred to in first post


-- 


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

[Bug fortran/34868] ICE with -ff2c for function returning a complex number

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2008-02-27 14:51 
---
There's more to it... using the "result" syntax for the function makes it fail
even with my patch:

function f(a) result(res)
  implicit none
  real(8), intent(in) :: a(:)
  complex(8) :: res

  res = cmplx(sum(a),product(a),8)
end function f


>From the tree dump:

f (a)
{
  complex(kind=8) res;
  [...]
  *res = NON_LVALUE_EXPR ;  // Ouch, that hurts
  [...]
  return res;
}


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|patch   |


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

[Bug c++/35393] Deep templates get 40x slower when depth goes from 17 to 18.

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-27 15:19 ---
You probably hit some inliner size limits which are not connected to
-ftemplate-depth-20.  (That option should never change code generation).

g++ 4.3.0 seems to work like a charm btw.  With g++ 4.2 you can use
__attribute__((flatten)) to force recursively inling all callees of
a function.  In your case there is no separate expression kernel
evaluator, but the following will do it:

int __attribute__((flatten)) evaluate ()
{
  int i, s = 0;
  for(i = 0; i < 10; i++)
s += Int(i).add(i).add(i).add(i).add(i).add(i).add(i).add(i).add(i)
   .add(i).add(i).add(i).add(i).add(i).add(i).add(i).add(i)
#ifdef DEPTH17
   .add(i)
#endif
#ifdef DEPTH18
   .add(i).add(i)
#endif
   .value();
  return s;
}

int main()
{
  cout << evaluate() << endl;
}

With 4.3 it is still way faster because it vectorizes the reduction by
default which 4.2 can't do.  Actually for this reason it may be that
with depth18 the code gets slower because of register pressure and
bad code generation and not missed inlining.

Indeed.  With DEPTH17 you get

_Z8evaluatev:   
.LFB1471:
xorl%edx, %edx
xorl%eax, %eax
.p2align 4,,7 
.L2:
leal(%rax,%rdx,8), %eax
leal(%rax,%rdx,8), %eax
addl%edx, %eax
addl$1, %edx
cmpl$10, %edx
jne .L2
rep ; ret

while with DEPTH18 the following is generated:

_Z8evaluatev:   
.LFB1471:
subq$48, %rsp
.LCFI0:
xorl%edx, %edx
xorl%ecx, %ecx
.p2align 4,,7 
.L2:
movl%edx, -36(%rsp)
movl%edx, -40(%rsp)
movq-40(%rsp), %rax
movl%edx, -28(%rsp)
movl%edx, -32(%rsp)
movl%edx, -20(%rsp)
movl%edx, -24(%rsp)
movl%edx, -12(%rsp)
movq%rax, -120(%rsp)
movq-32(%rsp), %rax
movl%edx, -16(%rsp)
movl%edx, -4(%rsp)
movl%edx, -8(%rsp)
movl%edx, 4(%rsp)
movq%rax, -112(%rsp)
movq-24(%rsp), %rax
movl%edx, (%rsp)
movl%edx, 12(%rsp)
movl%edx, 8(%rsp)
movl%edx, 20(%rsp)
movq%rax, -104(%rsp)
movq-16(%rsp), %rax
movl%edx, 16(%rsp)
movl%edx, 28(%rsp)
movl%edx, 24(%rsp)
movq%rax, -96(%rsp)
movq-8(%rsp), %rax
movq%rax, -88(%rsp)
movq(%rsp), %rax
movq%rax, -80(%rsp)
movq8(%rsp), %rax
movq%rax, -72(%rsp)
movq16(%rsp), %rax
movq%rax, -64(%rsp)
movq24(%rsp), %rax
movq%rax, -56(%rsp)
movl-52(%rsp), %eax
addl-56(%rsp), %eax
addl-60(%rsp), %eax
addl-64(%rsp), %eax
addl-68(%rsp), %eax
addl-72(%rsp), %eax
addl-76(%rsp), %eax
addl-80(%rsp), %eax
addl-84(%rsp), %eax
addl-88(%rsp), %eax
addl-92(%rsp), %eax
addl-96(%rsp), %eax
addl-100(%rsp), %eax
addl-104(%rsp), %eax
addl-108(%rsp), %eax
addl-112(%rsp), %eax
addl-116(%rsp), %eax
addl-120(%rsp), %eax
addl%edx, %eax
addl$1, %edx
addl%eax, %ecx
cmpl$10, %edx
jne .L2
movl%ecx, %eax
addq$48, %rsp
ret

scalarization seems to give up here (not for 4.3 again).

Fixed in 4.3.0.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||missed-optimization
 Resolution||FIXED
   Target Milestone|--- |4.3.0


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

[Bug c++/35393] Deep templates get 40x slower when depth goes from 17 to 18.

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2008-02-27 15:59 ---
I tested on a x86_64 host where possibly all the string operations are
inlined (try -minline-all-stringops).  Indeed, flatten only inlines all
functions
where the body is available -- a warning is possibly not wanted in that case
(I use this attribute on functions calling into libm for example, where I don't
expect a warning for calling tan(), but still want all available bodies
inlined).

You can also use --param sra-field-structure-ratio=0 to force not using
these block copies.


-- 


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

[Bug c++/35393] Deep templates get 40x slower when depth goes from 17 to 18.

[jacob at math dot jussieu dot fr]

--- Comment #3 from jacob at math dot jussieu dot fr  2008-02-27 15:49 
---
Thank you for the quick reply. I'm glad to hear that it's fixed and much
improved in 4.3.

I tried what you said about __attribute__((flatten)) (I copied and pasted your
code) and that didn't change the performance at all (with 4.2.3). I compiled
with

g++ -O3 -DDEPTH18 test.cpp  -S -o test.s

and the generated assembly file starts as follows:

.file   "test.cpp"
.section.ctors,"aw",@progbits
.align 4
.long   _GLOBAL__I__Z8evaluatev
.text
.align 2
.p2align 4,,15
.globl _Z8evaluatev
.type   _Z8evaluatev, @function
_Z8evaluatev:
.LFB1436:
pushl   %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
pushl   %edi
.LCFI2:
pushl   %esi
.LCFI3:
xorl%esi, %esi
pushl   %ebx
.LCFI4:
xorl%ebx, %ebx
subl$172, %esp
.LCFI5:
leal-84(%ebp), %edi
.p2align 4,,7
.L2:
leal-160(%ebp), %eax
movl%ebx, -16(%ebp)
movl%ebx, -20(%ebp)
movl%ebx, -24(%ebp)
movl%ebx, -28(%ebp)
movl%ebx, -32(%ebp)
movl%ebx, -36(%ebp)
movl%ebx, -40(%ebp)
movl%ebx, -44(%ebp)
movl%ebx, -48(%ebp)
movl%ebx, -52(%ebp)
movl%ebx, -56(%ebp)
movl%ebx, -60(%ebp)
movl%ebx, -64(%ebp)
movl%ebx, -68(%ebp)
movl%ebx, -72(%ebp)
movl%ebx, -76(%ebp)
movl%ebx, -80(%ebp)
movl%ebx, -84(%ebp)
movl$72, 8(%esp)
movl%edi, 4(%esp)
movl%eax, (%esp)
callmemcpy
movl-92(%ebp), %eax
addl-96(%ebp), %eax
addl-100(%ebp), %eax
addl-104(%ebp), %eax
addl-108(%ebp), %eax
addl-112(%ebp), %eax
addl-116(%ebp), %eax
addl-120(%ebp), %eax
addl-124(%ebp), %eax
addl-128(%ebp), %eax
addl-132(%ebp), %eax
addl-136(%ebp), %eax
addl-140(%ebp), %eax
addl-144(%ebp), %eax
addl-148(%ebp), %eax
addl-152(%ebp), %eax
addl-156(%ebp), %eax
addl-160(%ebp), %eax
addl%esi, %eax
leal(%eax,%ebx), %esi
addl$1, %ebx
cmpl$10, %ebx
jne .L2
addl$172, %esp
movl%esi, %eax
popl%ebx
popl%esi
popl%edi
popl%ebp
ret
.LFE1436:
.size   _Z8evaluatev, .-_Z8evaluatev

As you can see, there is a call to memcpy() which isn't present in your
version. What can I do (if anything) to improve speed with g++ 4.2.3?

Also, isn't it a bit surprising to have a call in a function that has
__attribute__((flatten)) ? The compilation doesn't produce any warning.


-- 


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

[Bug c++/35393] Deep templates get 40x slower when depth goes from 17 to 18.

[jacob at math dot jussieu dot fr]

--- Comment #5 from jacob at math dot jussieu dot fr  2008-02-27 16:22 
---
Oh sure, I hadn't thought about that, but it makes perfect sense to not
"flatten" callees whose body source code is not available.

I tried g++-4.3 and confirm that it is much faster and doesn't suffer from that
bug.

I tried what you last suggested regarding 4.2:

$ g++ -O3 -DDEPTH18 --param sra-field-structure-ratio=0 test.cpp -o test
$ time ./test
real0m2.634s

This is much better, but still 50% slower than -DDEPTH17.

Anyway, since it is more than resolved in 4.3.0 I won't waste more of your time
with that :)

Thanks


-- 


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

[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2

[charles dot w dot lambert at gmail dot com]

--- Comment #2 from charles dot w dot lambert at gmail dot com  2008-02-27 
16:32 ---
I can confirm this bug against gcc 4.2.3 and gcc 4.3.0 on os x (10.5.2).
Apparently apple has changed the way that putenv is handled. From the `man 3 
getenv` page i quote:
"COMPATIBILITY
 putenv() no longer copies its input buffer.  This often appears in crash
logs as a
 crash in getenv().  Avoid passing local buffers or freeing the memory that
is passed
 to putenv().  Use setenv(), which still makes an internal copy of its
buffers."

I have examined the source code and found the error to be in the file
/gcc/ada/env.c near line 179 in __gnat_setenv() with the following
code:
179:  putenv (expression);
180: #if (defined (__FreeBSD__) && (__FreeBSD__ < 7)) \
181:   || defined (__APPLE__) || defined (__MINGW32__) \
182:   ||(defined (__vxworks) && ! defined (__RTP__))
183:  /* On some systems like FreeBSD 6.x and earlier, MacOS X and Windows,
184: putenv is making a copy of the expression string so we can free
185: it after the call to putenv */
186:  free (expression);
187:#endif

On current versions of OS X (10.5 on my system). This call to free on line 186
is causing all calls to getenv() after calling __gnat_setenv() to return NULL

This happens when calling gnatmake during the Initialize procedure in make.adb
near line
6645 with the following code:
6645:   declare
6646:  PATH : constant String :=
6647:   Prefix & Directory_Separator & "bin" &
6648:   Path_Separator &
6649:   Getenv ("PATH").all;
6650:   begin
6651:  Setenv ("PATH", PATH);
6652:   end;

Setenv here is located in /gcc/ada/s-os_lib.adb near line 2285
Setenv imports __gnat_setenv

I can confirm that removing the call to free fixes the problem in this bug
report. However i do not know  what proper preprocessor flags to use.


-- 

charles dot w dot lambert at gmail dot com changed:

   What|Removed |Added

 CC||charles dot w dot lambert at
   ||gmail dot com


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

[Bug tree-optimization/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2

[jacob at math dot jussieu dot fr]

--- Comment #34 from jacob at math dot jussieu dot fr  2008-02-27 16:36 
---
I retried today with

g++-4.3 (Ubuntu 4.3-20080126-1ubuntu1) 4.3.0 20080126 (experimental) [trunk
revision 131874]

and my benchmark ran in 25s compared to 20s with g++-4.2.3.

So there is certainly a lot of improvement though it's still 20% slower than
4.2.3. (This might have further improved since my 4.3 snapshot is 1 month old).


-- 


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

[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2

[pinskia at gcc dot gnu dot org]

--- Comment #35 from pinskia at gcc dot gnu dot org  2008-02-27 16:43 
---
We get:
:
  m__valuem_I_lsm.28 = 1.0e+0 - m__valuem_I_lsm.28;
  ivtmp.30 = ivtmp.30 + 1;
  if (ivtmp.30 != 1)
goto ;
  else
goto ;

or:
L2:
addl$1, %eax
movapd  %xmm1, %xmm2
subsd   %xmm0, %xmm2
cmpl$1, %eax
movapd  %xmm2, %xmm0
jne L2

or :
L2:
addl$1, %eax
cmpl$1, %eax
fsub%st, %st(1)
jne L2

All are fast.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|tree-optimization   |target


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

[Bug c++/26266] [4.0/4.1/4.2/4.3/4.4 regression] Trouble with static const data members in template classes

[bangerth at dealii dot org]

--- Comment #21 from bangerth at dealii dot org  2008-02-27 16:52 ---
Can someone check which of the testcases now work and separate
those that don't into PRs of their own? This PR has become
a bit confusing.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2

[jacob at math dot jussieu dot fr]

--- Comment #36 from jacob at math dot jussieu dot fr  2008-02-27 16:58 
---
That's great; from the assembly code I take it that you are referring tothe
last benchmark.cpp; I was referring to the first one. Again, my 4.3 is one
month old so maybe things have further improved since.


-- 


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

[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2

[bonzini at gnu dot org]

--- Comment #37 from bonzini at gnu dot org  2008-02-27 17:05 ---
Subject: Re:  [4.3/4.4 Regression] Revision 119502 causes
 significantly slower results with 4.3/4.4 compared to 4.2

jacob at math dot jussieu dot fr wrote:
> --- Comment #36 from jacob at math dot jussieu dot fr  2008-02-27 16:58 
> ---
> That's great; from the assembly code I take it that you are referring tothe
> last benchmark.cpp; I was referring to the first one. Again, my 4.3 is one
> month old so maybe things have further improved since.

No, I doubt.  The last benchmark.cpp is now fully optimized, but we 
might be missing something.

Paolo


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[uros at gcc dot gnu dot org]

--- Comment #58 from uros at gcc dot gnu dot org  2008-02-27 17:30 ---
Subject: Bug 25477

Author: uros
Date: Wed Feb 27 17:29:58 2008
New Revision: 132723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132723
Log:
PR target/25477
* config/darwin-ppc-ldouble-patch.def (BUILT_IN_NANL): Add.
(BUILT_IN_NEXTTOWARD): Remove.
(BUILT_IN_NEXTTOWARDF): Ditto.
* config/darwin.c (darwin_patch_builtin): Use ACONCAT instead of
alloca/strcpy/strcat.  Remove commented-out code.  Fix whitespace.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin-ppc-ldouble-patch.def
trunk/gcc/config/darwin.c


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[ubizjak at gmail dot com]

--- Comment #59 from ubizjak at gmail dot com  2008-02-27 17:32 ---
Fixed.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/35394] New: Agressive template instantiation?

[proy at clg dot qc dot ca]

I think recent versions of g++ (4.*, for example, but not 3.4.4) go too far
performing C++ template instantiation. Mind you, this is only a guess, and you
guys will know better.

Here's the problem case. The code shown below should (in my opinion) compile
properly as is but should not compile when the 2nd line of main() is not
commented out.

This «non-compilability» of the 2nd line is made on purpose, to simplify static
error checking, and relies on a technique similar to the one made by boost's
static assert on most platforms. The intent is to cause meaningful error
messages in cases where we can "see them coming", without preventing correct
programs to compile. In main(), the 1st line is expected to be legal and the
2nd (when it's not commented out) is illegal. What I see as a bug here is that
the code for generic class not_compilable seems to be considered even when the
code does not use it.

In more detail: the goal of the test cas below is to provoke a compile-time
failure that describes the error using the template parameter Reason in generic
class not_compilable, but only when the static int value used for factorial is
negative. This test code compiles (or does not compile, depending on the case)
fine using most compilers at my disposal (g++ 3.3* and 3.4* included) but most
of my students using g++ 4.* report that this code fails to compile even when
only the 1st line of main() is there. I would like to give you guys more info
but all g++ compilers around me seem to handle this correctly; only "recent
versions" (at least from 4.1* on) seem to mishandle it (at least if one
considers, as I do, the following technique to be valid C++).

The code follows...

// ---

//
// static_assert is provided here for clarity; remove it or
// rename it if it is provided by your compiler
//
template 
   struct static_assert;
template <>
   struct static_assert {};

//
// A class made not to compile, on purpose. Since it is generic, my
// expectation is that it should not be considered if it is not being
// used. It is syntactically correct and compiles fine (when not used)
// on older g++ (3.3* to 3.4* at least) and on all compilers at my
// disposal, as mentioned above
//
template 
   class not_compilable
   {
  enum { dummy_value = sizeof (static_assert) };
   };

//
// A class that does compile :)
//
struct compilable
{
};

//
// A static type selector
//
template 
   struct static_if_else;
template 
   struct static_if_else
   {
  typedef IfTrue type;
   };
template 
   struct static_if_else
   {
  typedef IfFalse type;
   };

//
// An empty class to add meaning when factorial does
// not compile using a negative value for N
//
class negative_value_not_accepted {};

//
// A class that should only compile when N>=0 and that
// should fail otherwise
//
template 
   struct factorial
  : private static_if_else<
   (N<0), not_compilable, compilable
>::type
   {
  enum { value = N * factorial::value };
   };
template <>
   struct factorial<0>
   {
  enum { value = 1 };
   };

//
// The test program. My understanding is that it should compile
// when only the 1st line is included and that it should not
// compile when the 2nd line is included. What I see as a bug is
// that g++ 4.1*+ seems not to accept even the 1st line, considering
// not_compilable even though it is not being used by the program...
//
#include 
using std::cout;
int main ()
{
   cout << factorial<5>::value; // Cool; should compile
   //cout << factorial<-3>::value; // should not compile
}


-- 
   Summary: Agressive template instantiation?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: proy at clg dot qc dot ca


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

[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2008-02-27 
17:49 ---
Subject: Re:  Cannot bootstrap Ada with host gnatmake-4.2

> --- Comment #2 from charles dot w dot lambert at gmail dot com  
> 2008-02-27 16:32 ---
> I can confirm this bug against gcc 4.2.3 and gcc 4.3.0 on os x (10.5.2).
> Apparently apple has changed the way that putenv is handled. From the `man 3 
> getenv` page i quote:
> "COMPATIBILITY
>  putenv() no longer copies its input buffer.  This often appears in crash
> logs as a
>  crash in getenv().  Avoid passing local buffers or freeing the memory 
> that
> is passed
>  to putenv().  Use setenv(), which still makes an internal copy of its
> buffers."
> 
> I have examined the source code and found the error to be in the file
> /gcc/ada/env.c near line 179 in __gnat_setenv() with the following
> code:
> 179:  putenv (expression);
> 180: #if (defined (__FreeBSD__) && (__FreeBSD__ < 7)) \
> 181:   || defined (__APPLE__) || defined (__MINGW32__) \
> 182:   ||(defined (__vxworks) && ! defined (__RTP__))
> 183:  /* On some systems like FreeBSD 6.x and earlier, MacOS X and Windows,
> 184: putenv is making a copy of the expression string so we can free
> 185: it after the call to putenv */
> 186:  free (expression);
> 187:#endif

It looks like setenv should be used, as in previous hunk for vxworks:

#elif defined (__vxworks) && defined (__RTP__)
  setenv (name, value, 1);

Dave


-- 


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

[Bug target/34409] MIPS: Non-optimal DWARF frame data

[daney at gcc dot gnu dot org]

--- Comment #1 from daney at gcc dot gnu dot org  2008-02-27 18:05 ---
Subject: Bug 34409

Author: daney
Date: Wed Feb 27 18:04:49 2008
New Revision: 132725

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132725
Log:
PR target/34409
* config/mips/iris.h (MIPS_DEBUGGING_INFO): Define.
* config/mips/openbsd.h (MIPS_DEBUGGING_INFO): Same.
* config/mips/sde.h (MIPS_DEBUGGING_INFO): Remove undef.
* config/mips/vxworks.h (MIPS_DEBUGGING_INFO): Same.
* config/mips/mips.h (MIPS_DEBUGGING_INFO): Remove define.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/iris.h
trunk/gcc/config/mips/mips.h
trunk/gcc/config/mips/openbsd.h
trunk/gcc/config/mips/sde.h
trunk/gcc/config/mips/vxworks.h


-- 


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

[Bug target/34409] MIPS: Non-optimal DWARF frame data

[daney at gcc dot gnu dot org]

--- Comment #2 from daney at gcc dot gnu dot org  2008-02-27 18:08 ---
Fixed on the trunk.


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libgcj/29604] Race condition in ServerSocket.accept()

[daney at gcc dot gnu dot org]

--- Comment #7 from daney at gcc dot gnu dot org  2008-02-27 18:11 ---
Unassigning as I am not working on this.


-- 

daney at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|daney at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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

[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2

[charles dot w dot lambert at gmail dot com]

--- Comment #4 from charles dot w dot lambert at gmail dot com  2008-02-27 
18:16 ---
I agree, what flags can be used to determine when to use it?
I used
...
#elif (defined (__vxworks) && defined (__RTP__)) \
   || (defined (__i386__) && (__APPLE__))
  setenv (name, value, 1);

#else
...
but i know that is most likely not the correct fix. If someone could verify
that setenv copies the input buffer on all versions of OS X then it could
simply be changed to
...
#elif (defined (__vxworks) && defined (__RTP__)) \
   || defined (__APPLE__)
  setenv (name, value, 1);

#else
...


-- 


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

[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2

[charles dot w dot lambert at gmail dot com]

--- Comment #5 from charles dot w dot lambert at gmail dot com  2008-02-27 
18:20 ---
I also forgot to add that changing to
...
#elif (defined (__vxworks) && defined (__RTP__)) \
   || defined (__APPLE__)
  setenv (name, value, 1);

#else
...
would involve changing
...
  putenv (expression);
#if (defined (__FreeBSD__) && (__FreeBSD__ < 7)) \
   || defined (__APPLE__) || defined (__MINGW32__) \
   ||(defined (__vxworks) && ! defined (__RTP__))
  /* On some systems like FreeBSD 6.x and earlier, MacOS X and Windows,
 putenv is making a copy of the expression string so we can free
 it after the call to putenv */
  free (expression);
#endif
...
to
...
  putenv (expression);
#if (defined (__FreeBSD__) && (__FreeBSD__ < 7)) \
   defined (__MINGW32__) \
   ||(defined (__vxworks) && ! defined (__RTP__))
  /* On some systems like FreeBSD 6.x and earlier, and Windows,
 putenv is making a copy of the expression string so we can free
 it after the call to putenv */
  free (expression);
#endif
...


-- 


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

[Bug fortran/35395] New: Invalid-accepted - public entity with private type should be diagnosed

[w6ws at earthlink dot net]

The following test case should be diagnosed as an error.  This is because the
type definition (e.g, X_t) is private, but the entity defined with it (abc) is
public.

module xyzzy
  implicit none
  private

  type X_t
real :: y
real :: z
  end type

  private :: X_t

  type(X_t), parameter, public :: abc = X_t (12.34, 56.78)

end module 

This was observed with several versions of gfortran, including the 4.1.0 IA64
release, the 4.3.0 20081222 snapshot for x86 windows, and the 4.4.0 20080219
snapshot for x86_64 linux.

Both ifort 10.1 and SGI IRIX f90 correctly reject the code.  Interestingly,
Salford 5.10 (wrongly) accepts it.


-- 
   Summary: Invalid-accepted - public entity with private type
should be diagnosed
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: w6ws at earthlink dot net
 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=35395

[Bug fortran/35395] Invalid-accepted - public entity with private type should be diagnosed

[w6ws at earthlink dot net]

--- Comment #1 from w6ws at earthlink dot net  2008-02-27 18:30 ---
Add keywords


-- 

w6ws at earthlink dot net changed:

   What|Removed |Added

   Keywords||accepts-invalid


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

[Bug preprocessor/35379] -MT generates a target string too long over two lines

[rwild at gcc dot gnu dot org]

--- Comment #3 from rwild at gcc dot gnu dot org  2008-02-27 18:32 ---
This isn't a regression: 3.3 has this issue, and 2.95 (which does not have
-MT) has this issue when you use
  123456789a123456789b123456789c123456789d123456789e123456789f123456789g123.c
as source file name.

The online documentation for nmake states that the target is required to start
at the beginning of the line, confirming your report with it.

Proposed patch at
.


-- 

rwild 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-27 18:32:30
   date||


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

[Bug preprocessor/35379] -MT generates a target string too long over two lines

[rwild at gcc dot gnu dot org]

--- Comment #4 from rwild at gcc dot gnu dot org  2008-02-27 18:35 ---
(In reply to comment #3)
> This isn't a regression: 3.3 has this issue, and 2.95 (which does not have
> -MT) has this issue when you use
>   123456789a123456789b123456789c123456789d123456789e123456789f123456789g123.c
> as source file name.

Erm, never mind.  2.95 did not have this issue.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||3.3.6 4.1.3 4.3.0
  Known to work||2.95


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

[Bug fortran/33197] Fortran 2008: gamma() and other small changes

[fxcoudert at gcc dot gnu dot org]

-- 

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-08-28 14:46:00 |2008-02-27 18:37:40
   date||


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

[Bug c++/35389] error in norm() of STL

[ywei at qualcomm dot com]

--- Comment #3 from ywei at qualcomm dot com  2008-02-27 20:13 ---
Subject: RE:  error in norm() of STL

I did additional test based your test code. You are right that norm()
seems to be fine. The problem happens when I try to cast the return
double value of norm() to unsigned long long (please see my test code
below and the corresponding output). Still, it bothers me that if I
carry out the norm calculation explicitly, instead of calling norm(),
there is no such an issue.

Thanks,
- Yongbin

My test code:
=
#include 
#include 

using namespace std;

main() {

   complex tt(8,1);
   double x, y;

x = norm(tt);
  double r = tt.real(), i = tt.imag();
  y = r*r + i*i;

cout << tt << "\t" << (unsigned long long)x << "\t" << (unsigned
long long)y << endl;
cout << tt << "\t" << x << "\t" << y << endl;
}
==
The output
(8,1)   64  65
(8,1)   65  65 

-Original Message-
From: rguenth at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 27, 2008 4:44 AM
To: Wei, Yongbin
Subject: [Bug c++/35389] error in norm() of STL



--- Comment #2 from rguenth at gcc dot gnu dot org  2008-02-27 12:43
---
I used:

#include 
#include 
#include 

int main()
{
  std::complex x(8, 1);
  std::cout << std::norm(x) << std::endl;
}


-- 


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

[Bug c++/35389] error in norm() of STL

[pluto at agmk dot net]

--- Comment #4 from pluto at agmk dot net  2008-02-27 20:30 ---
Subject: Re:  error in norm() of STL

On Wednesday 27 of February 2008 21:13:13 ywei at qualcomm dot com wrote:
> --- Comment #3 from ywei at qualcomm dot com  2008-02-27 20:13 ---
> Subject: RE:  error in norm() of STL
>
> I did additional test based your test code. You are right that norm()
> seems to be fine. The problem happens when I try to cast the return
> double value of norm() to unsigned long long (please see my test code
> below and the corresponding output). Still, it bothers me that if I
> carry out the norm calculation explicitly, instead of calling norm(),
> there is no such an issue.
>
> Thanks,
> - Yongbin
>
> My test code:
> =
> #include 
> #include 
>
> using namespace std;
>
> main() {
>
>complex tt(8,1);
>double x, y;
>
> x = norm(tt);
>   double r = tt.real(), i = tt.imag();
>   y = r*r + i*i;
>
> cout << tt << "\t" << (unsigned long long)x << "\t" << (unsigned
> long long)y << endl;
> cout << tt << "\t" << x << "\t" << y << endl;
> }
> ==
> The output
> (8,1)   64  65
> (8,1)   65  65

$ ./a.out
(8,1)   64  65
(8,1)   64.985789   65

(long long)64.9 -> 64.


--- Comment #5 from pluto at agmk dot net  2008-02-27 20:30 ---
Created an attachment (id=15239)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15239&action=view)


-- 


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

[Bug c++/35389] error in norm() of STL

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-02-27 20:38 ---
This is just the non bug with respect of percussion.

See http://gcc.gnu.org/bugs.html#nonbugs_general




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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[pinskia at gcc dot gnu dot org]

--- Comment #103 from pinskia at gcc dot gnu dot org  2008-02-27 20:38 
---
*** Bug 35389 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ywei at qualcomm dot com


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

[Bug fortran/33197] Fortran 2008: gamma() and other small changes

[fxcoudert at gcc dot gnu dot org]

--- Comment #6 from fxcoudert at gcc dot gnu dot org  2008-02-27 21:02 
---
Two more remarks on that: ASINH, ACOSH and ATANH need to accept COMPLEX
arguments. Some other functions also should be extended that way (ASIN, ACOS...
and probably many more).

Also, one very annoying feature: BESSEL_JN and BESSEL_YN have two forms, with 2
or 3 arguments. What's more, these two forms have very different properties
(the first one is elemental, the second one is transformational), and I don't
know how to implement that in the current handling of intrinsics!


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[dominiq at lps dot ens dot fr]

--- Comment #60 from dominiq at lps dot ens dot fr  2008-02-27 21:26 ---
(In reply to comment #53)

> Oops, sorry, fixed by rev. 132621.

Now I get:

XPASS: gfortran.dg/large_real_kind_3.F90  -O0  (test for excess errors)
FAIL: gfortran.dg/large_real_kind_3.F90  -O0  execution test
XPASS: gfortran.dg/large_real_kind_3.F90  -O1  (test for excess errors)
XPASS: gfortran.dg/large_real_kind_3.F90  -O2  (test for excess errors)
XPASS: gfortran.dg/large_real_kind_3.F90  -O3 -fomit-frame-pointer  (test for
excess errors)
XPASS: gfortran.dg/large_real_kind_3.F90  -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
XPASS: gfortran.dg/large_real_kind_3.F90  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
XPASS: gfortran.dg/large_real_kind_3.F90  -O3 -g  (test for excess errors)
XPASS: gfortran.dg/large_real_kind_3.F90  -Os  (test for excess errors)

in both 32 and 64 bit modes. I think the xpass are normal as the optimized dump
is:

;; Function MAIN__ (MAIN__)

Analyzing Edge Insertions.
MAIN__ ()
{
  static integer(kind=4) options.0[7] = {68, 127, 0, 0, 0, 1, 0};

:
  _gfortran_set_options (7, &options.0);
  if (2.9236712223862218652692294906906497118927045376e-17 /
9.59864575062830072127439962059725075960159301758e-1 >
9.9993922529029077850282192230224609375e-9)
goto ;
  else
goto ;

:
  _gfortran_abort ();

:
  if (5.87424647807422190473069128537003046257953999681e-17 /
1.13897071699133300981543470697943121194839477539e+0 >
9.9993922529029077850282192230224609375e-9)
goto ;
  else
goto ;

:
  _gfortran_abort ();

:
  return;

}

Also I don't understand why there is a test for "excess errors".


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[bonzini at gnu dot org]

--- Comment #61 from bonzini at gnu dot org  2008-02-27 21:32 ---
Subject: Re:  builtin functions should use $LDBL128 suffix
 on darwin when appropriate

I think it depends on the version of mpfr that you have installed?

> Also I don't understand why there is a test for "excess errors".

Errors/warnings not matching a dg-error.


-- 


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

[Bug rtl-optimization/323] optimized code gives strange floating point results

[ywei at qualcomm dot com]

--- Comment #104 from ywei at qualcomm dot com  2008-02-27 21:41 ---
Subject: RE:  optimized code gives strange floating point results

Not sure this is the same issues as 323. All three numbers, 8, 1 and 65,
should be able to represented in IEEE 754 floating-point format exactly
without any rounding or approximation. That is
 8 = 1* 2^3
  1 = 1* 2^0
  65  = (1 + 1/64) * 2^6


-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 27, 2008 12:39 PM
To: Wei, Yongbin
Subject: [Bug rtl-optimization/323] optimized code gives strange
floating point results



--- Comment #103 from pinskia at gcc dot gnu dot org  2008-02-27
20:38 ---
*** Bug 35389 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added


 CC||ywei at qualcomm dot
com


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

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

[Bug preprocessor/35379] -MT generates a target string too long over two lines

[rwild at gcc dot gnu dot org]

--- Comment #5 from rwild at gcc dot gnu dot org  2008-02-27 21:43 ---
Subject: Bug 35379

Author: rwild
Date: Wed Feb 27 21:42:23 2008
New Revision: 132727

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132727
Log:
libcpp:
PR preprocessor/35379
* mkdeps.c (deps_write): Ensure the first target always appears
in the first column, without leading backslash newline.  Avoid
some more extra whitespace.

Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/mkdeps.c


-- 


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

[Bug preprocessor/35379] -MT generates a target string too long over two lines

[rwild at gcc dot gnu dot org]

--- Comment #6 from rwild at gcc dot gnu dot org  2008-02-27 21:53 ---
Fixed in 4.4.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/35387] __PRETTY_FUNCTION__ produces inconsistent output

[d dot frey at gmx dot de]

--- Comment #4 from d dot frey at gmx dot de  2008-02-27 21:58 ---
More information:

I checked out the trunk and checked it again. The bug is still present, but
while testing it, I noticed that the problem does not occur with my own types,
only with types from the standard library. Here's the code I used:

#include 

template< typename X, typename Y > struct P {};

template< typename > struct A;

template< typename T, typename U >
struct A< P< T, U > >
{ static void f() { int i; } };

template< typename V, typename W >
struct A< std::pair< V, W > >
{ static void f() { int i; } };

int main()
{
  A< P< int, double > >::f();
  A< std::pair< int, double > >::f();
}

and the output is:

[EMAIL PROTECTED]:~/work/test/foo$
/home/frey/work/svn/gcc/host-i686-pc-linux-gnu/gcc/g++
-B/home/frey/work/svn/gcc/host-i686-pc-linux-gnu/gcc/ -ansi -pedantic -Wall
-Wextra 
-I/home/frey/work/svn/gcc/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/home/frey/work/svn/gcc/i686-pc-linux-gnu/libstdc++-v3/include
-I/home/frey/work/svn/gcc/libstdc++-v3/libsupc++ foo.cpp -c -o foo
foo.cpp: In static member function ‘static void A >::f() [with T = int,
U = double]’:
foo.cpp:12:   instantiated from here
foo.cpp:7: warning: unused variable ‘i’
foo.cpp: In static member function ‘static void A >::f()
[with V = int, W = double]’:
foo.cpp:13:   instantiated from here
foo.cpp:8: warning: unused variable ‘i’
[EMAIL PROTECTED]:~/work/test/foo$
/home/frey/work/svn/gcc/host-i686-pc-linux-gnu/gcc/g++ --version
g++ (GCC) 4.4.0 20080227 (experimental)
[snip]


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[fxcoudert at gcc dot gnu dot org]

--- Comment #62 from fxcoudert at gcc dot gnu dot org  2008-02-27 22:28 
---
That new testcase fails under Darwin at -O0 (because of a faulty libm) and
passes with optimization turned on (because the middle-end is very clever). So,
there two solutions are: either have 1 FAIL (-O0) and the rest PASS, like I had
before; or have 1XFAIL and the rest XPASS, which is was we have after my last
commit.

The first situation was clearly better, but I was at work when Dominique
emailed my after my first commit, saying the new testcase FAILed, and I got
confused. I think I'll revert to the old situation, and we'll live with that
one FAIL until Apple fixes the bug or the universe stops expanding and
condenses into a single point of pure energy, whichever happens first. (My
money is on the second guess.)


-- 


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

[Bug c++/35387] __PRETTY_FUNCTION__ produces inconsistent output

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-02-27 22:45 ---
This is most likely a dup of bug 99.


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[dominiq at lps dot ens dot fr]

--- Comment #63 from dominiq at lps dot ens dot fr  2008-02-27 22:52 ---
(In reply to comment #62)
I have nothing against FAIL (I am not fond of XFAIL that in my opinion hide the
problem). I reported the failures because I understood that they were not
expected. If now they will, it fine with me.


-- 


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

[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.

[gnu_andrew at member dot fsf dot org]

--- Comment #6 from gnu_andrew at member dot fsf dot org  2008-02-27 23:00 
---
The new structure is committed.  As StringBuilder is final, we will have to
clone AbstractStringBuilder in the gnu.classpath package.  This is not too
problematic, as we don't expect the internal class to need to change.


-- 

gnu_andrew at member dot fsf dot org changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Last reconfirmed|2008-02-17 15:58:22 |2008-02-27 23:00:53
   date||


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

[Bug ada/33857] Cannot bootstrap Ada with host gnatmake-4.2

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2008-02-28 
01:41 ---
Subject: Re:  Cannot bootstrap Ada with host gnatmake-4.2

> but i know that is most likely not the correct fix. If someone could verify
> that setenv copies the input buffer on all versions of OS X then it could
> simply be changed to

It does on 10.3.9.  Doubt that we need to be overly concerned about
earlier OS X versions.

I tried the setenv change with 4.2.3.  Had to apply the "-larg -lgcc_eh"
hack to Make-lang.in to do an initial bootstrap.  After installing this
build, the hack isn't needed.  I'll post testresults for 4.2.3 on 10.5.2
soon.

Dave


-- 


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

[Bug fortran/35381] Misleading error message with derived types: Exponent at (1) must be INTEGER for an initialization expression

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-02-28 04:59 
---
Yes, of course we just bumped to 4.4 a few days ago.


-- 


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

[Bug c++/35396] New: possible incorrect opitmization due to missed dependency

[kimwooyoung at gmail dot com]

configured with ../gcc-4.3-20080208/configure --enable-languages=c,c++,java

The same issue was also observed on i686-pc-linux x86-64 platforms.

>Description:
when an assignment to a variable is followed by 'cmpxchg' on the 
variable, there exists a dependency between the two statements.  
thus, the store has to complete before cmpxchg on the variable would 
be issued.  
The issue was not seen with -O0.  It was seen when compiled with -O2.
I have not tried -O1, though.
For examples, when we have

inline bool LockByte( volatile unsigned char &flag ) {
volatile void *f = &flag;
if ( CompareAndSwap1(f,1,0) != 0) {
do {
 __asm__ __volatile__("pause;");
} while ( CompareAndSwap1(f,1,0) != 0) ;
}
return 0;
}
main(...) {
...
char x = 0;
LockByte(x);
...
}
   even with a single thread, LockByte() hangs i.e., spins forever.
   It appears that the compiler misses the dependency and does not
   generate the store to the memory location.
>How-To-Repeat:

Compile the following program with -O2 option. i.e.,
g++ -O2 .  It hangs.  g++  generates an executable
that completes and prints 'done'.
#include 
#include 
#define DECL_CMPSWP(S,T,X) \
static inline T machine_cmpswp##S (volatile void *ptr, T value, T comparand ) \
{ \
T result; \
  \
__asm__ __volatile__("lock\ncmpxchg" X " %2,%1" \
 : "=a"(result), "=m"(*(T *)ptr) \
 : "q"(value), "0"(comparand)   \
 : "memory"); \
return result; \
}
DECL_CMPSWP(1,unsigned char,"b");
#define CompareAndSwap1(a,b,c) machine_cmpswp1(a,b,c)
inline bool LockByte( volatile unsigned char &flag ) {
volatile void *f = &flag;
if ( CompareAndSwap1(f,1,0) != 0) {
do {
 __asm__ __volatile__("pause;");
} while ( CompareAndSwap1(f,1,0) != 0) ;
}
return 0;
}
static void TestTinyLock() {
unsigned char flags[16];
for( int i=0; i<16; ++i )
flags[i] = i;
flags[8] = 0;
LockByte(flags[8]);
for( int i=0; i<16; ++i )
assert( flags[i]==(i==8?1:i) );
}

int main( int argc, char* argv[] ) {
try {
TestTinyLock();
} catch(...) {
}
printf("done\n");
return 0;
}
-
'g++ -O2 -S' output
pushl   %ecx
leal-16(%ebp), %eax
subl$88, %esp
movl%eax, -52(%ebp)
leal-84(%ebp), %eax
movl$___gxx_personality_sj0, -60(%ebp)
movl$LLSDA6, -56(%ebp)
movl$L13, -48(%ebp)
movl%esp, -44(%ebp)
movl%eax, (%esp)
call__Unwind_SjLj_Register
call___main
xorl%eax, %eax
leal-32(%ebp), %edx
.p2align 4,,7
L2:
movb%al, (%edx,%eax)
addl$1, %eax
cmpl$16, %eax
jne L2
leal-24(%ebp), %ebx
xorl%eax, %eax
movl$1, %edx
/APP
 # 44 "test_test.cpp" 1
lock
cmpxchgb %dl,(%ebx)
 # 0 "" 2
/NO_APP
testb   %al, %al
je  L3
movl$1, %ecx
xorl%edx, %edx
.p2align 4,,7
L14:
/APP
 # 52 "test_test.cpp" 1
pause;
 # 0 "" 2
/NO_APP
movl%edx, %eax
/APP
 # 44 "test_test.cpp" 1
lock
cmpxchgb %cl,(%ebx)
 # 0 "" 2
/NO_APP
testb   %al, %al
jne L14
L3:
movl$0, -88(%ebp)
jmp L8
.p2align 4,,7
L6:
movzbl  %al, %eax
cmpl%edx, %eax
je  L7
movl$LC0, 8(%esp)
movl$66, 4(%esp)
movl$LC1, (%esp)
movl$1, -80(%ebp)
call___assert
L7:
addl$1, -88(%ebp)
cmpl$16, -88(%ebp)
je  L9
L8:

>Fix:
The work-around is to declare the variabe to be 'volatile'
If we do 
* (volatile unsigned char *) &flags[8] = 0;
instead, the generated executable completes.


-- 
   Summary: possible incorrect opitmization due to missed dependency
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kimwooyoung at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin


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

[Bug c++/35396] possible incorrect opitmization due to missed dependency

[kimwooyoung at gmail dot com]

--- Comment #1 from kimwooyoung at gmail dot com  2008-02-28 06:35 ---
Created an attachment (id=15240)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15240&action=view)
a test file to re-produce the issue

to reproduce the issue, compile it with 'g++ -O2 '


-- 


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

[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)

[uros at gcc dot gnu dot org]

--- Comment #32 from uros at gcc dot gnu dot org  2008-02-28 07:09 ---
Subject: Bug 24685

Author: uros
Date: Thu Feb 28 07:08:51 2008
New Revision: 132737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132737
Log:
PR target/25477
* gcc/config/darwin-protos.h: Add darwin_patch_builtins prototype.
* gcc/config/darwin-ppc-ldouble-patch.def: New file.
* gcc/config/rs6000/darwin.h (SUBTARGET_INIT_BUILTINS): New macro.
* gcc/config/rs6000/rs6000.c (rs6000_init_builtins): Call
SUBTARGET_INIT_BUILTINS if defined.
* gcc/config/darwin.c (darwin_patch_builtin,
darwin_patch_builtins): New functions. 

fortran/ChangeLog:

PR target/25477
* trans-expr.c (gfc_conv_power_op): Use BUILT_IN_CPOW{F,,L}.
* f95-lang.c (gfc_init_builtin_functions): Define BUILT_IN_CPOW{F,,L}.
* trans.h (gfor_fndecl_math_cpow, gfor_fndecl_math_cpowf,
gfor_fndecl_math_cpowl10, gfor_fndecl_math_cpowl16): Remove.
* trans-decl.c: Likewise.

testsuite/ChangeLog:

PR libfortran/24685
* gfortran.dg/large_real_kind_form_io_2.f90: XFAIL on
powerpc*-apple-darwin*.
* gfortran.dg/large_real_kind_2.F90: Split testing of ERF and
ERFC into gfortran.dg/large_real_kind_3.F90.
* gfortran.dg/large_real_kind_3.F90: New test.


Added:
branches/gcc-4_3-branch/gcc/config/darwin-ppc-ldouble-patch.def
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/large_real_kind_3.F90
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/darwin-protos.h
branches/gcc-4_3-branch/gcc/config/darwin.c
branches/gcc-4_3-branch/gcc/config/rs6000/darwin.h
branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/f95-lang.c
branches/gcc-4_3-branch/gcc/fortran/trans-decl.c
branches/gcc-4_3-branch/gcc/fortran/trans-expr.c
branches/gcc-4_3-branch/gcc/fortran/trans.h
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/large_real_kind_2.F90
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/large_real_kind_form_io_2.f90


-- 


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

[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate

[uros at gcc dot gnu dot org]

--- Comment #64 from uros at gcc dot gnu dot org  2008-02-28 07:09 ---
Subject: Bug 25477

Author: uros
Date: Thu Feb 28 07:08:51 2008
New Revision: 132737

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132737
Log:
PR target/25477
* gcc/config/darwin-protos.h: Add darwin_patch_builtins prototype.
* gcc/config/darwin-ppc-ldouble-patch.def: New file.
* gcc/config/rs6000/darwin.h (SUBTARGET_INIT_BUILTINS): New macro.
* gcc/config/rs6000/rs6000.c (rs6000_init_builtins): Call
SUBTARGET_INIT_BUILTINS if defined.
* gcc/config/darwin.c (darwin_patch_builtin,
darwin_patch_builtins): New functions. 

fortran/ChangeLog:

PR target/25477
* trans-expr.c (gfc_conv_power_op): Use BUILT_IN_CPOW{F,,L}.
* f95-lang.c (gfc_init_builtin_functions): Define BUILT_IN_CPOW{F,,L}.
* trans.h (gfor_fndecl_math_cpow, gfor_fndecl_math_cpowf,
gfor_fndecl_math_cpowl10, gfor_fndecl_math_cpowl16): Remove.
* trans-decl.c: Likewise.

testsuite/ChangeLog:

PR libfortran/24685
* gfortran.dg/large_real_kind_form_io_2.f90: XFAIL on
powerpc*-apple-darwin*.
* gfortran.dg/large_real_kind_2.F90: Split testing of ERF and
ERFC into gfortran.dg/large_real_kind_3.F90.
* gfortran.dg/large_real_kind_3.F90: New test.


Added:
branches/gcc-4_3-branch/gcc/config/darwin-ppc-ldouble-patch.def
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/large_real_kind_3.F90
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/darwin-protos.h
branches/gcc-4_3-branch/gcc/config/darwin.c
branches/gcc-4_3-branch/gcc/config/rs6000/darwin.h
branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/f95-lang.c
branches/gcc-4_3-branch/gcc/fortran/trans-decl.c
branches/gcc-4_3-branch/gcc/fortran/trans-expr.c
branches/gcc-4_3-branch/gcc/fortran/trans.h
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/large_real_kind_2.F90
   
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/large_real_kind_form_io_2.f90


-- 


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