[Bug target/36348] [4.4 Regression] f951 link failure on i686-apple-darwin9
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-05-28 06:59 --- Mine. Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg01786.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-05-28 01:19:07 |2008-05-28 06:59:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36348
[Bug c/36351] New: gcc handled OpenMP programs with uplevel reference wrongly
the testcase uplevi.c is to show that for OpenMP programs, gcc reference
uplevel variable by [%fp - 4] in each thread.
micro# cat uplevi.c
int main()
{
int i;
void sub()
{
printf("0x%x\n", &i);
}
#pragma omp parallel num_threads(4)
sub();
return 0;
}
micro# /import/dr3/s10/gcc-4.2/bin/gcc uplevi.c -fopenmp -w
micro# ./a.out
0xfeffbecc
0xfeefbecc
0xffbffa8c
0xff0fbecc
micro# /import/dr3/s10/gcc-4.2/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure
--prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran
--enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2
--with-gmp=/import/dr3/s10/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070228 (prerelease)
--
Summary: gcc handled OpenMP programs with uplevel reference
wrongly
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36351
[Bug middle-end/36351] gcc handled OpenMP programs with uplevel reference wrongly
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36351
[Bug middle-end/36351] gcc handled OpenMP programs with uplevel reference wrongly
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-28 07:18 --- This is a dup of bug 35130 which was fixed for 4.3.0. *** This bug has been marked as a duplicate of 35130 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36351
[Bug middle-end/35130] OpenMP: Private variable passed to subroutine
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-05-28 07:18 --- *** Bug 36351 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35130
[Bug middle-end/36351] gcc handled OpenMP programs with uplevel reference wrongly
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-28 07:19 --- Also by the way for this testcase, you are using a GNU extension with OpenMP so you should take care. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36351
[Bug target/34988] gcc-4.3 (20080118 snapshot) crashes while building libstdc++ (locale_facets_nonio.tcc)
--- Comment #3 from giamby at infinito dot it 2008-05-28 07:27 --- It now works on my system too. -- giamby at infinito dot it changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34988
[Bug c++/36288] OpenMP-C++: segmentation fault in basic string constructors
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-28 07:31 ---
(In reply to comment #5)
> BTW, the i = i trick
it only works in the initializer and not as a statement after the fact.
That is:
#include
int foo (int x)
{
int y = y;
assert (x == 0 || x == 1);
if (x == 0)
y = 1;
else if (x == 1)
y = 2;
return y;
}
Will work, also with the jump threading, GCC should be able to figure out that
y is always inlined (except when -DNDEBUG is used).
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug tree-optimization/36352] New: missed "inlining" of static untouched variable in linked once function
While looking into PR 36297, I found this interesting missed optimization, it
only happens with linked once functions. Testcase:
template int f(void)
{
static int t = a;
return t;
}
int g(void)
{
return f<1>();
}
We should produce return 1 for both functions but currently we reference
f<1>::t .
--
Summary: missed "inlining" of static untouched variable in linked
once function
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352
[Bug tree-optimization/36297] false warning: 'variable' may be used uninitialized in this function
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-28 07:47 --- This has been fixed in at least 4.3.0, it might have also been fixed in 4.2.0 also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |tree-optimization Keywords||diagnostic Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36297
[Bug c++/36288] OpenMP-C++: segmentation fault in basic string constructors
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-28 07:51 --- Hmm, I don't think this is a bug as the assignment of the string is not going to be atomic so you could get a partial assignment of a.astr happening. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
[Bug middle-end/36288] OpenMP-C++: segmentation fault in basic string constructors
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-28 07:53 --- Is there a reason why you think this is well defined code? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-28 07:55 --- >checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. make[1]: *** [configure-target-libgomp] Error 1 Can you attach the config.log then? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
[Bug c++/36353] New: Unclear error message in unused template
I get these error messages:
aap.cc: In member function 'void Bar::function(T)':
aap.cc:16: error: expected `;' before 'it'
aap.cc:18: error: 'it' was not declared in this scope
When I compile this code:
#include
#include
template
class Foo {
public:
void function(T arg) { std::cout << arg; }
};
template
class Bar {
std::list *> foo_list;
public:
void function(T arg)
{
std::list *>::iterator it;
for (it = foo_list.begin(); it!=foo_list.end(); it++) {
Foo *el = (*it);
el->function (arg);
}
}
};
int
main(void)
{
#if 0
// Enabling this gives a better error message
Bar bar;
bar.function(1);
#endif
return 1;
}
When you enabled the #ifdeffed out code you will get these much clearer error
messages too:
aap.cc: In member function 'void Bar::function(T) [with T = int]':
aap.cc:31: instantiated from here
aap.cc:16: error: dependent-name 'std::list*,std::allocator*>
>::iterator' is parsed as a non-type, but instantiation yields a type
aap.cc:16: note: say 'typename std::list*,std::allocator*>
>::iterator' if a type is meant
verbose output:
trunk (--) ~/src/q/ g++ -v -save-temps aap.cc
Reading specs from
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/specs
Target: i686-pc-linux-gnu
Configured with: /home/gcc/gcc/gcc-4.2.2.1/gcc-4.2.2.1/configure
--prefix=/cadappl/gcc/4.2.2.1 --with-as=/cadappl/gcc/4.2.2.1/bin/as
--with-ld=/cadappl/gcc/4.2.2.1/bin/ld --enable-__cxa_atexit
--enable-threads=posix --with-march=i686 --with-tune=pentium4
--enable-languages=c,c++,fortran --with-gmp=/cadappl/gcc/4.2.2.1
--with-mpfr=/cadappl/gcc/4.2.2.1
Thread model: posix
gcc version 4.2.2
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus
-E -quiet -v -iprefix
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/
-D_GNU_SOURCE aap.cc -mtune=pentium4 -fpch-preprocess -o aap.ii
ignoring nonexistent directory
"/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/cadappl/gcc/4.2.2.1/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2"
ignoring duplicate directory
"/cadappl/gcc/4.2.2.1/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu"
ignoring duplicate directory
"/cadappl/gcc/4.2.2.1/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward"
ignoring duplicate directory
"/cadappl/gcc/4.2.2.1/lib/gcc/i686-pc-linux-gnu/4.2.2/include"
ignoring nonexistent directory
"/cadappl/gcc/4.2.2.1/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/i686-pc-linux-gnu
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../include/c++/4.2.2/backward
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/include
/usr/local/include
/cadappl/gcc/4.2.2.1/include
/usr/include
End of search list.
/sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.2/cc1plus
-fpreprocessed aap.ii -quiet -dumpbase aap.cc -mtune=pentium4 -auxbase aap
-version -o aap.s
GNU C++ version 4.2.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 473b7610f3bef24f1da62f9e674d528f
aap.cc: In member function 'void Bar::function(T)':
aap.cc:16: error: expected `;' before 'it'
aap.cc:18: error: 'it' was not declared in this scope
--
Summary: Unclear error message in unused template
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wim dot yedema at gmail dot com
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36353
[Bug testsuite/36332] [4.4 Regression] FAIL: gcc.dg/torture/type-generic-1.c -O* execution test on powerpc-apple-darwin*
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-28 07:57 --- It is also happening on powerpc-linux-gnu: http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg02422.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin* | GCC host triplet|powerpc-apple-darwin* | GCC target triplet|powerpc-apple-darwin* |powerpc*-*-* Last reconfirmed|-00-00 00:00:00 |2008-05-28 07:57:44 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36332
[Bug c++/36353] missing typename for unused template error message is unclear
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic Summary|Unclear error message in|missing typename for unused |unused template |template error message is ||unclear http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36353
[Bug c++/36353] missing typename for unused template error message is unclear
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-28 08:00 --- *** This bug has been marked as a duplicate of 15946 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36353
[Bug c++/15946] Unhelpful error message when "typename" is omitted
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-28 08:00 --- *** Bug 36353 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||wim dot yedema at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15946
[Bug c++/36353] missing typename for unused template error message is unclear
--- Comment #2 from wim dot yedema at gmail dot com 2008-05-28 08:00 --- Created an attachment (id=15689) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15689&action=view) preprocessed case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36353
[Bug c++/36353] missing typename for unused template error message is unclear
--- Comment #3 from wim dot yedema at gmail dot com 2008-05-28 08:01 --- Created an attachment (id=15690) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15690&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36353
[Bug middle-end/36326] gimplification of aggregate copies introduces extra aggregate copy
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-28 08:05 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36326
[Bug testsuite/36344] [4.3/4.4 Regression] gcc.dg/tree-ssa/loadpre8.c XFAILed
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36344
[Bug middle-end/36296] wrong warning about potential uninitialized variable
--- Comment #7 from vincent at vinc17 dot org 2008-05-28 08:18 --- (In reply to comment #6) > (In reply to comment #5) > > BTW, the i = i trick > > it only works in the initializer and not as a statement after the fact. But in such a case, as i is not initialized yet, this may be undefined behavior with some C implementations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36296
[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-28 08:21 ---
I think this is more of an issue of changing the variable to be readonly than
an "inlining" the variable issue as the following source works as expected:
template int f(int i)
{
static const int t = a;
static const int t1 = a;
return i?t:t1;
}
int g(void)
{
return f<1>(1);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|missed "inlining" of static |missed "inlining" of static
|untouched variable in linked|untouched variable in linked
|once function |once function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352
[Bug fortran/36309] gfortran and cc1 error
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-05-28 08:27 --- What the issue is that the C compiler was not configured with fortran compiler so they don't ignore the fortran options but then the fortran compiler was configured separately. So this is invalid and really an issue with how cc1 was built. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36309
[Bug c/36354] New: gcc handled OpenMP programs with uplevel reference wrongly
the testcase uplevi.c is to show that for OpenMP programs, gcc reference
uplevel variable by [%fp - 4] in each thread.
micro# cat uplevi.c
int main()
{
int i;
void sub()
{
printf("0x%x\n", &i);
}
#pragma omp parallel num_threads(4)
sub();
return 0;
}
micro# /import/dr3/s10/gcc-4.2/bin/gcc uplevi.c -fopenmp -w
micro# ./a.out
0xfeffbecc
0xfeefbecc
0xffbffa8c
0xff0fbecc
micro# /import/dr3/s10/gcc-4.2/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure
--prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran
--enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2
--with-gmp=/import/dr3/s10/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070228 (prerelease)
--
Summary: gcc handled OpenMP programs with uplevel reference
wrongly
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36354
[Bug c/36354] gcc handled OpenMP programs with uplevel reference wrongly
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-28 08:32 --- *** This bug has been marked as a duplicate of 36351 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36354
[Bug middle-end/36351] gcc handled OpenMP programs with uplevel reference wrongly
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-28 08:32 --- *** Bug 36354 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36351
[Bug fortran/36355] New: matmul argument-check: wrong error messages
$> cat matmul.f90
REAL, DIMENSION(2,2) :: a
character(1) :: b
print *, MATMUL(a, b) ! line 4: argument matrix_b is wrong
print *, MATMUL(b, a) ! line 5: argument matrix_a is wrong
end
$> gfortran-svn matmul.f90
matmul.f90:4.18:
print *, MATMUL(a, b)
1
Error: 'matrix_a' argument of 'matmul' intrinsic at (1) must be numeric or
LOGICAL
matmul.f90:5.20:
print *, MATMUL(b, a)
1
Error: 'matrix_b' argument of 'matmul' intrinsic at (1) must be numeric or
LOGICAL
Proposed change (untested):
Index: check.c
===
--- check.c (revision 136058)
+++ check.c (working copy)
@@ -1761,7 +1761,7 @@ gfc_check_malloc (gfc_expr *size)
try
gfc_check_matmul (gfc_expr *matrix_a, gfc_expr *matrix_b)
{
- if ((matrix_a->ts.type != BT_LOGICAL) && !gfc_numeric_ts (&matrix_b->ts))
+ if ((matrix_a->ts.type != BT_LOGICAL) && !gfc_numeric_ts (&matrix_a->ts))
{
gfc_error ("'%s' argument of '%s' intrinsic at %L must be numeric "
"or LOGICAL", gfc_current_intrinsic_arg[0],
@@ -1769,7 +1769,7 @@ gfc_check_matmul (gfc_expr *matrix_a, gf
return FAILURE;
}
- if ((matrix_b->ts.type != BT_LOGICAL) && !gfc_numeric_ts (&matrix_a->ts))
+ if ((matrix_b->ts.type != BT_LOGICAL) && !gfc_numeric_ts (&matrix_b->ts))
{
gfc_error ("'%s' argument of '%s' intrinsic at %L must be numeric "
"or LOGICAL", gfc_current_intrinsic_arg[1],
--
Summary: matmul argument-check: wrong error messages
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36355
[Bug fortran/36342] Missing file name in compilation diagnostics with '-cpp' or '-x f95-cpp-input'
--- Comment #2 from P dot Schaffnit at access dot rwth-aachen dot de 2008-05-28 11:06 --- Thanks! Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36342
4.3.0/include/c++/bits/boost_concept_check.h - RandomAccessIteratorConcept Concept check ambiguous
we have ambiguous requirement
see:
template
struct _RandomAccessIteratorConcept
{
void __constraints() {
__function_requires< _BidirectionalIteratorConcept<_Tp> >();
__function_requires< _ComparableConcept<_Tp> >();
__function_requires< _ConvertibleConcept<
typename std::iterator_traits<_Tp>::iterator_category,
std::random_access_iterator_tag> >();
// ??? We don't use _Ref, are we just checking for "referenceability"?
typedef typename std::iterator_traits<_Tp>::reference _Ref;
__i += __n; // require assignment addition
operator
__i = __i + __n; // require addition with difference type
//__i = __n + __i; !!! ambiguous !!!
__i = __i - __n; // require subtraction with
//difference
type
__n = __i - __j; // require difference operator
(void)__i[__n]; // require element access operator
}
_Tp __a, __b;
_Tp __i, __j;
typename std::iterator_traits<_Tp>::difference_type __n;
};
what type expression __n + __i; must has ?
std::iterator_traits<_Tp>::difference_type or _Tp ?
what operator+ compiler must and can use ?
best regards
Bulavitsky Alexey
[Bug middle-end/17736] Optimization for global initialization with empty constructors
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-28 08:38 --- *** Bug 36310 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bla at thera dot be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17736
[Bug c++/36310] [avr] Lots of (possibly) unnecesary static initialization code generated.
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-28 08:38 --- *** This bug has been marked as a duplicate of 17736 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36310
[Bug rtl-optimization/36350] [4.3/4.4 Regression] GCC ICE with -frename-registers
--- Comment #1 from matthijs dot van dot de dot water at gmail dot com 2008-05-28 10:14 --- My arm-none-linux-gnueabi-gcc with the patch from bug 35964 does not suffer this ICE. This is also why Debian/Ubuntu/Fedora do not see this, because they have the referenced patch applied on top of gcc-4_3-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36350
[Bug bootstrap/36356] New: gcc-4.2.4 bootstrap failure on Solaris/x86 caused by PR31868 fix
gcc-4.2.4 fails to bootstrap on Solaris10/x86 as follows: env CONFIG_SHELL=/usr/bin/bash /home/mikpe/gcc-4.2.4/configure --prefix=/opt/local/gcc-4.2.4 --with-gnu-as --with-as=/opt/local/binutils-2.18/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix --disable-shared --enable-multilib --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --enable-java-awt=xlib --with-system-zlib --enable-languages=c,c++ --with-mpfr=/opt/csw make bootstrap ... checking sys/sem.h presence... yes checking for sys/sem.h... yes checking for sin in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/mikpe/objdir-4.2.4-static' make: *** [bootstrap] Error 2 I have previously built gcc-4.1.2 and gcc-4.2.3 successfully on this system, so this failure is an obvious regression. Testing older 4.2 snapshots showed that 4.2-20080206 was the last snapshot that built ok, and 4.2-20080213 is the first one that fails. Inspecting the diff between 20080206 and 20080213 and testing parts of it separately has identified H.J. Lu's fix for PR31868 as the culprit. Specifically, after that change crtstuff.c is compiled with -fno-asynchronous-unwind-tables which it wasn't before the change. 20080213 minus the -fno-asynchronous-unwind-tables change builds fine. I haven't yet checked if gcc-4.3 is similarly affected because I needed to resolve a generic 4.3 problem first (PR36339). -- Summary: gcc-4.2.4 bootstrap failure on Solaris/x86 caused by PR31868 fix Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC host triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36356
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #10 from acarmeli at mathworks dot com 2008-05-28 11:21 --- Created an attachment (id=15691) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15691&action=view) Steps to reach numerically incorrect/impossible result Compile: gcc bad_numeric.c Builds up expression until it breaks numerically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug tree-optimization/36347] points-to sets should be always kept for call-clobbering
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-28 08:58 --- I have a fix (fixing PR36346 fixes this as well). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||36346 AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-28 08:58:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36347
[Bug tree-optimization/36352] missed "inlining" of static untouched variable in linked once function
-- rguenth 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-05-28 09:00:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36352
[Bug middle-end/36288] OpenMP-C++: segmentation fault in basic string constructors
--- Comment #4 from hailijuan at gmail dot com 2008-05-28 08:54 --- Subject: Re: OpenMP-C++: segmentation fault in basic string constructors no. thanks for your comments. i have correct the testcase. the error is gone with gcc-4.2. thanks again. 2008/5/28 pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-28 07:53 > --- > Is there a reason why you think this is well defined code? > > > -- > > pinskia at gcc dot gnu dot org changed: > > What|Removed |Added > > Component|c++ |middle-end > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
[Bug testsuite/36344] [4.3/4.4 Regression] gcc.dg/tree-ssa/loadpre8.c XFAILed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-28 11:29 --- The reason that the PRE no longer works is that the edge iterator ei is now call clobbered. It escapes to a pure/const function (which wouldn't make it call clobbered alone) and it has its address taken which is why it is in the list of addressable vars. Now through the other calls there escape pointers that point to anything, so all addressable vars get clobbered. A few things would help here: - properly track what can point to local variables - track addresses that are stored somewhere separately (in this case &ei is only passed to a pure/const call) - do type-based pruning of the call clobber variables. This works only if an escaped pointer is _always_ dereferenced (thus the dereference site post-dominates the entry BB) - in contrast to pruning the points-to sets for dereference sites where we can prune in flow-insensitive way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36344
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #11 from acarmeli at mathworks dot com 2008-05-28 11:30 --- I believe there is still a violation of the C standard when expression folding folds this. The attached file demonstrates this. In step 7, we perform 4*3 in 32-bit and expect to get a 12 in a 64-bit. It should be possible to perform this without overflow and represent in 64-bit. It should be possible to divide the result in 3 and get the original number: 4 However, the folded expression does not permit this to happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug middle-end/17736] Optimization for global initialization with empty constructors
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-28 08:38 --- These constructors are not trivial as defined by the C++ standard :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Optimization for global |Optimization for global |initialization with trivial |initialization with empty |constructors|constructors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17736
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-05-28 11:48 --- We are probably not honoring the implementation defined signed truncation(s). But my head hurts looking at the testcase vs. the folding code ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug fortran/36355] matmul argument-check: wrong error messages
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-05-28 11:53 --- Proposed patch passed regression test on i686-pc-linux-gnu.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36355
[Bug preprocessor/36357] New: Feature request: -Wrecursive-inclusion
It would be really useful if gcc/cpp had a -Wrecursive-inclusion option. In essence, this should print warnings if any file, directly or indirectly, attempts to include itself. I believe that this in most cases is an error, and since regular header guards will work around the problem (by skipping already included files), it can lead to unfortunate silent recursive dependencies which may be hard to get rid of once they have been introduced. It is possible to do this manually, e.g. internally in each file, such as: #ifdef X #warning already included #else #define X /* ... */ #undef X #endif However, this is hard to maintain and easy to get wrong. So I suggest the introduction of a -Wrecursive-inclusion to let cpp do the job. -- Summary: Feature request: -Wrecursive-inclusion Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vegard dot nossum at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36357
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-05-28 12:11 --- In step5 we have signed overflow in the multiplication of -2147483646 with itself. Thus starting from that, the following results are unreliable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug fortran/36322] ICE with PROCEDURE using a complicated interface
-- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-28 12:38:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36322
[Bug c/8068] [3.2/3.3 regression] exceedingly high (infinite) memory usage
--- Comment #6 from acarmeli at mathworks dot com 2008-05-28 12:37 --- Richard, This is the root cause of the problem: I agree with you that an overflow can occur and there is no way to guarantee the resulting value. However, it must be a 32-bit value. It cannot all of a sudden become a 64-bit value, and that's the violation of the standard that I see. Alex. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8068
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #14 from acarmeli at mathworks dot com 2008-05-28 12:25 --- You are correct. But step 6 did not reveal that, and provided a correct s64 result. This result should have been carried over to step 7 to lead to a correct result. Otherwise, it will not be possible to get the result through a folded expression. It seems to me that adding more to the expression changes the optimization to inner expressions in a way that compromizes the numerical stability. We also tried masking to eliminate unwanted bits. The masks seem to have no effect and we suspect they get optimized out. It was an unfavorable solution anyway, due to the cost of the mask. In effect, there is no reliable way to grow a folded expression and consistently preserve the result of inner expressions. The only solution we have is temporary variables, which might get optimized out and folded as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug c/36249] Error: cpu `51qe' unrecognized while making for m68k target
--- Comment #2 from a dot iqbal at ieee dot org 2008-05-28 12:50 --- (In reply to comment #1) > You need a newer version of binutils (from CVS). > Thank you very much. That solved it. So I close it marking as invalid because it was an issue with binutils. -- a dot iqbal at ieee dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36249
Jobzentrale
Ein marktgewinnendes Handelsunternehmen sucht neue Kollegen !! Sie haben 4 Stunden in der Woche Zeit , besitzen einige Internetkenntnisse und sind immer erreichebar?? - Sie haben dann die Moeglichkeit bei uns einzusteigen und ab zwei Tausend monatlich zu erhalten!! Neugirig? - schreiben Sie uns an [EMAIL PROTECTED] und lassen Sie sich genauere Details zumailen. Mit freundlichen Gruessen ELFYNG LTD
[Bug middle-end/36300] Incorrect type used for inlined expression
--- Comment #15 from rguenther at suse dot de 2008-05-28 12:57 --- Subject: Re: Incorrect type used for inlined expression On Wed, 28 May 2008, acarmeli at mathworks dot com wrote: > --- Comment #14 from acarmeli at mathworks dot com 2008-05-28 12:25 > --- > You are correct. But step 6 did not reveal that, and provided a correct s64 > result. This result should have been carried over to step 7 to lead to a > correct result. Well, step 6 has a "correct" result by luck - the undefinedness doesn't expose an optimization opportunity. In step 7 the result from step 6 is not used, but instead its expression is inserted and the intermediate result from step 6 is unused (and so is combined with the added expression, exploiting the undefined behavior for a transformation the folding code thinks is worthwhile). > Otherwise, it will not be possible to get the result through a folded > expression. The code invokes undefined behavior if the expression in step 5 overflows. Undefined behavior can be also strange and "inconsistent" behavior as you see in your testcase. > It seems to me that adding more to the expression changes the optimization to > inner expressions in a way that compromizes the numerical stability. Yep. The folding code is run early and sees the whole C expression. Obviously this exploits more "interesting" opportunities to mangle the expressions. > We also tried masking to eliminate unwanted bits. The masks seem to have no > effect and we suspect they get optimized out. It was an unfavorable solution > anyway, due to the cost of the mask. > > In effect, there is no reliable way to grow a folded expression and > consistently preserve the result of inner expressions. The only solution we > have is temporary variables, which might get optimized out and folded as well. True. The only reliable way is to only write (partial) expressions that do not invoke undefined behavior in any case ;) This can be either done by carefully doing operations that may overflow in unsigned arithmetic or by providing -fwrapv as a compiler option. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables
--- Comment #6 from mikpe at it dot uu dot se 2008-05-28 13:20 --- (In reply to comment #5) > >checking for C compiler default output file name... configure: error: C > compiler cannot create executables > See `config.log' for more details. > make[1]: *** [configure-target-libgomp] Error 1 > > Can you attach the config.log then? > I get the exact same failure trying to bootstrap 4.3-20080522 + PR36339 fix on Solaris10/x86. The config.log entry says this: configure:2540: checking for C compiler default output file name configure:2543: /home/mikpe/objdir-4.3-20080522-static/./gcc/xgcc -B/home/mikpe/objdir-4.3-20080522-stat ic/./gcc/ -B/opt/local/gcc-4.3-20080522/i386-pc-solaris2.10/bin/ -B/opt/local/gcc-4.3-20080522/i386-pc-s olaris2.10/lib/ -isystem /opt/local/gcc-4.3-20080522/i386-pc-solaris2.10/include -isystem /opt/local/gcc -4.3-20080522/i386-pc-solaris2.10/sys-include -m64 -O2 -g -O2 -pthread conftest.c >&5 ld: fatal: unwind table: file /home/mikpe/objdir-4.3-20080522-static/./gcc/amd64/crtend.o: section .eh_f rame: bad cie version 0: offset 0x7ff84680 collect2: ld returned 1 exit status gcc is configured to use GNU as but Sun ld, as seems to be standard. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36330
GCC typo in char_traits.h header file
I have found a tipo in this file: -  C:/Dev-Cpp/include/c++/3.4.2/bits/char_traits.h -  --- LINE 80 --- Wrong:   * may not be specialized for fundamentl types, but classes in Ok   * may not be specialized for fundamental types, but classes in "fundamentl" is spelled incorrectly. Thanks!    Adolfo   /// Â
[Bug target/32000] x86 backend uses aligned load on unaligned memory
--- Comment #8 from hjl dot tools at gmail dot com 2008-05-28 13:32 --- (In reply to comment #7) > Fixed? > The bug report was opened against gcc 4.3. To fix it in 4.3, we need to backport the fix from trunk. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-28 13:32:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32000
[Bug middle-end/36300] [4.1/4.2/4.3 Regression] Incorrect type used for inlined expression
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Incorrect type used for |[4.1/4.2/4.3 Regression] |inlined expression |Incorrect type used for ||inlined expression Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug c++/27975] warning for comparison of different enum types impossible to control/is undocumented
--- Comment #8 from matz at gcc dot gnu dot org 2008-05-28 13:54 --- Fixed in [EMAIL PROTECTED] Option now is -Wno-enum-compare . -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27975
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-28 13:54 --- Subject: Bug 36291 Author: rguenth Date: Wed May 28 13:54:05 2008 New Revision: 136095 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136095 Log: 2008-05-28 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36291 * tree-flow. h (struct gimple_df): Remove var_anns member. * tree-flow-inline.h (gimple_var_anns): Remove. (var_ann): Simplify. * tree-dfa.c (create_var_ann): Simplify. (remove_referenced_var): Clear alias info from var_anns of globals. * tree-ssa.c (init_tree_ssa): Do not allocate var_anns. (delete_tree_ssa): Clear alias info from var_anns of globals. Do not free var_anns. (var_ann_eq): Remove. (var_ann_hash): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow-inline.h trunk/gcc/tree-flow.h trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug middle-end/36300] [4.1/4.2/4.3 Regression] Incorrect type used for inlined expression
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-05-28 13:46 --- Fixed for 4.3.1. Unassigning. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to work|2.95.4 4.4.0|2.95.4 4.3.1 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug middle-end/36300] [4.1/4.2/4.3 Regression] Incorrect type used for inlined expression
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-05-28 13:46 --- Subject: Bug 36300 Author: rguenth Date: Wed May 28 13:45:47 2008 New Revision: 136085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136085 Log: 2008-05-28 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/36300 * fold-const.c (extract_muldiv_1): Use TYPE_OVERFLOW_WRAPS, not TYPE_UNSIGNED. Use TYPE_PRECISION instead of GET_MODE_SIZE. * gcc.dg/pr36300-1.c: New testcase. * gcc.dg/pr36300-2.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36300-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36300-2.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=36300
[Bug tree-optimization/36291] GCC is slow and memory-hungry building sipQtGuipart.cpp
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-05-28 13:57 --- The situation on the trunk should be much better now. A trivial backport to the 4.3 branch failed during bootstrap though, so that has to wait for some investigation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36291
[Bug target/36348] [4.4 Regression] f951 link failure on i686-apple-darwin9
--- Comment #3 from dominiq at lps dot ens dot fr 2008-05-28 13:37 --- Will Darwin users have to wait two months for this patch to be approved and committed (even if Apple did not contributed)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36348
[Bug tree-optimization/36339] [4.3/4.4 Regression] not call clobbering variable for non common offset
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-28 14:46 --- Subject: Bug 36339 Author: rguenth Date: Wed May 28 14:45:57 2008 New Revision: 136100 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136100 Log: 2008-05-28 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Move pt_anything and clobbering code out of the loop. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36339
[Bug tree-optimization/36339] [4.3/4.4 Regression] not call clobbering variable for non common offset
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-05-28 14:53 --- Subject: Bug 36339 Author: rguenth Date: Wed May 28 14:52:07 2008 New Revision: 136101 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136101 Log: 2008-05-28 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/36339 * tree-ssa-alias.c (set_initial_properties): Move pt_anything and subvariable clobbering code out of the loop. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36339
[Bug ada/34446] gnatprep evaluating "not" operator at incorrect precidence
--- Comment #5 from charlet at gcc dot gnu dot org 2008-05-28 15:56 --- Subject: Bug 34446 Author: charlet Date: Wed May 28 15:55:41 2008 New Revision: 136111 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136111 Log: 2008-05-28 Vincent Celier <[EMAIL PROTECTED]> PR ada/34446 * gnat_ugn.texi: Document restriction introduced on 2007-04-20 in preprocessing expressions Modified: trunk/gcc/ada/gnat_ugn.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446
[Bug ada/34446] gnatprep evaluating "not" operator at incorrect precidence
--- Comment #6 from charlet at gcc dot gnu dot org 2008-05-28 15:58 --- Documentation has been updated, so closing. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34446
[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions
--- Comment #3 from gunnar at greyhound-data dot com 2008-05-28 16:14 --- (In reply to comment #1) > It would have been nice to check at least gcc 4.3 (or better current trunk). > I've verified with latest source gcc source "version 4.4.0 20080523 (experimental) (GCC)" The problem that GCC used totally unneeded TST instructions is still in the current source. Regards Gunnar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36133
[Bug target/36134] GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used
--- Comment #2 from gunnar at greyhound-data dot com 2008-05-28 16:18 --- (In reply to comment #1) > It would have been nice to check at least gcc 4.3 (or better current trunk). > I've verified with latest source gcc source "version 4.4.0 20080523 (experimental) (GCC)" The most current GCC source still has the problem that ADD.L instructions are used for incrementing pointers instead using shorter LEA instruction. Code generated by GCC 4.4 for the testcase. copy_32x4: link.w %fp,#-12 movem.l #3076,(%sp) move.l 16(%fp),%d2 lsr.l #4,%d2 move.l 8(%fp),%a3 move.l 12(%fp),%a2 jra .L6 .L7: move.l (%a2),%a1 subq.l #1,%d2 move.l 4(%a2),%d0 move.l 8(%a2),%d1 move.l 12(%a2),%a0 add.l #16,%a2 move.l %a1,(%a3) move.l %d0,4(%a3) move.l %d1,8(%a3) move.l %a0,12(%a3) add.l #16,%a3 .L6: tst.l %d2 jne .L7 movem.l (%sp),#3076 unlk %fp rts Regards Gunnar -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36134
[Bug target/36135] GCC creates suboptimal ASM : suboptimal Adressing-Modes used
--- Comment #2 from gunnar at greyhound-data dot com 2008-05-28 16:23 --- (In reply to comment #1) > It would have been nice to check at least gcc 4.3 (or better current trunk). > I have verified this for you with the most current GCC source. Verified with gcc version 4.4.0 20080523 (experimental) (GCC) The problem that GCC uses bad addressing modes is still persistent. Code generated by GCC 4.4 copy_32x4: link.w %fp,#-12 movem.l #3076,(%sp) move.l 16(%fp),%d2 lsr.l #4,%d2 move.l 8(%fp),%a3 move.l 12(%fp),%a2 jra .L6 .L7: move.l (%a2),%a1 subq.l #1,%d2 move.l 4(%a2),%d0 move.l 8(%a2),%d1 move.l 12(%a2),%a0 add.l #16,%a2 move.l %a1,(%a3) move.l %d0,4(%a3) move.l %d1,8(%a3) move.l %a0,12(%a3) add.l #16,%a3 .L6: tst.l %d2 jne .L7 movem.l (%sp),#3076 unlk %fp rts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36135
[Bug target/36136] GCC creates suboptimal ASM : constant work registers are set up inside work loops and not outside of the loop
--- Comment #2 from gunnar at greyhound-data dot com 2008-05-28 16:28 --- (In reply to comment #1) > It would have been nice to check at least gcc 4.3 (or better current trunk). > I have verified this with the most current GCC source trunk. GCC 4.4 code snapshot 2008-05-23 The problem is still persistant. GCC sets up his work registers inside the work loop. write_32x4: link.w %fp,#0 move.l 16(%fp),%d0 move.l 8(%fp),%a0 lsr.l #4,%d0 jra .L50 .L51: moveq #1,%d1 move.l %d1,(%a0) move.l %d1,4(%a0) move.l %d1,8(%a0) move.l %d1,12(%a0) lea (16,%a0),%a0 subq.l #1,%d0 .L50: tst.l %d0 jne .L51 unlk %fp rts -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36136
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #9 from joel at gcc dot gnu dot org 2008-05-28 16:29 --- Created an attachment (id=15692) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15692&action=view) Latest version Previous patch did not include s-interr-hwint.adb. There is no patch to s-osinte-rtems.adb since the .ads binds directly to OS provided routines. -- joel at gcc dot gnu dot org changed: What|Removed |Added Attachment #15505|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug ada/35576] Ada HW Interrupt Task Enhancement
--- Comment #10 from joel at gcc dot gnu dot org 2008-05-28 16:33 --- Updated changelog entry. I missed adding the s-hwint-interr.adb file when I replaced my svn tree a while back. There are no modifications to s-osinte-rtems.adb. The .ads just binds to more routines provided by RTEMS. 2008-05-28 Joel Sherrill <[EMAIL PROTECTED]> * Makefile.in: Switch RTEMS and VxWorks to s-interr-hwint.adb. * s-interr-hwint.adb: New file with portable implementation. * s-interr-vxworks.adb: Removed. * s-osinte-rtems.ads, s-osinte-vxworks.adb, s-osinte-vxworks.ads: Add shared hardware interrupt adapter layer. RTEMS binds to OS provided adapter routines so there are no modifications to s-osinte-rtems.adb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576
[Bug target/32000] x86 backend uses aligned load on unaligned memory
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-28 16:58 --- Not a regression so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32000
[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2008-05-28 17:26
---
For the memory leak that happens from simplify_parameter_variable(), a reduced
testcase is:
integer, parameter :: MSKa1(1) = 1
integer, parameter :: ARR1 = MSKa1(1)
end
The reason for it is that when we change the expression rank in
simplify_parameter_variable(), we don't change the shape accordingly. I think
it should be done like that:
Index: expr.c
===
--- expr.c (revision 135515)
+++ expr.c (working copy)
@@ -1522,12 +1522,20 @@ simplify_parameter_variable (gfc_expr *p
{
gfc_expr *e;
try t;
+ int n;
e = gfc_copy_expr (p->symtree->n.sym->value);
if (e == NULL)
return FAILURE;
+ /* Copy the rank and shape from p, but first clear the existing shape. */
+ if (e->shape)
+for (n = 0; n < e->rank; n++)
+ mpz_clear (e->shape[n]);
+
+ gfc_free (e->shape);
e->rank = p->rank;
+ e->shape = gfc_copy_shape (p->shape, p->rank);
/* Do not copy subobject refs for constant. */
if (e->expr_type != EXPR_CONSTANT && p->ref != NULL)
That patch seems to regtest fine, but I don't see how it could fix the original
ICE.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
[Bug bootstrap/36180] [4.4 Regression] Multiple bootstrap failures due to revision 135069
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36180
[Bug fortran/36197] [4.4 Regressio]: gfortran.dg/initialization_12.f90
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
[Bug middle-end/36184] gimple-tuples-branch fails bootstrap on x86 Darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-28 18:51 --- It should be mentioned this is a stack overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36184
[Bug testsuite/36155] UTF tests doesn't work on Linux
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36155
[Bug testsuite/36196] gcc.dg/pr22231.c doesn't work
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36196
[Bug fortran/36263] gfortran.dg/bind_c_module.f90 doesn't work
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36263
[Bug fortran/36264] [4.4 Regression]: gfortran.dg/char_cast_2.f90
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36264
[Bug fortran/36271] [4.3 regression] Missed error with assignment to INTENT(IN) argument
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug fortran/36319] Segfault with wide characters in DATA
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-28 21:12 --- Subject: Bug 36319 Author: fxcoudert Date: Wed May 28 21:11:39 2008 New Revision: 136129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136129 Log: PR fortran/36319 * intrinsic.c (gfc_convert_chartype): Don't mark conversion function as pure. * trans-array.c (gfc_trans_array_ctor_element): Divide element size by the size of one character to obtain length. * iresolve.c (gfc_resolve_cshift): Call the _char4 variant when appropriate. (gfc_resolve_eoshift): Likewise. * trans-intrinsic.c (gfc_conv_intrinsic_ctime): Minor beautification. (gfc_conv_intrinsic_fdate): Minor beautification. (gfc_conv_intrinsic_ttynam): Minor beautification. (gfc_conv_intrinsic_minmax_char): Allow all character kinds. (size_of_string_in_bytes): New function. (gfc_conv_intrinsic_size): Call size_of_string_in_bytes for character expressions. (gfc_conv_intrinsic_sizeof): Likewise. (gfc_conv_intrinsic_array_transfer): Likewise. (gfc_conv_intrinsic_trim): Allow all character kinds. Minor beautification. (gfc_conv_intrinsic_repeat): Fix comment typo. * simplify.c (gfc_convert_char_constant): Take care of conversion of array constructors. * intrinsics/string_intrinsics_inc.c (string_index): Return correct value for zero-length substring. * intrinsics/cshift0.c: Add _char4 variant. * intrinsics/eoshift0.c (eoshift0): Allow filler to be a pattern wider than a single byte. Add _char4 variant and use above functionality. * intrinsics/eoshift2.c (eoshift2): Likewise. * m4/eoshift1.m4: Likewise. * m4/eoshift3.m4: Likewise. * m4/cshift1.m4: Add _char4 variants. * gfortran.map (GFORTRAN_1.1): Add _gfortran_cshift0_1_char4, _gfortran_cshift0_2_char4, _gfortran_cshift0_4_char4, _gfortran_cshift0_8_char4, _gfortran_cshift1_16_char4, _gfortran_cshift1_4_char4, _gfortran_cshift1_8_char4, _gfortran_eoshift0_1_char4, _gfortran_eoshift0_2_char4, _gfortran_eoshift0_4_char4, _gfortran_eoshift0_8_char4, _gfortran_eoshift1_16_char4, _gfortran_eoshift1_4_char4, _gfortran_eoshift1_8_char4, _gfortran_eoshift2_1_char4, _gfortran_eoshift2_2_char4, _gfortran_eoshift2_4_char4, _gfortran_eoshift2_8_char4, _gfortran_eoshift3_16_char4, _gfortran_eoshift3_4_char4 and _gfortran_eoshift3_8_char4. * generated/eoshift3_4.c: Regenerate. * generated/eoshift1_8.c: Regenerate. * generated/eoshift1_16.c: Regenerate. * generated/cshift1_4.c: Regenerate. * generated/eoshift1_4.c: Regenerate. * generated/eoshift3_8.c: Regenerate. * generated/eoshift3_16.c: Regenerate. * generated/cshift1_8.c: Regenerate. * generated/cshift1_16.c: Regenerate. * gfortran.dg/widechar_5.f90: New file. * gfortran.dg/widechar_6.f90: New file. * gfortran.dg/widechar_7.f90: New file. * gfortran.dg/widechar_intrinsics_5.f90: Uncomment the lines testing the SPREAD intrinsic. * gfortran.dg/widechar_intrinsics_6.f90: New file. * gfortran.dg/widechar_intrinsics_7.f90: New file. * gfortran.dg/widechar_intrinsics_8.f90: New file. * gfortran.dg/widechar_intrinsics_9.f90: New file. * gfortran.dg/widechar_intrinsics_10.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/widechar_5.f90 trunk/gcc/testsuite/gfortran.dg/widechar_6.f90 trunk/gcc/testsuite/gfortran.dg/widechar_7.f90 trunk/gcc/testsuite/gfortran.dg/widechar_intrinsics_10.f90 trunk/gcc/testsuite/gfortran.dg/widechar_intrinsics_6.f90 trunk/gcc/testsuite/gfortran.dg/widechar_intrinsics_7.f90 trunk/gcc/testsuite/gfortran.dg/widechar_intrinsics_8.f90 trunk/gcc/testsuite/gfortran.dg/widechar_intrinsics_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/iresolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/widechar_intrinsics_5.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/generated/cshift1_16.c trunk/libgfortran/generated/cshift1_4.c trunk/libgfortran/generated/cshift1_8.c trunk/libgfortran/generated/eoshift1_16.c trunk/libgfortran/generated/eoshift1_4.c trunk/libgfortran/generated/eoshift1_8.c trunk/libgfortran/generated/eoshift3_16.c trunk/libgfortran/generated/eoshift3_4.c trunk/libgfortran/generated/eoshift3_8.c trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/cshift0.c trunk/libgfortran/intrinsics/eoshift0.c trunk/libgfortran/intrinsics/eoshift2.c trunk/libgfortran/intrinsics/string
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #12 from janus at gcc dot gnu dot org 2008-05-28 21:28 --- Subject: Bug 36325 Author: janus Date: Wed May 28 21:27:56 2008 New Revision: 136130 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136130 Log: 2008-05-28 Janus Weil <[EMAIL PROTECTED]> PR fortran/36325 PR fortran/35830 * interface.c (gfc_procedure_use): Enable argument checking for external procedures with explicit interface. * symbol.c (check_conflict): Fix conflict checking for externals. (copy_formal_args): Fix handling of arrays. * resolve.c (resolve_specific_f0, resolve_specific_s0): Fix handling of intrinsics. * parse.c (parse_interface): Non-abstract INTERFACE statement implies EXTERNAL attribute. 2008-05-28 Janus Weil <[EMAIL PROTECTED]> PR fortran/36325 PR fortran/35830 * gfortran.dg/interface_23.f90: New. * gfortran.dg/gomp/reduction3.f90: Fixed invalid code. * gfortran.dg/proc_decl_12.f90: New: * gfortran.dg/external_procedures_1.f90: Fixed error message. Added: trunk/gcc/testsuite/gfortran.dg/interface_23.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/reduction3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #7 from janus at gcc dot gnu dot org 2008-05-28 21:28 --- Subject: Bug 35830 Author: janus Date: Wed May 28 21:27:56 2008 New Revision: 136130 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=136130 Log: 2008-05-28 Janus Weil <[EMAIL PROTECTED]> PR fortran/36325 PR fortran/35830 * interface.c (gfc_procedure_use): Enable argument checking for external procedures with explicit interface. * symbol.c (check_conflict): Fix conflict checking for externals. (copy_formal_args): Fix handling of arrays. * resolve.c (resolve_specific_f0, resolve_specific_s0): Fix handling of intrinsics. * parse.c (parse_interface): Non-abstract INTERFACE statement implies EXTERNAL attribute. 2008-05-28 Janus Weil <[EMAIL PROTECTED]> PR fortran/36325 PR fortran/35830 * gfortran.dg/interface_23.f90: New. * gfortran.dg/gomp/reduction3.f90: Fixed invalid code. * gfortran.dg/proc_decl_12.f90: New: * gfortran.dg/external_procedures_1.f90: Fixed error message. Added: trunk/gcc/testsuite/gfortran.dg/interface_23.f90 trunk/gcc/testsuite/gfortran.dg/proc_decl_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/external_procedures_1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/reduction3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug fortran/35830] ICE with PROCEDURE() containing array formal arguments
--- Comment #8 from janus at gcc dot gnu dot org 2008-05-28 21:34 --- rev. 136130 contains the fixes from comment #2 and comment #3, but the test case from comment #1 is still failing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35830
[Bug target/36358] New: -mvrsave / -mno-vrsave ignored
The -m[no-]vrsave option is ignored on 4.3.0 (and it seems on the trunk as of 2008/5/28 it still is). Note the old form -mvrsave=no does work. Other -m[no-] options also fail to work with 4.3.0 but (at least some) of them have apparently been fixed on the trunk (as of today) but -m[no-]vrsave has not. -- Summary: -mvrsave / -mno-vrsave ignored Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: strauman at slac dot stanford dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-unknown-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36358
[Bug target/36358] -mvrsave / -mno-vrsave ignored
--- Comment #1 from strauman at slac dot stanford dot edu 2008-05-28 21:35 --- Created an attachment (id=15693) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15693&action=view) suggested fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36358
[Bug fortran/36325] specific or generic INTERFACE implies the EXTERNAL attribute
--- Comment #13 from janus at gcc dot gnu dot org 2008-05-28 21:37 --- Fixed with r136130. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36325
[Bug fortran/36275] Binding label can be any scalar char initialisation expression
--- Comment #3 from janus at gcc dot gnu dot org 2008-05-28 21:58 ---
The problem in comment #2 was indeed introduced by my rev. 134867, and can be
fixed by the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 136130)
+++ gcc/fortran/resolve.c (working copy)
@@ -7751,6 +7751,7 @@ resolve_symbol (gfc_symbol *sym)
{
sym->ts.type = sym->ts.interface->ts.type;
sym->ts.kind = sym->ts.interface->ts.kind;
+ sym->ts.is_c_interop = sym->ts.interface->ts.is_c_interop;
sym->attr.function = sym->ts.interface->attr.function;
sym->attr.subroutine = sym->ts.interface->attr.subroutine;
copy_formal_args (sym, sym->ts.interface);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36275
[Bug target/35100] [4.1/4.2/4.3/4.4 regression] internal compiler error: in extract_insn, at recog.c:1990
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
[Bug middle-end/36262] [4.3/4.4 Regression] Extreme memory usage of VRP compared to older versions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
[Bug fortran/36271] [4.3 regression] Missed error with assignment to INTENT(IN) argument
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||accepts-invalid Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36271
[Bug fortran/36276] [4.3/4.4 Regression] possible issue with opening fortran files?
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug middle-end/36278] [4.2/4.3/4.4 Regression] ICE with typedef void in namespace and using the defined type in another when compiling with "-g"
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
[Bug middle-end/36300] [4.1/4.2 Regression] Incorrect type used for inlined expression
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2 Regression] |Incorrect type used for |Incorrect type used for |inlined expression |inlined expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36300
[Bug tree-optimization/36343] [4.3/4.4 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug testsuite/36344] [4.3/4.4 Regression] gcc.dg/tree-ssa/loadpre8.c XFAILed
-- rguenth 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-05-28 22:12:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36344
[Bug c/36359] New: [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
Hi I've tested gcc-4.4 with the current developer kernel 2.6.26-rc4 and got the following compile error: ... Setup is 12236 bytes (padded to 12288 bytes). System is 2521 kB CRC 735d1682 Kernel: arch/x86/boot/bzImage is ready (#62) Building modules, stage 2. MODPOST 222 modules ERROR: "ilog2_NaN" [drivers/usb/core/usbcore.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 This can be avoided when switching on the OPTIMIZE_SIZE kconfig option which in fact replaces the standard -O2 option with -Os, so I think there must be something wrong in what -O2 does. This happens only with gcc-4.4 not with gcc-4.3 and before (I've also tested gcc-4.1). The latest gcc-4.4 version I tested was 20080526. I compiled gcc without any options to ./configure. I'll try to attach my config file so you might be able to reproduce the error. This has been reported to lkml. The discussion can be read here: http://lkml.org/lkml/2008/5/25/169. Thanks Mirco -- Summary: [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mt-ml at gmx dot de GCC build triplet: none GCC host triplet: ubuntu linux 8.10 (dev) GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
