[Bug ada/39793] New: gnatxref generates incomplete output for overloaded operator
This bug report only concerns gnatxref not the gnat compiler.
Given the following :
package bug_op is
type Vector is array (1 .. 1) of Integer;
function "&"(A, B : Vector) return Vector;
end bug_op;
with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
package body bug_op is
V : Vector;
function "&"(A, B : Vector) return Vector is
begin
return Vector'(1 => 42);
end "&";
begin
V := Vector'(1 => 1) & Vector'(1 => 1);
Put(V(1), 0);
end bug_op;
the .ali files contains the line:
4V10*"&"{3A6}<3p6> 4>14 4>17 14|4b10 7l5 7t8 10r24
which is correct, but gnat xref only outputs:
"&" function
Decl: bug_op.ads 4:10
(i.e. it is missing the body and reference)
if the "&" is changed to a "+" in the original code the .ali file contains:
4V10*"+"{3A6} 4>14 4>17 14|4b10 7l5 7t8 10r24
and gnatxref gets it and outputs the correct references:
"+" function
Decl: bug_op.ads 4:10
Body: bug_op.adb 4:10
Ref: bug_op.adb10:24
Note that gnatxref shipped with gnat 3.4.2 behaves properly in both
circumstances.
Sincerely,
David
http://www.midoan.com
--
Summary: gnatxref generates incomplete output for overloaded
operator
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david at midoan dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39793
[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-04-17 08:26 --- Ah. I see what goes on then. The new logic assumes that GOMP_barrier does not change shrd (which is a local non-address-taken static variable in main, accessed from the OMP clone main.omp_fn.0). This is of course true, but nothing in GCC knows about threads - instead we rely on the builtins to act as optimization barriers. The patch breaks this assumption. I will revert the broken part for now. -- 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|2009-04-16 18:45:47 |2009-04-17 08:26:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
[Bug testsuite/39792] g++.dg/ext/complit11.C failed
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-17 08:47 --- Subject: Bug 39792 Author: jakub Date: Fri Apr 17 08:46:52 2009 New Revision: 146223 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146223 Log: PR testsuite/39792 * g++.dg/ext/complit11.C: Add empty dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/complit11.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39792
[Bug testsuite/39792] g++.dg/ext/complit11.C failed
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-17 08:54 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39792
[Bug middle-end/39794] New: Miscompile with -O2 -funroll-loops
The following testcase aborts with -O2 -funroll-loops, but passes with plain
-O2 for me on today's trunk.
--cut here
extern void abort();
void foo(int *a, int n)
{
int i;
for (i = 0; i < n; i++)
{
a[i] *= 2;
a[i+1] = a[i-1] + a[i-2];
}
}
enum {N = 16};
int a[N];
int ref[N] = {0, 1, 4, 2, 10, 12, 24, 44, 72, 136, 232, 416, 736, 1296, 2304,
2032};
int main()
{
int i;
for (i = 0; i < N; i++)
a[i] = i;
foo(a + 2, N - 3);
for (i = 0; i < N; i++)
if (ref[i] != a[i])
abort();
return 0;
}
-- cut here
--
Summary: Miscompile with -O2 -funroll-loops
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: abel at gcc dot gnu dot org
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug libstdc++/38132] basic_string.tcc methods not declared inline
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-17 10:12 --- Frankly, I don't think this is an issue. What we really want, is that all inline functions get inlined anyway, debug mode or not, and this is correctly happening, as far as I can see. Out of line functions are expected to not be inlined, even at -O3, because of the extern templates, indeed. All in all, also considering other metrics, like compile-time performance, code-size, and the ABI-impact of anything having to do with strings, I don't believe this is going to change any time soon. To repeat, the maintainers are well aware that, due to extern inline, out of line functions are not inlined even at -O3, but that is believed to be a good compromise, in general, outside the case of some special micro-benchmarks. It's definitely a well known design choice, which existed for string since the very beginning of the project. For this specific micro-benchmark, the performance difference in debug-mode is noticeable only in 4.3.x, it wasn't in 4.2.x, probably because we are now inlining large functions a bit more easily. Actually the suppression of extern inline in debug-mode is just an historical accident, necessary in order to make sure debug-mode works also for the very special case of strings (vs all the standard containers). Some maintainers argued at length *against* it, because indeed it's sort of an hack, you can find something in the archive about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug libstdc++/38132] basic_string.tcc methods not declared inline
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-17 09:23 --- We had this for a short time but then see 2009-02-24 Richard Guenther PR c++/39242 * pt.c (instantiate_decl): Do not instantiate extern, non-inline declared functions. thus, if the functions would be marked inline we should still instantiate them (otherwise we run into standard conformance issues like in that PR). I also seem to remember that we hide implementation details of these functions to be able to change them without breaking the ABI. But Paolo likely knows more. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ Summary|extern template prohibits |basic_string.tcc methods not |inlining|declared inline http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug c++/37949] static initialisation through pointer deferred until run time
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-17 09:18 --- This would be "inlining" of static-initialization-and-destruction functions if they get optimized to return a constant initializer. It's not easy to do as they cannot be easily removed late in the compilation. Of course this particular simple case can be handled by folding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37949
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
-- amonakov at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.0 4.5.0 Known to work||4.3.2 Priority|P3 |P5 Summary|Miscompile with -O2 - |[4.4/4.5 Regression] |funroll-loops |Miscompile with -O2 - ||funroll-loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-04-17 10:29 --- Subject: Bug 39746 Author: rguenth Date: Fri Apr 17 10:29:26 2009 New Revision: 146240 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146240 Log: 2009-04-17 Richard Guenther PR tree-optimization/39746 * tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Remove special-casing for builtins and static variable use/def. (call_may_clobber_ref_p_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug fortran/39795] New: Support round-to-zero in Fortran front-end
On the SPU, all single-precision floating-point arithmetic always takes place in round-to-zero rounding mode. The Fortran front-end always assumes round-to-nearest mode. This causes a number of issues: - Both real->string and string->real transformations (e.g. printf, scanf) operate in round-to-zero mode. This means that a round-trip transform will often not yield an identical result; this causes e.g. the default_format_1.f90 test case to fail. It seems this cannot be fixed as the behaviour of printf and scanf is specified to follow round-to-zero on the SPU ... - As a special case of the real->string->real round-trip transform problem, the value of GFC_REAL_4_HUGE from the (generated) kinds.h does not convert to the largest real when read back in, but its immediate predecessor. This causes the scalar_mask_2.f90 test case to fail. This can be fixed by using rounding away from zero when generating the string constant that is written to the kinds.h file. - Compile-time operations performed by the Fortran front-end are always done in round-to-nearest mode. This results in different results as compared to executing the corresponding operations at run-time. This causes e.g. the integer_exponentiation_3.F90 test case to fail. This can be fixed by having the Fortran front-end check the target floating format rounding mode, and using this mode to perform compile-time operations in. -- Summary: Support round-to-zero in Fortran front-end Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: uweigand at gcc dot gnu dot org GCC target triplet: spu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39795
[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-04-17 10:29 --- Fixed. -- 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=39746
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
--- Comment #13 from ramana at gcc dot gnu dot org 2009-04-17 11:07 --- Created an attachment (id=17650) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17650&action=view) Patch being tested Here is a rather hackish patch that I'm testing. It looks correct so far with the case of builtin_setjmp and builtin_longjmp and works correctly in cases where you have setjmp and longjmp across ARM and Thumb ISA states. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P5 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-17 12:19 ---
-fno-ivopts also fixes this. The unrolling happening on the RTL level
for the loop in foo() somehow is broken.
We end up with
(gdb) p a
$1 = {0, 1, 4, 2, 10, 12, 24, 44, 72, 18, 20, 22, 24, 26, 28, 50}
(gdb) p ref
$2 = {0, 1, 4, 2, 10, 12, 24, 44, 72, 136, 232, 416, 736, 1296, 2304, 2032}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-04-17 12:19:28
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug libstdc++/38132] basic_string.tcc methods not declared inline
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-17 10:50 --- Thus, wontfix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug c++/39786] [4.3/4.4/4.5 Regression] Qualified name lookup through different numbers of using directives
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-17 09:14 --- Confirmed. The code was accepted with 3.3.6 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail|4.1.2 4.3.2 |4.1.2 4.3.2 4.5.0 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2009-04-17 09:14:10 date|| Summary|Qualified name lookup |[4.3/4.4/4.5 Regression] |through different numbers of|Qualified name lookup |using directives|through different numbers of ||using directives Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39786
[Bug libstdc++/38132] basic_string.tcc methods not declared inline
--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-17 10:27 --- Of course s/extern inline/extern template -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug ada/35953] Socket stream subprograms incorrectly handling null arrays
--- Comment #1 from charlet at gcc dot gnu dot org 2009-04-17 13:39 --- Subject: Bug 35953 Author: charlet Date: Fri Apr 17 13:39:10 2009 New Revision: 146267 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146267 Log: 2009-04-17 Thomas Quinot PR ada/35953 * g-socthi-vms.adb, g-socthi-vms.ads, g-socthi-vxworks.adb, g-socthi-vxworks.ads, g-socthi-mingw.adb, g-socthi-mingw.ads, g-socthi.adb, g-stsifd-sockets.adb, g-socthi.ads, g-socket.adb, g-socket.ads (GNAT.Sockets.Thin.C_Send, GNAT.Sockets.Thin.Syscall_Send): Remove unused subprograms. Replace calls to send(2) with equivalent sendto(2) calls. (GNAT.Sockets.Send_Socket): Factor common code in inlined subprogram. (GNAT.Sockets.Write): Account for the case of hyper-empty arrays, do not report an error in that case. Factor code common to the two versions (datagram and stream) in common routine Stream_Write. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/g-socket.adb trunk/gcc/ada/g-socket.ads trunk/gcc/ada/g-socthi-mingw.adb trunk/gcc/ada/g-socthi-mingw.ads trunk/gcc/ada/g-socthi-vms.adb trunk/gcc/ada/g-socthi-vms.ads trunk/gcc/ada/g-socthi-vxworks.adb trunk/gcc/ada/g-socthi-vxworks.ads trunk/gcc/ada/g-socthi.adb trunk/gcc/ada/g-socthi.ads trunk/gcc/ada/g-stsifd-sockets.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35953
[Bug ada/35953] Socket stream subprograms incorrectly handling null arrays
--- Comment #2 from charlet at gcc dot gnu dot org 2009-04-17 13:41 --- Fixed on trunk -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35953
[Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible
libstdc++ ensures that cin/cout/cerr are constructed before they are used, but
the scheme fails when using constructor priorities. Constructors with a
priority are run before constructors without a priority, which is the
appropriate behaviour. However, this means that this program:
#include
void f1() __attribute__ ((constructor (101)));
void f1() { std::cout << "f1" << std::endl; }
int main() { }
will crash at runtime. f1 will be run at a user level priority, but it will
run before std::cout is initialized.
I suggest that on systems which support constructor priorities, that we arrange
to run ios_base::Init::Init() at a high priority. The destructor should also
be run at a high priority, of course.
--
Summary: cin/cout/cerr constructors should run at high priority
when possible
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-17 15:06 --- I see. I would be tempted to ask you to propose a fix at once, seems pretty simple, basically a bit of configury and very few lines of actual code. However, I wonder if we have something similar elsewhere, I seem to remember something for the memory allocators, for example, but possibly by now we have static locals everywhere to avoid completely running into such priority issues. Another area which probably should be audited is that of locale. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
[Bug c++/39797] New: Segmentation fault g++
Version Info:
Using built-in specs.
Target: i486-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
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Command line:
g++ --save-temp snippet.cpp
snippet.cpp:21: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
--- SOURCE CODE BEGIN ---
#include
class MatrixBase {
public:
virtual ~MatrixBase() {}
virtual const size_t M() const = 0 ;
virtual const size_t N() const = 0 ;
} ;
template class Matrix : public MatrixBase {
public:
Matrix() {}
~Matrix() {}
const double & operator()( size_t m, size_t n ) const {
if ( m < M && n < N ) {
return m_array[ m ][ n ] ;
} else {
throw Exception( "Matrix indices out of bounds" ) ;
}
}
Matrix & operator*=( double f ) {
for ( size_t m = 0; m < M; ++m ) {
for ( size_t n = 0; n < N; ++n ) {
m_array[ m ][ n ] *= f ;
}
}
return *this ;
}
const size_t M() const { return M ; }
const size_t N() const { return N ; }
typedef T size_type ;
private:
T m_array[ M ][ N ] ;
} ;
int main( int argc, char * argv[] )
{
return 0 ;
}
--- SOURCE CODE END ---
--
Summary: Segmentation fault g++
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stephanemarcotte at 3d-p dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug c++/39797] Segmentation fault g++
--- Comment #1 from stephanemarcotte at 3d-p dot com 2009-04-17 15:27 --- Created an attachment (id=17651) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17651&action=view) Source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug c++/39797] Segmentation fault g++
--- Comment #2 from stephanemarcotte at 3d-p dot com 2009-04-17 15:27 --- Created an attachment (id=17652) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17652&action=view) the .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug c++/39797] Segmentation fault g++
--- Comment #3 from stephanemarcotte at 3d-p dot com 2009-04-17 15:38 --- Isolate to the method: Matrix::Matrix & operator*=( double f ) ... The template takes 2 args, but the above makes g++ crash. If I take out one parameter (e.g., Matrix), then I get a compiler error as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug c++/39797] Segmentation fault g++
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-17 15:40 --- I can reproduce only with 4_2-branch (no longer maintained) and 4_3-branch. I can't with 4_4-branch and mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug c++/39797] Segmentation fault g++
--- Comment #5 from stephanemarcotte at 3d-p dot com 2009-04-17 15:41 --- Also, if I remove the derivation from the MatrixBase abstract base class, the error disappears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug c++/39797] Segmentation fault g++
--- Comment #6 from stephanemarcotte at 3d-p dot com 2009-04-17 15:45 --- the template also declares the methods M() and N(), when M, N are also template parameters. (The code snippet is obviously buggy.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug target/27263] armv5te-linux-gnueabi-gcc-4.1 fails to compile libquicktime-0.9.7-0.4/plugins/opendivx/encore50/text_code_mb.c
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-17 16:41 --- As per comment above appears fixed in all release branches today. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27263
[Bug c++/39798] New: would like flag to disable constructors for built-in types
In C++, the statement 'k = int()' will zero 'k'. This somewhat inconsistent behavior (e.g. initialize a struct with a default constructor is a no-op) is somewhat annoying because it results in all STL containers zeroing their contents. I've encountered a few rare cases where this resulted in a significant performance hit but the most annoying part is that it prevents tools like valgrind from detecting the use uninitialized values taken from STL containers. It would be nice if g++ had a flag to optionally disable this behavior (make the constructors for build-in types be no-ops.) -- Summary: would like flag to disable constructors for built-in types Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kraftche at cae dot wisc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39798
[Bug regression/39799] New: missing 'may be used uninitialized' warning
The following code:
inline int foo(int x)
{
return x;
}
static void bar(int a, int *ptr)
{
do
{
int b;
if (b < 40)
{
ptr[0] = b;
}
b += 1;
ptr++;
}
while (--a != 0);
}
void foobar(int a, int *ptr)
{
bar(foo(a), ptr);
}
generates correct warning when compiled by gcc 4.2.4:
$ gcc -O3 -Wall -Werror -c 1.c
cc1: warnings being treated as errors
1.c: In function âfoobarâ:
1.c:9: warning: âbâ may be used uninitialized in this function
1.c:9: note: âbâ was declared here
But it compiles without any warning with gcc 4.4.0. The bug reproduces on gcc
4.3.1 as well.
--
Summary: missing 'may be used uninitialized' warning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexvod at google dot com
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=39799
[Bug fortran/39800] New: Rejects PRIVATE TYPE as compont of local type declaration
Reported by Alexei Matveev at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ed70666b0c90b655
* * *
The following does not make sense:
MODULE m
TYPE, PRIVATE :: type; ...
CONTAINS
SUBROUTINE foo()
TYPE :: bar
TYPE(type) :: x
The last line is rejected with "The component 'x' is a PRIVATE type and cannot
be a component of 'type', which is PUBLIC at (1)"
The error is complete nonsense - TYPE(BAR) is not even used as dummy argument
(which would be valid since F2003).
The message only makes sense for the interface part of a module:
MODULE m
TYPE, PRIVATE :: type; ...
TYPE, PUBLIC :: bar
type(type) :: x
That case is valid Fortran 2003 and invalid Fortran 95 ("Component X of type T2
exposes PRIVATE type T1" as NAG f95 states). -- gfortran rejects this
unconditionally, however.
Thus there are two bugs:
- Local TYPE declarations in procedures are wrongly rejected
- Public types with private components are allowed in F2003 only,
s/gfc_error/gfc_std_notify(GFC_STD2003/.
* * *
module m
implicit none
type :: t1
integer :: i
end type
type,public :: t2
! OK in F2003, wrong in F95
type(t1) :: j ! { dg-error "Fortran 2003: ..." }
end type
contains
subroutine sub()
type :: t3
integer x
type(t1) :: j ! OK (F95 + F2003) - no dummy argument
end type! (dummy arg is OK only in F2003)
end subroutine
end module m
--
Summary: Rejects PRIVATE TYPE as compont of local type
declaration
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39800
[Bug c++/39797] Segmentation fault g++
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-17 20:49 --- g++-4.3 -S t.C t.C:21: error: could not convert template argument MatrixBase::M to unsigned int t.C:21: error: could not convert template argument MatrixBase::N to unsigned int t.C: In member function const double& Matrix::operator()(size_t, size_t) const: t.C:18: error: there are no arguments to Exception that depend on a template parameter, so a declaration of Exception must be available t.C:18: error: (if you use -fpermissive, G++ will accept your code, but allowing the use of an undeclared name is deprecated) this ice-on-invalid is fixed in 4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.3 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
[Bug middle-end/39801] New: Builtins are assumed not to throw exceptions, even with -fnon-call-exceptions
Some builtin functions are marked as not throwing exceptions, even when -fnon-call-exceptions is in use. As a result, the compiler will assume these functions will not throw exceptions -- but they might. For example, the buitin va_arg might cause a SEGV, which would become an exception, if the pointer provided was invalid. Even builtins which call external library routines might do so, if the routines have themselves been compiled with -fnon-call-exceptions. For more background, see: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00920.html and follow-ups thereto. -- Summary: Builtins are assumed not to throw exceptions, even with -fnon-call-exceptions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmitchel at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39801
[Bug other/31567] cc1, cc1plus, etc. don't support @file mechanism
--- Comment #2 from dnovillo at gcc dot gnu dot org 2009-04-17 20:51 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01379.html -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-17 20:51:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31567
[Bug tree-optimization/39799] [4.3/4.4/4.5 Regression] missing 'may be used uninitialized' warning
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-17 20:55 --- This is because we zero-initialize uninitialized variables during inlining. Honza, do you remember why we do this? /* By inlining function having uninitialized variable, we might extend the lifetime (variable might get reused). This cause ICE in the case we end up extending lifetime of SSA name across abnormal edge, but also increase register pressure. We simply initialize all uninitialized vars by 0 except for case we are inlining to very first BB. We can avoid this for all BBs that are not inside strongly connected regions of the CFG, but this is expensive to test. */ -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|regression |tree-optimization Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-04-17 20:55:52 date|| Summary|missing 'may be used|[4.3/4.4/4.5 Regression] |uninitialized' warning |missing 'may be used ||uninitialized' warning Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39799
[Bug other/31567] cc1, cc1plus, etc. don't support @file mechanism
--- Comment #3 from dnovillo at gcc dot gnu dot org 2009-04-17 21:12 --- Subject: Bug 31567 Author: dnovillo Date: Fri Apr 17 21:11:46 2009 New Revision: 146292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146292 Log: PR 31567 * gcc.c (create_at_file): New. (compile_input_file_p): New. (do_spec_1): Use @args files for %i. Use create_at_file for %o. * main.c (main): Update call to toplev_main. * toplev.c (toplev_main): Change signature. Call expandargv. * toplev.h (toplev_main): Change signature. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/main.c trunk/gcc/toplev.c trunk/gcc/toplev.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31567
[Bug other/31567] cc1, cc1plus, etc. don't support @file mechanism
--- Comment #4 from dnovillo at gcc dot gnu dot org 2009-04-17 21:13 --- Fixed. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31567
[Bug other/31567] cc1, cc1plus, etc. don't support @file mechanism
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31567
[Bug c++/39778] Using DJGPP to compile CPP file and get failure
--- Comment #2 from andris dot pavenis at iki dot fi 2009-04-17 21:15 --- One needs additional information (like preprocessed source, used operating system etc.) to do anything with this bug report. See page http://gcc.gnu.org/bugs.html (already mentioned in GCC error message) for more details. -- andris dot pavenis at iki dot fi changed: What|Removed |Added CC||andris dot pavenis at iki ||dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39778
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
--- Comment #2 from amonakov at gcc dot gnu dot org 2009-04-17 21:55
---
I attempted to investigate the miscompilation on the 4.4 branch.
The problem seems to appear in dse2 pass. Basically, after encountering
313 dx:DI=ax:DI+0x4
187 {[di:DI+dx:DI]=[di:DI+dx:DI]<<0x1;clobber flags:CC;}
...
191 [di:DI+dx:DI+0x4]=cx:SI
314 dx:DI=ax:DI+0x8
200 {[di:DI+dx:DI]=[di:DI+dx:DI]<<0x1;clobber flags:CC;}
and upon considering insn 200, dse2 decides to delete insn 191 and protect insn
187 (both are wrong, 200 depends on 191 and 187 is irrelevant):
**scanning insn=200
mem: (plus:DI (reg/v/f:DI 5 di [orig:63 a ] [63])
(reg:DI 1 dx [orig:84 ivtmp.36 ] [84]))
expanding: r5 into: NULL
expanding: r1 into: (plus:DI (value:DI)
(const_int 8 [0x8]))
expanding value DI into: r0
expanding: r0 into: NULL
after cselib_expand address: (plus:DI (plus:DI (reg/v/f:DI 5 di [orig:63 a ]
[63])
(reg:DI 0 ax [orig:76 ivtmp.36 ] [76]))
(const_int 8 [0x8]))
after canon_rtx address: (plus:DI (plus:DI (reg/v/f:DI 5 di [orig:63 a ]
[63])
(reg:DI 0 ax [orig:76 ivtmp.36 ] [76]))
(const_int 8 [0x8]))
varying cselib base=67 offset = 8
processing cselib load mem:(mem:SI (plus:DI (reg/v/f:DI 5 di [orig:63 a ]
[63])
(reg:DI 1 dx [orig:84 ivtmp.36 ] [84])) [2 S4 A32])
processing cselib load against insn 191
processing cselib load against insn 187
removing from active insn=187 has store
mem: (plus:DI (reg/v/f:DI 5 di [orig:63 a ] [63])
(reg:DI 1 dx [orig:84 ivtmp.36 ] [84]))
expanding: r5 into: NULL
expanding: r1 into: (plus:DI (value:DI)
(const_int 8 [0x8]))
expanding value DI into: r0
expanding: r0 into: NULL
after cselib_expand address: (plus:DI (plus:DI (reg/v/f:DI 5 di [orig:63 a ]
[63])
(reg:DI 0 ax [orig:76 ivtmp.36 ] [76]))
(const_int 8 [0x8]))
after canon_rtx address: (plus:DI (plus:DI (reg/v/f:DI 5 di [orig:63 a ]
[63])
(reg:DI 0 ax [orig:76 ivtmp.36 ] [76]))
(const_int 8 [0x8]))
varying cselib base=67 offset = 8
processing cselib store [8..12)
trying store in insn=191 gid=-1[8..12)
Locally deleting insn 191
deferring deletion of insn with uid = 191.
mems_found = 1, cannot_delete = false
I wonder how dse2 is supposed to notice that insn 314 changes DX. E.g. when
checking rhs of insn 200 ([di+dx]) against lhs of insn 191 ([di+dx+4] for
different dx) in check_mem_read_rtx it calls canon_true_dependence (from
dse.c:2224) for [di+dx] and [di+dx+4] which returns false. However, these
references clearly conflict. Maybe a stupid question, but shouldn't this
canon_true_dependence call receive canonicalized MEMs from 'base' and
'store_info->cse_base'?
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gmail dot com,
||amonakov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug middle-end/39794] [4.4/4.5 Regression] Miscompile with -O2 -funroll-loops
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-17 22:06 --- Best to CC Zadeck on DSE problems. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
[Bug fortran/31243] truncating strings longer than 2**32 characters
--- Comment #6 from jb at gcc dot gnu dot org 2009-04-17 22:13 --- I'm not sure how this could be fixed in a "proper way" without breaking the procedure call ABI. Gfortran follows pretty much every other Fortran compiler in providing character length as a hidden argument of type default integer. In principle we could break this and make the length argument (s)size_t like the string functions in C/C++ do, but that would probably be a major headache for all those doing mixed C/Fortran programming the old fashioned way without ISO_C_BINDING. Of course, in principle one option could be to support larger strings as long as no procedure calls are made, but that sounds pretty confusing and flaky IMHO. Considering that string sizes larger than 2**31 are pretty rare outside of testcases, and IMHO not worth breaking the procedure call ABI for, the proper resolution for this PR would be to just print out a "compiler limit" error message like Thomas Koenig suggested. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #1 from jb at gcc dot gnu dot org 2009-04-17 22:18 --- Confirmed, assigning to myself. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jb at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-17 22:18:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug target/38627] SuperH libgcc.a lacks .note.GNU-stack markings in math funcs
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-04-17 22:20 --- Subject: Bug 38627 Author: kkojima Date: Fri Apr 17 22:20:40 2009 New Revision: 146297 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146297 Log: PR target/38627 * config/sh/lib1funcs.asm [__ELF__ && __linux__]: Add .note.GNU-stack. * config/sh/linux-atomic.asm: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/lib1funcs.asm trunk/gcc/config/sh/linux-atomic.asm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38627
[Bug libstdc++/39802] New: std::num_get fails to pase negative zero input correctly
A call to std::num_get fails to parse negative values (specifically -0 in my
example).
/** Begin Test **/
#include
#include
#include
int main ()
{
unsigned long val = 1;
std::stringbuf sb ("-0");
std::istream is (&sb);
std::ios_base::iostate err (std::ios_base::goodbit);
typedef std::istreambuf_iterator iter_t;
const std::num_get& fac =
std::use_facet >(is.getloc ());
fac.get (is, iter_t (), is, err, val);
assert (is.eofbit == err && 0 == val);
return 0;
}
/** End Test **/
Even thought this test case only exercises -0 I think the method should be able
to handle any negative value. I have noted that other implementations do not
appear to exhibit this behavior.
--
Summary: std::num_get fails to pase negative zero input correctly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ritter at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39802
[Bug c/39383] sizeof object with zero-length array ignores initializer
--- Comment #10 from anmol at freescale dot com 2009-04-17 22:39 --- I am working on this problem and see that for generic ELF OS's, defining ASM_DECLARE_OBJECT_NAME (gcc/config/elfos.h) to use the size of the initializer (as against the size of the type) to emit the true size in the .size directive results in the following code being emitted for the submitted example: .type f1, @object .size f1, 16 f1: .long 1 .long 2 .long 3 .long 4 .section.rodata I am currently regression testing my fix (and plan on submitting the patch for the generic ELF OS case (assuming that this is the right approach to take here)). However, I am not sure if the same change will be needed in ASM_FINISH_DECLARE_OBJECT as well? rest_of_decl_compilation in gcc/passes.c seems to suggest that this macro is used for tentative definitions - in which case there would be no initializer and that seems to suggest that no change would be needed (using the size of the type would be the right thing to do). But in the GCC Internals Manual, Ch. 17 Sec. 17.21.4 Output and Generation of Labels - the description suggests that a change is needed in this macro as well. (Kindly advise, and I shall incorporate). Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383
[Bug fortran/31243] truncating strings longer than 2**32 characters
--- Comment #7 from dominiq at lps dot ens dot fr 2009-04-17 22:42 --- Compiling the code in comment #1 gives: [ibook-dhum] f90/bug% gfc42 pr31243.f90 pr31243.f90:12.15: print *, len(ch) 1 Error: Result of LEN overflows its kind at (1) It compiles with -fdefault-integer-8 and gives 4294967300 4 when executed. Note that "print *,ch(1:2_8**32_8+3_8)" prints three spaces and the value of 'i' in the subroutine is 4294967300. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
[Bug c++/39803] New: Bogus 'unused value' warning on declarations of non-POD arrays
When compiling the following program using the mainline GCC (4.5) with -Wunused
flag, we get a bogus "unused value" warning on the array declaration:
$ cat Wunused-14.C
#include
using std::pair;
int foo() {
pair components[3];
components[0].first = 0;
return 0;
}
$ g++ -Wunused -c Wunused-14.C
Wunused-14.C: In function 'int foo()':
Wunused-14.C:6: warning: value computed is not used
Here is the version string of the compiler used:
Target: x86_64-unknown-linux-gnu
gcc version 4.5.0 20090414 (experimental) (GCC)
--
Summary: Bogus 'unused value' warning on declarations of non-POD
arrays
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lcwu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39803
[Bug c++/39803] Bogus 'unused value' warning on declarations of non-POD arrays
--- Comment #1 from lcwu at gcc dot gnu dot org 2009-04-17 23:07 ---
This bogus warning started to show up after the fix for PR c++/39551 was
submitted (at revision 146132). And the root cause for the issue is that C++
front-end generates the following code to initialize the local 'pair' array:
(see build_vec_init() in cp/init.c)
*(struct pair[3] *) ({
(D.2247 = (struct pair *) &components);
(D.2248 = D.2247);
(D.2249 = 2);
for_stmt
{
D.2249 != -1;
--D.2249;
__comp_ctor (NON_LVALUE_EXPR );
++D.2248;
}
D.2247; })
The INDIRECT_REF operation (*) in the above code was later determined useless
and therefore deleted. However, since we didn't know that the INDIRECT_REF
expression was actually created by the compiler (instead of coming from the
user code) and therefore mistakenly emit an 'unused value' warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39803
[Bug middle-end/39625] [4.5 Regression] Revision 145338 breaks ability to build Ada
--- Comment #39 from rob1weld at aol dot com 2009-04-17 23:32 --- (In reply to comment #38) > Maybe fixed now (the reduced testcase is). Please re-open if not. Confirmed. Thank you Richard. # uname -a OpenBSD openbsd.localdomain 4.5 GENERIC#19 i386 Host Compiler: # egcc -v Reading specs from /usr/local/lib/gcc-lib/i386-unknown-openbsd4.5/3.3.6/specs Configured with: /usr/obj/i386/gcc-3.3.6/gcc-3.3.6/configure --verbose --program-transform-name=s,^,e, --disable-nls --with-system-zlib --enable-languages=c,c++,f77,objc,ada --enable-cpp --with-gnu-as --with-gnu-ld --enable-shared --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info Thread model: single gcc version 3.3.6 # gcc/xgcc -v Using built-in specs. Target: i386-unknown-openbsd4.5 Configured with: /home/user/gcc_trunk/configure --prefix=/usr/obj/gcc_installed --enable-languages=c,ada,c++ --with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-gnu-as --with-gnu-ld --enable-sjlj-exceptions --enable-shared --enable-multilib --enable-decimal-float --with-long-double-128 --with-tune=k8 --with-cpu=k8 --with-arch=k8 --enable-threads --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --disable-stage1-checking --enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.5.0 20090417 (experimental) [trunk revision 146277] (GCC) Thanks, Rob PS: The middle-end now permits the _build_ of gcc with the Language Ada selected to complete without failure, except for this unrelated issue: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00444.html . The actual ability of the Ada Language to operate correctly or pass the Testsuites is a _different_ issue that needs a separate RFE unrelated to #39625 . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug libstdc++/39802] std::num_get fails to parse negative zero input correctly
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-18 01:17 --- Oops, apparently we never parsed correctly negative values for unsigned. The fix is simple. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-18 01:17:12 date|| Summary|std::num_get fails to pase |std::num_get fails to parse |negative zero input |negative zero input |correctly |correctly http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39802
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #4 from t dot artem at mailcity dot com 2009-04-18 01:44 --- Test configuration: Software: Linux kernel 2.6.28.9 x86, GCC 4.2.4, GCC 4.4.0 RC, http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz Hardware: AMD64 Dual Core CPU 5600, 1MB x 2 level 2 cache RAM: DDR2 800MHz 4GB unrarsrc-3.8.5.tar.gz compiled binary (compilation flags: -march=pentium2 -O2 -ftree-vectorize): GCC 4.2.4: 180492 bytes GCC 4.4.0: 196288 bytes Uncompressing 1GB archive (several hundreds WAV files): time rar-4.2.4 t -inul archive.rar real1m18.413s user1m17.758s sys 0m0.580s time rar-4.4.0 t -inul archive.rar real1m28.021s user1m27.344s sys 0m0.627s (average results for five runs - disk IO has zero effect, since file resides on RAM disk). Summary: 4.4.x binary is 9% larger and produces code which runs 14% slower. -- t dot artem at mailcity dot com changed: What|Removed |Added Severity|minor |major Status|RESOLVED|UNCONFIRMED Known to fail||4.4.0 4.3.3 Known to work||4.2.4 Resolution|WONTFIX | Summary|[POSSIBLY NOT A BUG] GCC|GCC 4.4.x vs. 4.2.x |4.3.0 vs. 4.2.3 observations|performance regression Version|4.3.0 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-18 02:24 --- (In reply to comment #4) > Test configuration: > > Software: Linux kernel 2.6.28.9 x86, GCC 4.2.4, GCC 4.4.0 RC, > http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz > > Hardware: AMD64 Dual Core CPU 5600, 1MB x 2 level 2 cache > RAM: DDR2 800MHz 4GB > > unrarsrc-3.8.5.tar.gz compiled binary (compilation flags: -march=pentium2 -O2 > -ftree-vectorize): > Why do you use -march=pentium2 on AMD64 Dual Core CPU 5600? Remove -march=pentium2 and report what you get. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
--- Comment #2 from ian at airs dot com 2009-04-18 05:40 --- You are much more familiar with the library than I am. I don't know if this issue arises anywhere else. cin/cout/cerr is sort of an obvious case. It didn't really occur to me that there might be similar issues elsewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
