[Bug fortran/36091] false positive in bounds checking with forall

[pault at gcc dot gnu dot org]

--- Comment #8 from pault at gcc dot gnu dot org  2009-04-06 05:26 ---
Subject: Bug 36091

Author: pault
Date: Mon Apr  6 05:25:46 2009
New Revision: 145581

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145581
Log:
2009-04-06  Paul Thomas  

PR fortran/36091
* trans-array.c (gfc_conv_array_ref): If the symbol has the
temporary attribute use the array_spec for the bounds.
* gfortran.h : Add the temporary field to the structure
'symbol_attribute'.
* trans-stmt.c (forall_make_variable_temp): Set the symbol's
temporary attribute.

2009-04-06  Paul Thomas  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091

[Bug c++/39658] New: "wrong number of template arguments" in variadic template specialization

[me22 dot ca at gmail dot com]

vartembug.cxx:25: error: wrong number of template arguments (3, should be 4 or
more)
vartembug.cxx:8: error: provided for ‘template struct
bitstring_entry_attributes’

>From the following code:


template <
bool found_label,
bool found_size,
bool found_sign,
bool found_endian,
typename... Args
>
struct bitstring_entry_attributes {
};

template <
bool found_size,
bool found_sign,
bool found_endian,
typename Arg,
typename... Args
>
struct bitstring_entry_attributes<
false,
found_size,
found_sign
found_endian,
Arg, 
Args...
> {
};


$ g++-4.3.3 -v -save-temps -std=gnu++0x vartembug.cxx
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/gcc-4.3.3/configure --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--enable-cld --disable-libgcj --enable-languages=c,c++,treelang --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.3-r2 p1.1,
pie-10.1.5'
Thread model: posix
gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-shared-libgcc'
'-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE
vartembug.cxx -D_FORTIFY_SOURCE=2 -mtune=generic -std=gnu++0x -fpch-preprocess
-o vartembug.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include/g++-v4/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=gnu++0x' '-shared-libgcc'
'-mtune=generic'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.3.3/cc1plus -fpreprocessed vartembug.ii
-quiet -dumpbase vartembug.cxx -mtune=generic -auxbase vartembug -std=gnu++0x
-version -o vartembug.s
GNU C++ (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) version 4.3.3 (x86_64-pc-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version
2.4.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 99eb7989473b1a2e92eed91867d56b9a


Of interest is that removing 2 of the non-variadic arguments/parameters (giving
the following) compiles fine:


template <
bool found_label,
bool found_endian,
typename... Args
>
struct bitstring_entry_attributes {
};

template <
bool found_endian,
typename Arg,
typename... Args
>
struct bitstring_entry_attributes<
false,
found_endian,
Arg, 
Args...
> {
};


-- 
   Summary: "wrong number of template arguments" in variadic
template specialization
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: me22 dot ca at gmail dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

--- Comment #13 from hp at gcc dot gnu dot org  2009-04-06 02:55 ---
(In reply to comment #7)
> Please, let me know how it goes as far as the fails related to log2* are
> concerned.

Revision 145575 only had these following libstdc++ regressions remaining (not
counting the new FAILs), where the log messages are consistent with a
stdint.h-related flaw only; all log2l-related FAILs are fixed AFAICT.

libstdc++.sum 17_intro/using_namespace_std_tr1_neg.cc
libstdc++.sum 26_numerics/headers/random/types_std_c++0x.cc

Thanks!  Hopefully I'll find time to analyze the stdint.h-related FAILs more
thoroughly, but I can't commit to that.


-- 


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

[Bug c++/39656] g++.dg/template/error39.C failed

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-04-06 00:56 ---
Fixed.  I accidentally committed a version of the test with typos.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug pending/39657] [4.3 Regression] compiling ruby (yacc) output takes inordinate amount of time on x86 with -O2

[vapier at gentoo dot org]

--- Comment #1 from vapier at gentoo dot org  2009-04-06 00:50 ---
Created an attachment (id=17592)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17592&action=view)
parse_.i

$ time gcc -c -O2 parse_.i
real5m16.777s
user5m14.586s
sys 0m1.545s


-- 


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

[Bug pending/39657] New: [4.3 Regression] compiling ruby (yacc) output takes inordinate amount of time on x86 with -O2

[vapier at gentoo dot org]

gcc 4.1, 4.2, and 4.4 all take less than 30 seconds to compile this file.  but
gcc-4.3 can easily take more like 5 minutes.

the file comes from the preprocessed output of a file in the ruby package.


-- 
   Summary: [4.3 Regression] compiling ruby (yacc) output takes
inordinate amount of time on x86 with -O2
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pending
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vapier at gentoo dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[amylaar at gcc dot gnu dot org]

--- Comment #25 from amylaar at gcc dot gnu dot org  2009-04-06 00:37 
---
(In reply to comment #24)
> Which testcase?

The second attachment, 20367-sched.c

>  This bug is mildly confusing.  Note that i is a global
> variable,

If you mean i in f of comment #2, that's not gloabal, but static.

> it may be reached via recursive invocations of the function and
> we do not have analysis that disproves this.

I suppose you mean that f may be reached via recursion, thus
clobbering i, as already mentioned in comment #7.

Unfortunately, the original testcase went into the big bit bucket in the sky,
and when you try to make up a minimal example on the spot, you are bound to
overlook the very same aspects of the problem you have overlooked in the
work on the problm so far.

But there is still code in EEMBC that genuinely benefits from load hoisting /
store sinking and scheduling which is enabled by recognizing that a static
variable that hasn't got its address taken can't alias another MEM - in some
cases, the static variable can be completely replaced by a local variable,
in other cases, it can't (without whole-program analysis) because an
indirect recursive call cannot be ruled out.


-- 


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

[Bug c++/39656] New: g++.dg/template/error39.C failed

[hjl dot tools at gmail dot com]

g++.dg/template/error39.C failed on Linux/ia32:

FAIL: g++.dg/template/error39.C (test for excess errors)


-- 
   Summary: g++.dg/template/error39.C failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2009-04-05 23:38 ---
(In reply to comment #10)
> Hans-Peter, please understand that this code is brand new,

I *do* understand.  Please don't misunderstand the intent here.  Just because I
report regressions or follow-up requests doesn't mean I insist on it being
handled as a priority issue, not more so than any other regression.

> contributed by an
> external friend of the project. Thus, if you spot something trivial, like a
> typo, definitely improving the build on your system, just go ahead,

That goes without saying, really.  I do that, sometimes, depending on
priorities and whatnot.  Don't expect much on weekends; I don't...
I do try to be clear and complete and quick enough with regression reports, but
anything more than that has to compete with other priorities.

My earlier comment was just a quick pasting from intermediate results from an
autotester run in-progress, in response to your request.  So, I was able to
quickly report something that went wrong, but couldn't verify complete
correctness in that same time-frame, not to the level that I'd be comfortable
checking in a fix, at least this time, right or wrong.  I had a brief look, but
wasn't sufficiently sure that it was worth the effort to set up and regtest
manually after removing a ")", also considering the likelihood that it was
already done.  I figured you or someone else with svn write access, a clue and
a just-built tree were about to notice yourself, and that a fix would be
committed by the time my autester would start the next round and I'd be able to
verify any correction without setting up a test-run manually.

And even if wasn't so, I'm not expecting (or expecting anyone to expect) quick
fixes, certainly not in less than a day at this time of the week.

...and there you go, the autotester has finished the earlier round (with the
typo) and has picked up the correction (thanks!)  I'll know in about 2h, which
perhaps an hour or at most two later than best.
If I'm awake that is.

So, while I'm thankful for the quick response, I'm not expecting it.


-- 


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

[Bug libstdc++/39629] [4.5 Regression] Revision 145483 caused many libstdc++ failures

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2009-04-05 22:52 
---
Indeed, the fix is marked as *partial*.


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2009-04-05 22:47 
---
wake up, of course ;)


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2009-04-05 22:46 
---
Hans-Peter, please understand that this code is brand new, contributed by an
external friend of the project. Thus, if you spot something trivial, like a
typo, definitely improving the build on your system, just go ahead, don't wait
for me to weak up maybe in a different time zone, or whatever. Thanks in
advance.


-- 


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

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2009-04-05 22:46 ---
Subject: Bug 39648

Author: hjl
Date: Sun Apr  5 22:45:59 2009
New Revision: 145574

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145574
Log:
2009-04-05  H.J. Lu  

Backport from mainline:
2009-04-05  Richard Guenther  

PR tree-optimization/39648
* gcc.c-torture/compile/pr39648.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39648.c
  - copied unchanged from r145573,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39648.c
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/39629] [4.5 Regression] Revision 145483 caused many libstdc++ failures

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.5 Regression] Revision   |[4.5 Regression] Revision
   |145483 may have caused many |145483 caused many libstdc++
   |failures|failures
   Target Milestone|--- |4.5.0


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

[Bug libstdc++/39629] [4.5 Regression] Revision 145483 may have caused many failures

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2009-04-05 22:42 
---
As of revision 145565, I still see

FAIL: 26_numerics/random/knuth_b.cc execution test
FAIL: 26_numerics/random/piecewise_linear_distribution/operators/serialize.cc
execution test
FAIL: 26_numerics/random/ranlux48.cc execution test
FAIL: 26_numerics/random/ranlux48_base.cc execution test

for Linux/ia32 target.


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #9 from paolo dot carlini at oracle dot com  2009-04-05 22:41 
---
Humpf, I see a spurious closed parenthesis for the weakly tested so far case of
_GLIBCXX_USE_C99_MATH_TR1 undefined. In fact, all this math should be probably
done better, but I'm going to remove the parenthesis, let's see if we can move
ahead.


-- 


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

[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4/4.5

[jvdelisle at gcc dot gnu dot org]

--- Comment #15 from jvdelisle at gcc dot gnu dot org  2009-04-05 22:35 
---
Fixed on 4.5, good for 4.4 after some main line testing/exercise.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4/4.5 Regression] READ   |[4.4 Regression] READ I/O
   |I/O Performance regression  |Performance regression from
   |from 4.3 to 4.4/4.5 |4.3 to 4.4/4.5


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2009-04-05 22:24 ---
(In reply to comment #7)
> Please, let me know how it goes as far as the fails related to log2* are
> concerned.

Revision r145563 seems to have a typo.  I now see in the .log (beware,
cutnpaste):
...
compiler exited with status 1
output is:
In file included from
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/random:58,
 from
/tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc:122:
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:
In member function 'result_type std:
:piecewise_linear_distribution<_RealType>::operator()(_UniformRandomNumberGenerator&,
const std::piecewise_linear_distribution<_RealType>::param_type&)':
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/bits/random.tcc:2598:
error: expected ',' or ';' before ')' token

FAIL: 17_intro/headers/c++200x/all.cc (test for excess errors)


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[rainer at emrich-ebersheim dot de]

--- Comment #19 from rainer at emrich-ebersheim dot de  2009-04-05 22:18 
---
(In reply to comment #18)
> > Is there a supported platform currently using FE SJLJ?
> 
> Windows.
> 

I confirm the exactly same issue for i686-pc-cygwin. And I think it is the same
for the *mingw32 targets.


-- 


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

[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2009-04-05 22:05 ---
Created an attachment (id=17591)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17591&action=view)
Reduced gcc.dg/torture/builtin-math-3.c

The two lines causing link_error() to be called as in the linker error messages
are cut out and the condition is reduced such that the emitted assembly-code is
still identical.  Compile with e.g. -O1.  Observe libcalls for "<=" and ">="
being called for constants, while in the pre-regression code, everything is
optimized out to the effect of "return 0;"


-- 


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

[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2009-04-05 22:00 ---
(In reply to comment #1)
> Can you 1) reduce the testcase and attach preprocessed source that
> works with a cross-compiler,

The test-case was already self-contained and had little context-sensitiveness
due to the line-oriented nature, so I didn't expect you to need this.

> 2) identify what goes wrong so we don't
> have to analyze cris assembler?

This is a bit worrying.  Surely you didn't think this would ever be needed, for
a test-case where the nature of the failure is that it emits a subroutine call
to link_error()?  Again, the regression is a missing optimization of sincos for
a soft-float target, as already mentioned in the summary and description.

Anyway, one reduced test-case coming up.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-05 22:00:23
   date||


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[ebotcazou at gcc dot gnu dot org]

--- Comment #18 from ebotcazou at gcc dot gnu dot org  2009-04-05 21:43 
---
> Is there a supported platform currently using FE SJLJ?

Windows.


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[rob1weld at aol dot com]

--- Comment #17 from rob1weld at aol dot com  2009-04-05 20:53 ---
> I've found machines and hosting to add i686
What a great guy!

More patches / support files / etc.

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

ports/lang/gcc/4.3/patches/
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/4.3/patches/

ports/lang/gcc/3.3/
http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/3.3/

Back in an hour,
Rob


-- 


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

[Bug fortran/29962] Initialization expressions

[dfranke at gcc dot gnu dot org]

--- Comment #15 from dfranke at gcc dot gnu dot org  2009-04-05 20:40 
---
Subject: Bug 29962

Author: dfranke
Date: Sun Apr  5 20:40:13 2009
New Revision: 145573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145573
Log:
gcc/fortran/:
2009-04-05  Daniel Franke  

PR fortran/25104
PR fortran/29962
* check.c (gfc_check_all_any): Check rank of DIM.
(gfc_check_count): Likewise.
* intrinsic.h (gfc_simplify_all): New prototype.
(gfc_simplify_any): Likewise.
(gfc_simplify_count): Likewise.
(gfc_simplify_sum): Likewise.
(gfc_simplify_product): Likewise.
* intrinsic.c (add_functions): Added new simplifier callbacks.
* simplify.c (transformational_result): New.
(simplify_transformation_to_scalar): New.
(simplify_transformation_to_array): New.
(gfc_count): New.
(gfc_simplify_all): New.
(gfc_simplify_any): New.
(gfc_simplify_count): New.
(gfc_simplify_sum): New.
(gfc_simplify_product): New.
* expr.c (check_transformational): Allow additional transformational
intrinsics in initialization expression.

gcc/testsuite/:
2009-04-05  Daniel Franke  

PR fortran/25104
PR fortran/29962
* gfortran.dg/count_init_expr.f03
* gfortran.dg/product_init_expr.f03
* gfortran.dg/sum_init_expr.f03


Added:
branches/fortran-dev/gcc/testsuite/gfortran.dg/count_init_expr.f03
branches/fortran-dev/gcc/testsuite/gfortran.dg/product_init_expr.f03
branches/fortran-dev/gcc/testsuite/gfortran.dg/sum_init_expr.f03
Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.dev
branches/fortran-dev/gcc/fortran/check.c
branches/fortran-dev/gcc/fortran/expr.c
branches/fortran-dev/gcc/fortran/intrinsic.c
branches/fortran-dev/gcc/fortran/intrinsic.h
branches/fortran-dev/gcc/fortran/simplify.c
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


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

[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector

[dfranke at gcc dot gnu dot org]

--- Comment #12 from dfranke at gcc dot gnu dot org  2009-04-05 20:40 
---
Subject: Bug 25104

Author: dfranke
Date: Sun Apr  5 20:40:13 2009
New Revision: 145573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145573
Log:
gcc/fortran/:
2009-04-05  Daniel Franke  

PR fortran/25104
PR fortran/29962
* check.c (gfc_check_all_any): Check rank of DIM.
(gfc_check_count): Likewise.
* intrinsic.h (gfc_simplify_all): New prototype.
(gfc_simplify_any): Likewise.
(gfc_simplify_count): Likewise.
(gfc_simplify_sum): Likewise.
(gfc_simplify_product): Likewise.
* intrinsic.c (add_functions): Added new simplifier callbacks.
* simplify.c (transformational_result): New.
(simplify_transformation_to_scalar): New.
(simplify_transformation_to_array): New.
(gfc_count): New.
(gfc_simplify_all): New.
(gfc_simplify_any): New.
(gfc_simplify_count): New.
(gfc_simplify_sum): New.
(gfc_simplify_product): New.
* expr.c (check_transformational): Allow additional transformational
intrinsics in initialization expression.

gcc/testsuite/:
2009-04-05  Daniel Franke  

PR fortran/25104
PR fortran/29962
* gfortran.dg/count_init_expr.f03
* gfortran.dg/product_init_expr.f03
* gfortran.dg/sum_init_expr.f03


Added:
branches/fortran-dev/gcc/testsuite/gfortran.dg/count_init_expr.f03
branches/fortran-dev/gcc/testsuite/gfortran.dg/product_init_expr.f03
branches/fortran-dev/gcc/testsuite/gfortran.dg/sum_init_expr.f03
Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.dev
branches/fortran-dev/gcc/fortran/check.c
branches/fortran-dev/gcc/fortran/expr.c
branches/fortran-dev/gcc/fortran/intrinsic.c
branches/fortran-dev/gcc/fortran/intrinsic.h
branches/fortran-dev/gcc/fortran/simplify.c
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[laurent at guerby dot net]

--- Comment #16 from laurent at guerby dot net  2009-04-05 20:23 ---
I've found machines and hosting to add i686 free/net/openBSD to the compile
farm, they should be online in the coming weeks, this allow smoother GCC
development and testing on these platforms.

http://gcc.gnu.org/wiki/CompileFarm


-- 


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

[Bug libfortran/38654] Fortran I/O speedup

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-04-05 20:23 
---
Subject: Bug 38654

Author: jvdelisle
Date: Sun Apr  5 20:23:21 2009
New Revision: 145572

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145572
Log:
2009-04-05  Daniel Kraft  

PR fortran/38654
* gfortran.dg/read_float_2.f03
* gfortran.dg/read_float_3.f90

Added:
trunk/gcc/testsuite/gfortran.dg/read_float_2.f03
trunk/gcc/testsuite/gfortran.dg/read_float_3.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared

[vapier at gentoo dot org]

--- Comment #7 from vapier at gentoo dot org  2009-04-05 20:18 ---
we've hit this with gcc-4.3.3 with arm-softfloat-linux-gnueabi targets, and the
commit in question was for PR38000:
http://gcc.gnu.org/viewcvs?view=rev&revision=143194

/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/gcc-4.3.3/libstdc++-v3/include/precompiled/stdtr1c++.h:38:
/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/build/arm-softfloat-linux-gnueabi/libstdc++-v3/include/tr1_impl/cfenv:56:
error: '::fenv_t' has not been declared
/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/build/arm-softfloat-linux-gnueabi/libstdc++-v3/include/tr1_impl/cfenv:57:
error: '::fexcept_t' has not been declared
/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/build/arm-softfloat-linux-gnueabi/libstdc++-v3/include/tr1_impl/cfenv:60:
error: '::feclearexcept' has not been declared
/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/build/arm-softfloat-linux-gnueabi/libstdc++-v3/include/tr1_impl/cfenv:61:
error: '::fegetexceptflag' has not been declared
/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/build/arm-softfloat-linux-gnueabi/libstdc++-v3/include/tr1_impl/cfenv:62:
error: '::feraiseexcept' has not been declared
/usr/arm-softfloat-linux-gnueabi/tmp/portage/sys-devel/gcc-4.3.3/work/build/arm-softfloat-linux-gnueabi/libstdc++-v3/include/tr1_impl/cfenv:63:
error: '::fesetexceptflag' has not been declared

adding "-nostdinc++" to libstdc++-v3/include/Makefile.am seemed to fix it ...


-- 

vapier at gentoo dot org changed:

   What|Removed |Added

 CC||toolchain at gentoo dot org


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

[Bug middle-end/39650] [4.5 regression] Revision 145533 breaks SPEC CPU 2K/2006

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-04-05 20:18 ---
Should be fixed now.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[rguenth at gcc dot gnu dot org]

--- Comment #24 from rguenth at gcc dot gnu dot org  2009-04-05 20:17 
---
Which testcase?  This bug is mildly confusing.  Note that i is a global
variable, it may be reached via recursive invocations of the function and
we do not have analysis that disproves this.


-- 


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

[Bug libfortran/25561] Eventually get rid of the Alloc Stream Facility

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2009-04-05 20:14 
---
Subject: Bug 25561

Author: jvdelisle
Date: Sun Apr  5 20:13:56 2009
New Revision: 145571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145571
Log:
2009-04-05  Daniel Kraft  

PR fortran/38654
* io/read.c (read_f): Reworked to speed up floating point parsing.
(convert_real): Use pointer-casting instead of memcpy and temporaries.

2009-04-05  Jerry DeLisle  

PR libfortran/37754
* io/io.h (format_hash_entry): New structure for hash table.
(format_hash_table): The hash table itself.
(free_format_data): Revise function prototype.
(free_format_hash_table, init_format_hash,
free_format_hash): New function prototypes.
* io/unit.c (close_unit_1): Use free_format_hash_table.
* io/transfer.c (st_read_done, st_write_done): Free format data if
internal unit.
* io/format.c (free_format_hash_table): New function that frees any
memory allocated previously for cached format data.
(reset_node): New static helper function to reset the format counters
for a format node.
(reset_fnode_counters): New static function recursively calls
reset_node
to traverse the fnode tree.
(format_hash): New simple hash function based on XOR, probabalistic,
tosses collisions.
(save_parsed_format): New static function to save the parsed format
data to use again.
(find_parsed_format): New static function searches the hash table
looking for a match.
(free_format_data): Revised to accept pointer to format data rather
than
the dtp pointer so that the function can be used in more places.
(format_lex): Editorial.
(parse_format_list): Set flag used to determine of format data hashing
is to be used.  Internal units are not persistent enough for this.
(revert): Move to ne location in file.
(parse_format): Use new functions to look for previously parsed
format strings and use them rather than re-parse.  If not found, saves
the parsed format data for later use.

2009-04-05  Jerry DeLisle  

PR libfortran/37754
* io/transfer.c (formatted_transfer_scalar): Remove this function by
factoring it into two new functions, one for read and one for write,
eliminating all the conditionals for read or write mode.
(formatted transfer_scalar_read): New function.
(formatted transfer_scalar_write): New function.
(formatted_transfer): Use new functions.

2009-04-05  Janne Blomqvist  

PR libfortran/25561 libfortran/37754
* io/io.h (struct stream): Define new stream interface function
pointers, and inline functions for accessing it.
(struct fbuf): Use int instead of size_t, remove flushed element.
(mem_alloc_w): New prototype.
(mem_alloc_r): New prototype.
(stream_at_bof): Remove prototype.
(stream_at_eof): Remove prototype.
(file_position): Remove prototype.
(flush): Remove prototype.
(stream_offset): Remove prototype.
(unit_truncate): New prototype.
(read_block_form): Change to return pointer, int* argument.
(hit_eof): New prototype.
(fbuf_init): Change prototype.
(fbuf_reset): Change prototype.
(fbuf_alloc): Change prototype.
(fbuf_flush): Change prototype.
(fbuf_seek): Change prototype.
(fbuf_read): New prototype.
(fbuf_getc_refill): New prototype.
(fbuf_getc): New inline function.
* io/fbuf.c (fbuf_init): Use int, get rid of flushed.
(fbuf_debug): New function.
(fbuf_reset): Flush, and return position offset.
(fbuf_alloc): Simplify, don't flush, just realloc.
(fbuf_flush): Make usable for read mode, salvage remaining bytes.
(fbuf_seek): New whence argument.
(fbuf_read): New function.
(fbuf_getc_refill): New function.
* io/file_pos.c (formatted_backspace): Use new stream interface.
(unformatted_backspace): Likewise.
(st_backspace): Make sure format buffer is reset, use new stream
interface, use unit_truncate.
(st_endfile): Likewise.
(st_rewind): Likewise.
* io/intrinsics.c: Use new stream interface.
* io/list_read.c (push_char): Don't use u.p.scratch, use realloc
to resize.
(free_saved): Don't check u.p.scratch.
(next_char): Use new stream interface, use fbuf_getc() for external
files.
(finish_list_read): flush format buffer.
(nml_query): Update to use modified interface:s
* io/open.c (test_endfile): Use new stream interface.
(edit_modes): Likewise.
(new_unit): Likewise, set bytes_left to 1 for stream files.
* io/read.c (read_l): Use new read_block_form interface.
(read_utf8): Likewise

[Bug libfortran/38654] Fortran I/O speedup

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-04-05 20:14 
---
Subject: Bug 38654

Author: jvdelisle
Date: Sun Apr  5 20:13:56 2009
New Revision: 145571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145571
Log:
2009-04-05  Daniel Kraft  

PR fortran/38654
* io/read.c (read_f): Reworked to speed up floating point parsing.
(convert_real): Use pointer-casting instead of memcpy and temporaries.

2009-04-05  Jerry DeLisle  

PR libfortran/37754
* io/io.h (format_hash_entry): New structure for hash table.
(format_hash_table): The hash table itself.
(free_format_data): Revise function prototype.
(free_format_hash_table, init_format_hash,
free_format_hash): New function prototypes.
* io/unit.c (close_unit_1): Use free_format_hash_table.
* io/transfer.c (st_read_done, st_write_done): Free format data if
internal unit.
* io/format.c (free_format_hash_table): New function that frees any
memory allocated previously for cached format data.
(reset_node): New static helper function to reset the format counters
for a format node.
(reset_fnode_counters): New static function recursively calls
reset_node
to traverse the fnode tree.
(format_hash): New simple hash function based on XOR, probabalistic,
tosses collisions.
(save_parsed_format): New static function to save the parsed format
data to use again.
(find_parsed_format): New static function searches the hash table
looking for a match.
(free_format_data): Revised to accept pointer to format data rather
than
the dtp pointer so that the function can be used in more places.
(format_lex): Editorial.
(parse_format_list): Set flag used to determine of format data hashing
is to be used.  Internal units are not persistent enough for this.
(revert): Move to ne location in file.
(parse_format): Use new functions to look for previously parsed
format strings and use them rather than re-parse.  If not found, saves
the parsed format data for later use.

2009-04-05  Jerry DeLisle  

PR libfortran/37754
* io/transfer.c (formatted_transfer_scalar): Remove this function by
factoring it into two new functions, one for read and one for write,
eliminating all the conditionals for read or write mode.
(formatted transfer_scalar_read): New function.
(formatted transfer_scalar_write): New function.
(formatted_transfer): Use new functions.

2009-04-05  Janne Blomqvist  

PR libfortran/25561 libfortran/37754
* io/io.h (struct stream): Define new stream interface function
pointers, and inline functions for accessing it.
(struct fbuf): Use int instead of size_t, remove flushed element.
(mem_alloc_w): New prototype.
(mem_alloc_r): New prototype.
(stream_at_bof): Remove prototype.
(stream_at_eof): Remove prototype.
(file_position): Remove prototype.
(flush): Remove prototype.
(stream_offset): Remove prototype.
(unit_truncate): New prototype.
(read_block_form): Change to return pointer, int* argument.
(hit_eof): New prototype.
(fbuf_init): Change prototype.
(fbuf_reset): Change prototype.
(fbuf_alloc): Change prototype.
(fbuf_flush): Change prototype.
(fbuf_seek): Change prototype.
(fbuf_read): New prototype.
(fbuf_getc_refill): New prototype.
(fbuf_getc): New inline function.
* io/fbuf.c (fbuf_init): Use int, get rid of flushed.
(fbuf_debug): New function.
(fbuf_reset): Flush, and return position offset.
(fbuf_alloc): Simplify, don't flush, just realloc.
(fbuf_flush): Make usable for read mode, salvage remaining bytes.
(fbuf_seek): New whence argument.
(fbuf_read): New function.
(fbuf_getc_refill): New function.
* io/file_pos.c (formatted_backspace): Use new stream interface.
(unformatted_backspace): Likewise.
(st_backspace): Make sure format buffer is reset, use new stream
interface, use unit_truncate.
(st_endfile): Likewise.
(st_rewind): Likewise.
* io/intrinsics.c: Use new stream interface.
* io/list_read.c (push_char): Don't use u.p.scratch, use realloc
to resize.
(free_saved): Don't check u.p.scratch.
(next_char): Use new stream interface, use fbuf_getc() for external
files.
(finish_list_read): flush format buffer.
(nml_query): Update to use modified interface:s
* io/open.c (test_endfile): Use new stream interface.
(edit_modes): Likewise.
(new_unit): Likewise, set bytes_left to 1 for stream files.
* io/read.c (read_l): Use new read_block_form interface.
(read_utf8): Likewise.

[Bug libfortran/37754] [4.4/4.5 Regression] READ I/O Performance regression from 4.3 to 4.4/4.5

[jvdelisle at gcc dot gnu dot org]

--- Comment #14 from jvdelisle at gcc dot gnu dot org  2009-04-05 20:14 
---
Subject: Bug 37754

Author: jvdelisle
Date: Sun Apr  5 20:13:56 2009
New Revision: 145571

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145571
Log:
2009-04-05  Daniel Kraft  

PR fortran/38654
* io/read.c (read_f): Reworked to speed up floating point parsing.
(convert_real): Use pointer-casting instead of memcpy and temporaries.

2009-04-05  Jerry DeLisle  

PR libfortran/37754
* io/io.h (format_hash_entry): New structure for hash table.
(format_hash_table): The hash table itself.
(free_format_data): Revise function prototype.
(free_format_hash_table, init_format_hash,
free_format_hash): New function prototypes.
* io/unit.c (close_unit_1): Use free_format_hash_table.
* io/transfer.c (st_read_done, st_write_done): Free format data if
internal unit.
* io/format.c (free_format_hash_table): New function that frees any
memory allocated previously for cached format data.
(reset_node): New static helper function to reset the format counters
for a format node.
(reset_fnode_counters): New static function recursively calls
reset_node
to traverse the fnode tree.
(format_hash): New simple hash function based on XOR, probabalistic,
tosses collisions.
(save_parsed_format): New static function to save the parsed format
data to use again.
(find_parsed_format): New static function searches the hash table
looking for a match.
(free_format_data): Revised to accept pointer to format data rather
than
the dtp pointer so that the function can be used in more places.
(format_lex): Editorial.
(parse_format_list): Set flag used to determine of format data hashing
is to be used.  Internal units are not persistent enough for this.
(revert): Move to ne location in file.
(parse_format): Use new functions to look for previously parsed
format strings and use them rather than re-parse.  If not found, saves
the parsed format data for later use.

2009-04-05  Jerry DeLisle  

PR libfortran/37754
* io/transfer.c (formatted_transfer_scalar): Remove this function by
factoring it into two new functions, one for read and one for write,
eliminating all the conditionals for read or write mode.
(formatted transfer_scalar_read): New function.
(formatted transfer_scalar_write): New function.
(formatted_transfer): Use new functions.

2009-04-05  Janne Blomqvist  

PR libfortran/25561 libfortran/37754
* io/io.h (struct stream): Define new stream interface function
pointers, and inline functions for accessing it.
(struct fbuf): Use int instead of size_t, remove flushed element.
(mem_alloc_w): New prototype.
(mem_alloc_r): New prototype.
(stream_at_bof): Remove prototype.
(stream_at_eof): Remove prototype.
(file_position): Remove prototype.
(flush): Remove prototype.
(stream_offset): Remove prototype.
(unit_truncate): New prototype.
(read_block_form): Change to return pointer, int* argument.
(hit_eof): New prototype.
(fbuf_init): Change prototype.
(fbuf_reset): Change prototype.
(fbuf_alloc): Change prototype.
(fbuf_flush): Change prototype.
(fbuf_seek): Change prototype.
(fbuf_read): New prototype.
(fbuf_getc_refill): New prototype.
(fbuf_getc): New inline function.
* io/fbuf.c (fbuf_init): Use int, get rid of flushed.
(fbuf_debug): New function.
(fbuf_reset): Flush, and return position offset.
(fbuf_alloc): Simplify, don't flush, just realloc.
(fbuf_flush): Make usable for read mode, salvage remaining bytes.
(fbuf_seek): New whence argument.
(fbuf_read): New function.
(fbuf_getc_refill): New function.
* io/file_pos.c (formatted_backspace): Use new stream interface.
(unformatted_backspace): Likewise.
(st_backspace): Make sure format buffer is reset, use new stream
interface, use unit_truncate.
(st_endfile): Likewise.
(st_rewind): Likewise.
* io/intrinsics.c: Use new stream interface.
* io/list_read.c (push_char): Don't use u.p.scratch, use realloc
to resize.
(free_saved): Don't check u.p.scratch.
(next_char): Use new stream interface, use fbuf_getc() for external
files.
(finish_list_read): flush format buffer.
(nml_query): Update to use modified interface:s
* io/open.c (test_endfile): Use new stream interface.
(edit_modes): Likewise.
(new_unit): Likewise, set bytes_left to 1 for stream files.
* io/read.c (read_l): Use new read_block_form interface.
(read_utf8): Likewise

[Bug fortran/36874] Add shape checks to cshift/eoshift

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2009-04-05 20:10 ---
Subject: Bug 36874

Author: dfranke
Date: Sun Apr  5 20:09:58 2009
New Revision: 145570

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145570
Log:
gcc/fortran/:
2009-04-05  Daniel Franke  

PR fortran/36874
* check.c (gfc_check_cshift): Added missing shape-conformance checks.
(gfc_check_eoshift): Likewise.


gcc/testsuite/:
2009-04-05  Daniel Franke  

PR fortran/36874
* gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error
message.
* gfortran.dg/zero_sized_1.f90: Removed checks with incompatible
shapes.
* gfortran.dg/zero_sized_5.f90: Likewise.



Modified:
branches/fortran-dev/gcc/fortran/ChangeLog.dev
branches/fortran-dev/gcc/fortran/check.c
branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev
   
branches/fortran-dev/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/zero_sized_1.f90
branches/fortran-dev/gcc/testsuite/gfortran.dg/zero_sized_5.f90


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[rob1weld at aol dot com]

--- Comment #15 from rob1weld at aol dot com  2009-04-05 20:10 ---
(In reply to comment #9)
> > Using the BSD Ports I was able to build Ada, up until revision < 145338 .
> > While I do not use Ada it would be unfortunate to lose this Language.
> 
> This language is not supported in the FSF tree on OpenBSD, i.e. there is no
> appropriate system-*.ads file in the ada/ sub-directory.
> 

Version: 3.3.6, Package name: gcc-3.3.6
Maintained by: Marc Espie es...@openbsd.org
http://openports.se/lang/gcc/3.3


Is this what we need ?

[PATCH] ada: Add support for OpenBSD
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00079.html

Rob


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[rob1weld at aol dot com]

--- Comment #14 from rob1weld at aol dot com  2009-04-05 20:03 ---
(In reply to comment #10)
> I think this should be kept open as an enhancement request, if we have a
> willing tester on openbsd I'll try to help.

I'll do my best to help but I know that there are numerous people who are
more qualified than me (knows Ada, the middle-end, etc.) _and_ who have
an long term interest in keeping this alive (someone from Adacore /OpenBSD).

If you want me to test Patches, fire away,
Rob


-- 

rob1weld at aol dot com changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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

[Bug testsuite/39655] New: autogen "fixinclude test FAILURES" - trunk revision 145337

[rob1weld at aol dot com]

There are a few failures in autogen's fixinclude tests for 
gcc version 4.5.0 20090331, trunk revision 145337. One file
says "fixinc check FAILS ON BSD" the others are silent:


# gmake -i -k check 
gmake[1]: Entering directory `/usr/gcc_build'
gmake[2]: Entering directory `/usr/gcc_build/fixincludes'
autogen -T /home/user/gcc_trunk/fixincludes/check.tpl
/home/user/gcc_trunk/fixincludes/inclhack.def
/bin/sh ./check.sh /home/user/gcc_trunk/fixincludes/tests/base
Fixed:  testing.h
Fixed:  testing.h
Fixed:  AvailabilityMacros.h
Fixed:  X11/ShellP.h
...
Fixed:  unistd.h
Fixed:  wchar.h
Xm/Traversal.h /home/user/gcc_trunk/fixincludes/tests/base/Xm/Traversal.h
differ: char 296, line 15
*** Xm/Traversal.h  Sun Apr  5 12:20:08 2009
--- /home/user/gcc_trunk/fixincludes/tests/base/Xm/Traversal.h  Thu Apr  2
10:08:06 2009
***
*** 12,18 
  #if defined( X11_NEW_CHECK )
  struct wedge {
  #ifdef __cplusplus
! Widgetold, c_new;
  #else
 Widget old, new; /* fixinc check FAILS ON BSD */
  #endif
--- 12,18 
  #if defined( X11_NEW_CHECK )
  struct wedge {
  #ifdef __cplusplus
!   Widget  old, c_new;
  #else
 Widget old, new; /* fixinc check FAILS ON BSD */
  #endif
pthread.h /home/user/gcc_trunk/fixincludes/tests/base/pthread.h differ: char
2234, line 60
*** pthread.h   Sun Apr  5 12:20:09 2009
--- /home/user/gcc_trunk/fixincludes/tests/base/pthread.h   Sat Apr  4
21:03:36 2009
***
*** 57,82 

  #if defined( GLIBC_MUTEX_INIT_CHECK )
  #define PTHREAD_MUTEX_INITIALIZER \
!   { { 0, } }
  #ifdef __USE_GNU
  # if __WORDSIZE == 64
  #  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP } }
  #  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP } }
  #  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP } }
  # else
  #  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP } }
  #  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP } }
  #  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP } }
  # endif
  #endif
! # define PTHREAD_RWLOCK_INITIALIZER \
!   { { 0, } }
  # ifdef __USE_GNU
  #  if __WORDSIZE == 64
  #   define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
--- 57,87 

  #if defined( GLIBC_MUTEX_INIT_CHECK )
  #define PTHREAD_MUTEX_INITIALIZER \
!   { { 0, 0, 0, 0, 0, 0 } }
  #ifdef __USE_GNU
  # if __WORDSIZE == 64
  #  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0 } }
  #  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0 } }
  #  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0 } }
  # else
  #  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0, 0 } }
  #  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0, 0 } }
  #  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
!   { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0, 0 } }
  # endif
  #endif
! # if __WORDSIZE == 64
! #  define PTHREAD_RWLOCK_INITIALIZER \
!   { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } }
! # else
! #  define PTHREAD_RWLOCK_INITIALIZER \
!   { { 0, 0, 0, 0, 0, 0, 0, 0 } }
! # endif
  # ifdef __USE_GNU
  #  if __WORDSIZE == 64
  #   define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
***
*** 87,93 
{ { 0, 0, 0, 0, 0, 0, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP, 0 } }
  #  endif
  # endif
! #define PTHREAD_COND_INITIALIZER { { 0, } }
  #endif  /* GLIBC_MUTEX_INIT_CHECK */


--- 92,98 
{ { 0, 0, 0, 0, 0, 0, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP, 0 } }
  #  endif
  # endif
! #define PTHREAD_COND_INITIALIZER { { 0, 0, 0, 0, 0, (void *) 0, 0, 0 } }
  #endif  /* GLIBC_MUTEX_INIT_CHECK */


sys/stat.h /home/user/gcc_trunk/fixincludes/tests/base/sys/stat.h differ: char
432, line 18
*** sys/stat.h  Sun Apr  5 12:20:10 2009
--- /home/user/gcc_trunk/fixincludes/tests/base/sys/stat.h  Thu Apr  2
10:08:11 2009
***
*** 15,21 


  #if defined( GLIBC_C99_INLINE_2_CHECK )
! extern int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull ((2));
  #ifdef __GNUC_GNU_INLINE__
  extern
  #endif
--- 15,24 


  #if defined( GLIBC_C99_INLINE_2_CHECK )
! #ifdef __GNUC_GNU_INLINE__
! extern
! #endif
! __inline__ int fstat64 (int __fd, struct stat64 *__buf) __THROW __nonnull
((2));
  #ifdef __GNUC_GNU_INLINE__
  extern
  #endif

There were fixinclude test FAILURES
gmake[2]: [check] Error 1 (ignored)
gmake[2]: Leaving directory `/usr/gcc_build/fixincludes'
gmake[2]: Entering directory `/usr/gcc_build/gcc'
Making a new config file...
echo "set tmpdir /usr/gcc_build/gcc/testsuite" >> ./tmp0
...

Thanks,
Rob


-- 
   Summary: autogen "fixinclude t

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-04-05 19:52 ---
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=39648

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-04-05 19:50 ---
Subject: Bug 39648

Author: rguenth
Date: Sun Apr  5 19:50:28 2009
New Revision: 145569

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145569
Log:
2009-04-05  Richard Guenther  

PR tree-optimization/39648
* tree-ssa-sccvn.c (vn_reference_fold_indirect): Work around
our &A vs. &A[0] IL deficiencies.

* gcc.c-torture/compile/pr39648.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr39648.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-sccvn.c


-- 


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

[Bug fortran/38822] Compile-time simplification of x**(real)

[dominiq at lps dot ens dot fr]

--- Comment #15 from dominiq at lps dot ens dot fr  2009-04-05 19:43 ---
> There are 2 URL's in comment #2.

Sorry to be dense, but I overlooked the differences:

< f = initialization(x-1)--> gives "T F"
---
> f = non_initialization(x-1)--> gives "T T" 

I get the same answers for gfortran, ifort, and g95. If someone has access to
other compilers and can run the test, let see!


-- 


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

[Bug c++/39653] error referencing a more specialized variadic template from primary

[jason at gcc dot gnu dot org]

--- Comment #1 from jason at gcc dot gnu dot org  2009-04-05 19:35 ---
I'd write that as

template 
struct S;

template 
struct S {
typedef typename S::type type;
};

template 
struct S { typedef T type; };


-- 


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[jason at gcc dot gnu dot org]

--- Comment #7 from jason at gcc dot gnu dot org  2009-04-05 19:33 ---
*** Bug 39642 has been marked as a duplicate of this bug. ***


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||piotr dot wyderski at gmail
   ||dot com


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

[Bug c++/39642] [C++0x] Unimplemented variadic template type expansion

[jason at gcc dot gnu dot org]

--- Comment #2 from jason at gcc dot gnu dot org  2009-04-05 19:33 ---


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


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/14912] Do not print default template arguments in error messages

[jason at gcc dot gnu dot org]

--- Comment #50 from jason at gcc dot gnu dot org  2009-04-05 19:29 ---
Subject: Bug 14912

Author: jason
Date: Sun Apr  5 19:29:02 2009
New Revision: 145566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145566
Log:
PR c++/14912
* error.c (count_non_default_template_args): New fn.
(dump_template_parms): Call it.
(dump_template_argument_list): Call it.  Add parms parm.
(dump_template_argument): Adjust call to dump_template_argument_list.
(dump_type, dump_decl): Likewise.
(dump_template_bindings): Refactor logic.

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


-- 


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

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2009-04-05 19:01 ---
This is likely the same issue that causes the sparc -linux bootstrap fail:

http://gcc.gnu.org/ml/gcc/2009-04/msg00164.html

This will save me a reduction :).

Note: I also see the same ICE during bootstrap on i686-mingw32.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[laurent at guerby dot net]

--- Comment #13 from laurent at guerby dot net  2009-04-05 18:46 ---
Is there a supported platform currently using FE SJLJ?


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2009-04-05 18:26 
---
> As for the backend issue, may be it will show up on i386-unknown-freebsd too 
> (a
> primary platform), and there's a gcc/ada/system-freebsd-x86.ads in the FSF
> tree.

Most probably not, you need FE SJLJ exceptions.


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[laurent at guerby dot net]

--- Comment #11 from laurent at guerby dot net  2009-04-05 18:18 ---
For reference, NetBSD Ada support patch was also posted recently:

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


-- 


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

[Bug ada/37309] tasking is not implemented on NetBSD

[laurent at guerby dot net]

--- Comment #10 from laurent at guerby dot net  2009-04-05 18:17 ---
Patch URL:

http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01510.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||03/msg01510.html


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[laurent at guerby dot net]

--- Comment #10 from laurent at guerby dot net  2009-04-05 18:12 ---
I think this should be kept open as an enhancement request, if we have a
willing tester on openbsd I'll try to help.

As for the backend issue, may be it will show up on i386-unknown-freebsd too (a
primary platform), and there's a gcc/ada/system-freebsd-x86.ads in the FSF
tree.


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
   Severity|major   |enhancement


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

[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one

[rguenther at suse dot de]

--- Comment #1 from rguenther at suse dot de  2009-04-05 18:07 ---
Subject: Re:   New: [4.5 Regression]: cris-elf
 gcc.dg/torture/builtin-math-3.c  -O1 and -Os sincos one

On Sat, 4 Apr 2009, hp at gcc dot gnu dot org wrote:

> With revision 145488 this test passed.
> From revision 145495 and on, this test has failed as follows:
> ...
> Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/dg-torture.exp
> ...
> FAIL: gcc.dg/torture/builtin-math-3.c  -O1  (test for excess errors)
> FAIL: gcc.dg/torture/builtin-math-3.c  -Os  (test for excess errors)
> ...
> 
> With the message in gcc.log being:
> builtin-math-3.c:(.text+0x88): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0xfe): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0x174): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0x1aa): undefined reference to `_link_error'
> builtin-math-3.c:(.text+0x220): undefined reference to `_link_error'
> /tmp/ccKBGOIU.o:builtin-math-3.c:(.text+0x296): more undefined references to
> `_link_error' follow
> 
> The lack of line-numbers is of course unhelpful, but with "-g" added, the link
> error becomes, for both -O1 and -Os:
> 
> builtin-math-3.o: In function `main':
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:176:
> undefined reference to `_link_error'
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:176:
> undefined reference to `_link_error'
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:177:
> undefined reference to `_link_error'
> /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/torture/builtin-math-3.c:177:
> undefined reference to `_link_error'
> 
> Author of patches in suspect revision range CC:ed.

Can you 1) reduce the testcase and attach preprocessed source that
works with a cross-compiler, 2) identify what goes wrong so we don't
have to analyze cris assembler?

Thanks,
Richard.


-- 


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

[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter

[dfranke at gcc dot gnu dot org]

--- Comment #13 from dfranke at gcc dot gnu dot org  2009-04-05 18:04 
---
Fixed in trunk. Backport unlikely as it's not a regression. Closing.


-- 

dfranke 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=29458

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-04-05 18:04 ---
Thanks to the reduced testcase I have a patch.  It's our usual &array vs.
&array[0] problem.


-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-05 18:04:13
   date||


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

[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter

[dfranke at gcc dot gnu dot org]

--- Comment #12 from dfranke at gcc dot gnu dot org  2009-04-05 18:02 
---
Subject: Bug 29458

Author: dfranke
Date: Sun Apr  5 18:02:00 2009
New Revision: 145564

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145564
Log:
gcc/fortran/:
2009-04-05  Daniel Franke  

PR fortran/29458
* trans-array.c (gfc_trans_array_constructor_value): Shadow implied
do-loop variable to avoid spurious middle-end warnings.


gcc/testsuite/:
2009-04-05  Daniel Franke  

PR fortran/29458
* gfortran.dg/implied_do_1.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2009-04-05 17:58 ---
> I only recently committed a fix to the dev-branch (#3).

Now I understand my mistake: pr30814 was fixed for runtime if compiled with
-fbounds-check. The patch in fortran-dev gives the error at compile time (much
better when possible!-).

> Not sure about backports, though.

Why not?


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[ebotcazou at gcc dot gnu dot org]

--- Comment #9 from ebotcazou at gcc dot gnu dot org  2009-04-05 17:55 
---
> Using the BSD Ports I was able to build Ada, up until revision < 145338 .
> While I do not use Ada it would be unfortunate to lose this Language.

This language is not supported in the FSF tree on OpenBSD, i.e. there is no
appropriate system-*.ads file in the ada/ sub-directory.


-- 


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

[Bug middle-end/39650] [4.5 regression] Revision 145533 breaks SPEC CPU 2K/2006

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-04-05 17:48 ---
Preprocessed source???


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[steven at gcc dot gnu dot org]

--- Comment #8 from steven at gcc dot gnu dot org  2009-04-05 17:40 ---
Bug is not in an FSF-GCC supported port.
Does the problem reproduce on supported targets?  Otherwise this bug should be
closed as "INVALID".


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK

[dfranke at gcc dot gnu dot org]

--- Comment #5 from dfranke at gcc dot gnu dot org  2009-04-05 17:38 ---
I only recently committed a fix to the dev-branch (#3). I'll merge this fix
together with all the other check and simplification changes to trunk when they
are complete. Not sure about backports, though.


-- 


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

[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada

[rob1weld at aol dot com]

--- Comment #7 from rob1weld at aol dot com  2009-04-05 17:31 ---
I can build gcc with the Ada Language using Trunk revision 145337
but the changes made in the next revision cause the build to fail.


The Changelog indicates Richard Guenther made the changes on 2009-03-31.
There were no changes made to Ada, only to the middle-end (AFAIK).

# ./contrib/gcc_update -r 145338
Updating SVN tree
Ugcc/java/java-gimplify.c
Ugcc/java/ChangeLog
Ugcc/tree.h
Ugcc/ChangeLog
Agcc/testsuite/gcc.dg/tree-ssa/pr23401.c
Agcc/testsuite/gcc.dg/tree-ssa/pr27810.c
Ugcc/testsuite/ChangeLog
Ugcc/tree-eh.c
Ugcc/gimplify.c
Ugcc/tree-ssa-pre.c
Ugcc/tree-mudflap.c
Ugcc/gimple.c
Ugcc/gimple.h
Ugcc/tree-cfg.c
Updated to revision 145338.


I do not know the middle-end well enough to tamper with it. 

I would appreciate if the remainder of this work could be undertaken 
by someone else. I do not think that this is entirely Operating System 
specific, others may be affected too.


# 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 20090331 (experimental) [trunk revision 145338] (GCC)


../../xgcc -B../../ -c -g -O2   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes  -gnatpg -gnata -I- -I../rts -I.
-I/home/user/gcc_trunk/gcc/ada /home/user/gcc_trunk/gcc/ada/prj-part.adb -o
prj-part.o
/home/user/gcc_trunk/gcc/ada/prj-part.adb: In function
'Prj.Part.Parse_Single_Project':
/home/user/gcc_trunk/gcc/ada/prj-part.adb:159: warning: 'Project' may be used
uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:159: note: 'Project' was declared
here
/home/user/gcc_trunk/gcc/ada/prj-part.adb:160: warning: 'Extends_All' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:160: note: 'Extends_All' was declared
here
/home/user/gcc_trunk/gcc/ada/prj-part.adb:952: warning: 'Canonical_Path_Name'
may be used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:953: warning: 'Project_Directory' may
be used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:957: warning: 'Extending' may be used
uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:959: warning: 'Extended_Project' may
be used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:965: warning: 'Name_From_Path' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:966: warning: 'Name_Of_Project' may
be used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:968: warning: 'Duplicated' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:970: warning: 'First_With' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:971: warning: 'Imported_Projects' may
be used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:977: warning: 'Proj_Qualifier' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:978: warning: 'Qualifier_Location'
may be used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:939: warning: '' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:939: warning: '' may be
used uninitialized in this function
/home/user/gcc_trunk/gcc/ada/prj-part.adb:961: warning:
'a_project_name_and_node.node' may be used uninitialized in this function

Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.
first_with_96(ab) and  first_with_455(ab)
+===GNAT BUG DETECTED==+
| 4.5.0 20090331 (experimental) [trunk revision 145338]
(i386-unknown-openbsd4.5) GCC error:|
| SSA corruption   |
| Error detected around /home/user/gcc_trunk/gcc/ada/prj-part.adb:939  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Pleas

[Bug fortran/39654] New: ABI bug: FTELL intrinsic function not capable of large files

[jb at gcc dot gnu dot org]

The FTELL function in libgfortran/io/intrinsics.c has the prototype

extern size_t PREFIX(ftell) (int *);

where the return value is the file position of the unit given in the int
argument. On 32-bit platforms this will not work for files > 4 GB. The return
type should be GFC_IO_INT which is a typedef for off_t which is 64-bit on LFS
capable systems.


-- 
   Summary: ABI bug: FTELL intrinsic function not capable of large
files
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[sebor at roguewave dot com]

--- Comment #6 from sebor at roguewave dot com  2009-04-05 17:12 ---
See also bug 39642 and bug 39653.


-- 


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

[Bug c++/39653] New: error referencing a more specialized variadic template from primary

[sebor at roguewave dot com]

I believe the following program is well-formed but gcc rejects it with
the same error as the one discussed in bug 35722. I'm opening this as
a separate bug since unlike in bug 35722, the referenced template is
variadic.

$ cat t.C && g++ --version && g++ -std=c++0x t.C
template 
struct S {
typedef typename S::type type;
};

template 
struct S { typedef T type; };
g++ (GCC) 4.5.0 20090404 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

t.C:3: sorry, unimplemented: cannot expand ‘Types ...’ into a fixed-length
argument list


-- 
   Summary: error referencing a more specialized variadic template
from primary
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com


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

[Bug libstdc++/39652] Trouble with new random bits

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-04-05 17:10 
---
See PR39644. I (think I have) just fixed the issues related to log2*, please
check if that's enough for you.


-- 


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

[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2009-04-05 17:08 ---
There is something weird here. This pr looks to be a duplicate of pr30814,
which is supposed to be fixed since 2007-07-24 (r126866) or 2007-07-29
(r127049: two commits to trunk if I am not mistaken).

The problem seems to be fixed in fortran-dev branch, but not in trunk (4.5
r145530). Could someone check what's going on? If I did not make any mistake,
could the patch be commited on trunk and backported to the 4.* version in which
it is missing (4.4, 4.3, it is also missing in 4.2, but it is closed)?


-- 


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

[Bug ada/39625] Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.

[rob1weld at aol dot com]

--- Comment #6 from rob1weld at aol dot com  2009-04-05 17:08 ---
(In reply to comment #3)
> The Ada compiler hasn't been ported to OpenBSD yet.

While "we" may not have ported Ada, the OpenBSD Group has it in Ports.

# pkg_add gnat-3.3.6p9
# 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

Using the BSD Ports I was able to build Ada, up until revision < 145338 .
While I do not use Ada it would be unfortunate to lose this Language.


The revision causing the build to fail has no updates to Ada, only
in the middle-end. I am going to change the Component accordingly
and revise the "Subject" to correctly reflect the issues.

Thanks for your input Eric,
Rob


-- 


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

[Bug libstdc++/39652] New: Trouble with new random bits

[danglin at gcc dot gnu dot org]

Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp
-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include
-i
system /opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/sys-include -g -O2
-D_GLIBCX
X_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2   
-DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++
-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libst
dc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/l
ibstdc++-v3/include/backward -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util
/te
st/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/c++200x/all.cc  
-std=gnu
++0x -S  -o all.s(timeout = 600)
In file included from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/incl
ude/random:58,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/
c++200x/all.cc:122:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n member function 'void std::linear_congruential_engine<_UIntType, __a, __c,
__m
>::seed(std::seed_seq&)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:12
1: error: 'log2' is not a member of 'std'
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n member function 'result_type
std::independent_bits_engine<_RandomNumberEngine,
 __w, _UIntType>::operator()()':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:58
1: error: 'log2l' is not a member of 'std'
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n member function 'result_type
std::piecewise_linear_distribution<_RealType>::op
erator()(_UniformRandomNumberGenerator&, const
std::piecewise_linear_distributio
n<_RealType>::param_type&)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:25
96: error: expected ',' or ';' before ')' token
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n function '_RealType std::generate_canonical(_UniformRandomNumberGenerator&)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:27
65: error: 'log2l' is not a member of 'std'
compiler exited with status 1
output is:
In file included from
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/incl
ude/random:58,
 from
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/headers/
c++200x/all.cc:122:
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n member function 'void std::linear_congruential_engine<_UIntType, __a, __c,
__m
>::seed(std::seed_seq&)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:12
1: error: 'log2' is not a member of 'std'
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n member function 'result_type
std::independent_bits_engine<_RandomNumberEngine,
 __w, _UIntType>::operator()()':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:58
1: error: 'log2l' is not a member of 'std'
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n member function 'result_type
std::piecewise_linear_distribution<_RealType>::op
erator()(_UniformRandomNumberGenerator&, const
std::piecewise_linear_distributio
n<_RealType>::param_type&)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:25
96: error: expected ',' or ';' before ')' token
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:
I
n function '_RealType std::generate_canonical(_UniformRandomNumberGenerator&)':
/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/bits/random.tcc:27
65: error: 'log2l' is not a member of 'std'

FAIL: 17_intro/headers/c++200x/all.cc (test for excess errors)
...
Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/test/gnu/gcc
/objdir/./gcc -nostdinc++
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v
3/src -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-B/opt/g
nu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.5.0/hppa64-hp
-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/include
-i
system /opt/gnu64/gcc/gcc-4.5.0/hppa64-hp-hpux11.11/sys-include -g -O2
-D_GLIBCX
X_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2   
-DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++
-v3/include/hppa64-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libst
dc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/l
ibstdc++-v3/include/backward -I/test/gnu/gc

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2009-04-05 16:59 
---
Please, let me know how it goes as far as the fails related to log2* are
concerned. For the other fails, stdint.h related, see my previous message in
the trail.


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo at gcc dot gnu dot org]

--- Comment #6 from paolo at gcc dot gnu dot org  2009-04-05 16:56 ---
Subject: Bug 39644

Author: paolo
Date: Sun Apr  5 16:56:16 2009
New Revision: 145563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145563
Log:
2009-04-05  Paolo Carlini  

PR libstdc++/39644 (partial)
* include/bits/random.tcc (linear_congruential_engine<>::
seed(seed_seq&), independent_bits_engine<>::operator(),
generate_canonical(_UniformRandomNumberGenerator&)): Avoid log2l.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.tcc


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2009-04-05 16:49 
---
(In reply to comment #4)
> > In any case, eventually, when 448 will be closed, *all* the
> > configure time tests in this area, and testing infrastructure, etc., will be
> > simply removed, the possibility to include  will be assumed
> > unconditionally.
> 
> Naturally.  Not sure about your point: I just reported observations I thought
> would be relevant.  What fails must be fixed.

Of course. My point is that if 448 is fixed soon, we can just remove all those
crazy configury bits, assume stdint.h is available unconditionally, and this PR
will be fixed automagically, as part of a library clean-up essentially.


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2009-04-05 16:46 ---
(In reply to comment #3)
> > (hm, you mean it doesn't work and that's the reason for those FAILs?)
> 
> Hum. Two separate comments: 1- The issue with those fails is only *partially*
> due to stdint.h, as you can see from the log2l related fails,

Of course.  By "those fails" instead of "all fails" I referred to those fails
(oops again :) only.  I guess depending on language that's an ambiguous phrase,
so let's use the longer "that subset of the FAILs".

> which have
> nothing to do with stdint.h, of course, and must be fixed anyway;

> 2- As regards
> stdint.h, if you can confirm that cris-elf is already ok for 448 (in practice
> that means that gcc installs a fully usable and conforming stdint.h, along 
> with
> float.h, and so on, in the */lib/gcc/*/4.5.0/include subdir),

It's not *installed* at the time the test-suite run, but from the brief look I
had, I saw nothing wrong with jsm28's stdint stuff.  For example, the C
test-cases jsm28 added all pass, so I see no apparent failure.  But see below.

> then it's
> probably libstdc++ fault, in that is currently carrying out configure-time
> tests for your target which actually spoil that work. I'm not sure. I'd like 
> to
> know more from you.

I see the following in the testsuite logs (for r145559), which might be a clue:
...
cstdint17453.cc:2: error: expected initializer at end of input
compiler exited with status 1
output is:
cstdint17453.cc:2: error: expected initializer at end of input

UNSUPPORTED: 18_support/headers/cstdint/types_std_c++0x.cc

so (wild speculation) if that dg- support test is wrong, it can explain why the
test-suite filters out all test-cases now "redundantly" gated by
dg-require-cstdint.

> In any case, eventually, when 448 will be closed, *all* the
> configure time tests in this area, and testing infrastructure, etc., will be
> simply removed, the possibility to include  will be assumed
> unconditionally.

Naturally.  Not sure about your point: I just reported observations I thought
would be relevant.  What fails must be fixed.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-05 16:46:18
   date||


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

[Bug middle-end/39651] New: New cleanup test failures

[danglin at gcc dot gnu dot org]

FAIL: gcc.dg/cleanup-10.c execution test
FAIL: gcc.dg/cleanup-11.c execution test
FAIL: gcc.dg/cleanup-8.c execution test
FAIL: gcc.dg/cleanup-9.c execution test

FAIL: g++.dg/ext/cleanup-10.C execution test
FAIL: g++.dg/ext/cleanup-11.C execution test
FAIL: g++.dg/ext/cleanup-8.C execution test
FAIL: g++.dg/ext/cleanup-9.C execution test

These fails were introduced between revision 145151 and revision 145211.


-- 
   Summary: New cleanup test failures
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-04-05 16:08 ---
I think this is the same as PR 39650.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/39650] [4.5 regression] Revision 145533 breaks SPEC CPU 2K/2006

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-04-05 15:51 ---
Revision 145533:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00155.html

is the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||rguenther at suse dot de
Summary|[4.5 regression] Many   |[4.5 regression] Revision
   |benchmarks in SPEC CPU 2K   |145533 breaks SPEC CPU
   |failed to compile   |2K/2006


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

[Bug c/39648] internal compiler error: in fold_convert, at fold-const.c:2506

[marcus at jet dot franken dot de]

--- Comment #1 from marcus at jet dot franken dot de  2009-04-05 15:29 
---
Created an attachment (id=17590)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17590&action=view)
xx.i reduced testcase

wine also fails, reduced testcase... 


-- 


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

[Bug c/39641] Compiling Linux 2.6.28.6 ends with a segfault on net/core/skbuff.c

[lasse-gccbug-2009 at mail dot plastictree dot net]

--- Comment #3 from lasse-gccbug-2009 at mail dot plastictree dot net  
2009-04-05 15:19 ---
Segfault does not occur when omitting '-ffreestanding'.

Segfault does not occur when using '-save-temps'.

When I add '-save-temps' to 'arch/x86/Makefile' in the same location in which
'-ffreestanding' occurs, 'make' runs through. I have not tested whether the
resulting kernel works.

Moreover, in that Makefile, it reads:

# temporary until string.h is fixed
KBUILD_CFLAGS += -ffreestanding

So, it appears that '-ffreestanding' is itself a workaround for something.

Another approach: obtain 'skbuff.i' via '-save-temps' and then copy it to
'net/core/skbuff.c'. Then 'make' will also run through.


-- 


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

[Bug middle-end/39650] [4.5 regression] Many benchmarks in SPEC CPU 2K failed to compile

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-04-05 15:04 ---
All errors look like:

util.c:133: internal compiler error: in create_tmp_var, at gimplify.c:553
real.c:1075: internal compiler error: in fold_convert, at fold-const.c:2506
regclass.c:1008: internal compiler error: in create_tmp_var, at gimplify.c:553
toke.c:1477: internal compiler error: in fold_convert, at fold-const.c:2506
system.c:3542: internal compiler error: in fold_convert, at fold-const.c:2506
utf8.c:1645: internal compiler error: in fold_convert, at fold-const.c:2506
real.c:1328: internal compiler error: in fold_convert, at fold-const.c:2506
engine/fuseki.c:160: internal compiler error: in fold_convert, at
fold-const.c:2506


-- 


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

[Bug middle-end/39650] [4.5 regression] Many benchmarks in SPEC CPU 2K failed to compile

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-04-05 14:54 ---
It also failed to compile

1x400.perlbench 1x403.gcc 1x435.gromacs 1x445.gobmk 1x456.hmmer

in SPEC CPU 2006.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/39650] New: [4.5 regression] Many benchmarks in SPEC CPU 2K failed to compile

[hjl dot tools at gmail dot com]

Revision 145536 failed to compile

Error: 1x164.gzip 1x176.gcc 1x253.perlbmk 1x254.gap

in SPEC CPU 2K on Linux/ia32 and Linux/x86-64.


-- 
   Summary: [4.5 regression] Many benchmarks in SPEC CPU 2K failed
to compile
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template

[sebor at roguewave dot com]

--- Comment #5 from sebor at roguewave dot com  2009-04-05 14:20 ---
(In reply to comment #4)

The change was introduced in N2622:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2622.pdf

I couldn't find a rationale for the change. Doug might remember


-- 


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

[Bug c++/39649] New: libstdc++-v3/src/functexcept.cc:65 internal compiler error: verify_eh_tree failed in stage3

[henrik30000 at gmail dot com]

The full error message is:
../../../../libstdc++-v3/src/functexcept.cc: In function ‘void
std::__throw_logic_error(const char*)’:
../../../../libstdc++-v3/src/functexcept.cc:65: error: region 6 may contain
throw and is contained in region that may not
Eh tree:
   8 must_not_throw also known as:4, 5
 6 allowed_exceptions tree_label:filter :0 types:
   1 cleanup tree_label:
 7 allowed_exceptions tree_label:filter :0 types:
 2 cleanup tree_label:
   3 cleanup tree_label:
../../../../libstdc++-v3/src/functexcept.cc:65: internal compiler error:
verify_eh_tree failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Using svn revision 145559 of gcc on Fedora 8
x86_64 AMD Phenom 9850 CPU
gcc configured with ../configure
--prefix=/home/rakhun/systembuilder/GNU-Linux/usr
--with-gmp=/home/rakhun/systembuilder/GNU-Linux/usr
--with-mpfr=/home/rakhun/systembuilder/GNU-Linux/usr --enable-languages=c,c++
--disable-werror
and compile initiated with 'make'

Log of make output: http://ei87.org/~rakhun/gccerrors.log
functexcept.ii: http://ei87.org/~rakhun/functexcept.ii (not sure if it is
relevant or not)


-- 
   Summary: libstdc++-v3/src/functexcept.cc:65 internal compiler
error: verify_eh_tree failed in stage3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: henrik3 at gmail 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=39649

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-04-05 13:48 
---
(In reply to comment #2)
> The cris-elf target uses standard newlib-stdint.h, nothing special about that.
> (hm, you mean it doesn't work and that's the reason for those FAILs?)

Hum. Two separate comments: 1- The issue with those fails is only *partially*
due to stdint.h, as you can see from the log2l related fails, which have
nothing to do with stdint.h, of course, and must be fixed anyway; 2- As regards
stdint.h, if you can confirm that cris-elf is already ok for 448 (in practice
that means that gcc installs a fully usable and conforming stdint.h, along with
float.h, and so on, in the */lib/gcc/*/4.5.0/include subdir), then it's
probably libstdc++ fault, in that is currently carrying out configure-time
tests for your target which actually spoil that work. I'm not sure. I'd like to
know more from you. In any case, eventually, when 448 will be closed, *all* the
configure time tests in this area, and testing infrastructure, etc., will be
simply removed, the possibility to include  will be assumed
unconditionally.


-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2009-04-05 13:36 ---
(In reply to comment #1)
> Anyway, just wanted to ask if the stdint.h support (the appropriate bits to
> close PR 448) is forthcoming for this OS:

The cris-elf target uses standard newlib-stdint.h, nothing special about that.
(hm, you mean it doesn't work and that's the reason for those FAILs?)


-- 


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

[Bug c/39648] New: internal compiler error: in fold_convert, at fold-const.c:2506

[happyarch at gmail dot com]

Hi, i have problem when compiling vim-7.2 in LFS64

TIA
==

bash-4.0$ cc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap
--disable-multilib
Thread model: posix
gcc version 4.5.0 20090404 (experimental) (GCC)
bash-4.0$ pwd
/home/user/d/vim7.2
bash-4.0$ make
Starting make in the src directory.
If there are problems, cd to the src directory and run make there
cd src && make first
make[1]: Entering directory `/home/user/d/vim7.2/src'
gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -D_FORTIFY_SOURCE=1 -o
objects/buffer.o buffer.c
buffer.c: In function :
buffer.c:3347: internal compiler error: in fold_convert, at fold-const.c:2506
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [objects/buffer.o] Error 1
make[1]: Leaving directory `/home/user/d/vim7.2/src'
make: *** [first] Error 2
bash-4.0$ vi fold-const.c +2506

 gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
  && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));


-- 
   Summary: internal compiler error: in fold_convert, at fold-
const.c:2506
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: happyarch at gmail dot com
 GCC build triplet: x86_64
  GCC host triplet: x86_64
GCC target triplet: x86_64


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

[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter

[dfranke at gcc dot gnu dot org]

--- Comment #11 from dfranke at gcc dot gnu dot org  2009-04-05 13:20 
---
Patch:
  http://gcc.gnu.org/ml/fortran/2009-04/msg00035.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|2007-08-06 13:47:12 |2009-04-05 13:20:02
   date||


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

[Bug c/39647] New: Syntax checks in #line not quite right

[neil at gcc dot gnu dot org]

The following is strictly conforming but GCC rejects it.

extern int x;
#define EMPTY()
#line 2 "foo.c" EMPTY( )


-- 
   Summary: Syntax checks in #line not quite right
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug c/39646] New: __FILE__ breaks for empty file name

[neil at gcc dot gnu dot org]

GCC rejects the following strictly conforming TU with -pedantic-errors

extern int x;

#line 24 ""
extern char z[sizeof __FILE__ == 1];


-- 
   Summary: __FILE__ breaks for empty file name
   Product: gcc
   Version: 4.1.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org


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

[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[steven at gcc dot gnu dot org]

--- Comment #23 from steven at gcc dot gnu dot org  2009-04-05 12:38 ---
Could it be that this is now fixed by the a-i-b merge?


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug bootstrap/39645] genattrtab.c does not compile under sparc Linux

[laurent at guerby dot net]

--- Comment #1 from laurent at guerby dot net  2009-04-05 11:50 ---
Confirmed:

http://gcc.gnu.org/ml/gcc/2009-04/msg00167.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net
 AssignedTo|unassigned at gcc dot gnu   |laurent at guerby dot net
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|c   |bootstrap
 Ever Confirmed|0   |1
   Keywords||build
   Last reconfirmed|-00-00 00:00:00 |2009-04-05 11:50:58
   date||


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

[Bug c/39645] New: genattrtab.c does not compile under sparc Linux

[michael dot a dot richmond at nasa dot gov]

When I attempt to compile gcc 4.5 on a sparc machine under Debian Linux 5.0 I
get the following error:

/home/mrichmon/gcc-4.5-20090402/gcc/genattrtab.c: In function âattr_rtxâ:
/home/mrichmon/gcc-4.5-20090402/gcc/genattrtab.c:478: error: âva_arg_tmp.72â
may be used uninitialized in this function
/home/mrichmon/gcc-4.5-20090402/gcc/genattrtab.c:478: note: âva_arg_tmp.72â was
declared here
/home/mrichmon/gcc-4.5-20090402/gcc/genattrtab.c:506: error: âva_arg_tmp.75â
may be used uninitialized in this function
/home/mrichmon/gcc-4.5-20090402/gcc/genattrtab.c:506: note: âva_arg_tmp.75â was
declared here


-- 
   Summary: genattrtab.c does not compile under sparc Linux
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
 GCC build triplet: sparc-unknown-linux-gnu
  GCC host triplet: sparc-unknown-linux-gnu
GCC target triplet: sparc-unknown-linux-gnu


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

[Bug ada/39625] Unable to coalesce ssa_names 96 and 455 which are marked as MUST COALESCE.

[rob1weld at aol dot com]

--- Comment #5 from rob1weld at aol dot com  2009-04-05 09:46 ---
(In reply to comment #4)
> (In reply to comment #1)
> > ...
Broken:  145350
Working: 145300
Rob



-- 


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

[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-04-05 09:09 
---
I'm removing myself from CC because I'm not more responsible for these issues
than the other maintainers.

Anyway, just wanted to ask if the stdint.h support (the appropriate bits to
close PR 448) is forthcoming for this OS: as regards the stdint.h part of the
issues, I'd like to avoid adding the dg-require-cstdint dance to all the
testcases, etc, because all of that will go away when 448 will be closed.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC|paolo at gcc dot gnu dot org|


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

[Bug bootstrap/39610] ICE in libstdc++-v3/include in stage 3

[ktietz at gcc dot gnu dot org]

--- Comment #4 from ktietz at gcc dot gnu dot org  2009-04-05 08:39 ---
for mingw-w64 we have the same issue as cygwin.


-- 

ktietz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu dot
   ||org


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

[Bug target/39573] Linking fails on AMD with -march=native and -fopenmp, works with generic x86_64

[fpbeekhof at gmail dot com]

--- Comment #16 from fpbeekhof at gmail dot com  2009-04-05 08:16 ---

Ok, this was the original code that fails
// Prepare points of cube relative to point in matrix.
typename iPoint3D::value_type offset [8] [3] = {
{0, 0, 0}, {1, 0, 0}, {1, 0, 1}, {0, 0, 1},
{0, 1, 0}, {1, 1, 0}, {1, 1, 1}, {0, 1, 1} };

After adding "const", it is fine!
// Prepare points of cube relative to point in matrix.
const typename iPoint3D::value_type offset [8] [3] = {
{0, 0, 0}, {1, 0, 0}, {1, 0, 1}, {0, 0, 1},
{0, 1, 0}, {1, 1, 0}, {1, 1, 1}, {0, 1, 1} };


-- 


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