[Bug debug/39267] [4.4/4.5 Regression] gdb testsuite regressions
--- Comment #7 from jakub at gcc dot gnu dot org 2009-04-06 08:13 --- Closing then. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39267
[Bug fortran/39414] PROCEDURE statement double declaration bug
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-06 08:33 --- Subject: Bug 39414 Author: janus Date: Mon Apr 6 08:33:31 2009 New Revision: 145583 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145583 Log: 2009-04-06 Janus Weil ja...@gcc.gnu.org PR fortran/39414 * decl.c (match_procedure_decl): Fix double declaration problems with PROCEDURE statements. * symbol.c (gfc_add_type): Ditto. 2009-04-06 Janus Weil ja...@gcc.gnu.org PR fortran/39414 * gfortran.dg/proc_decl_21.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39414
[Bug fortran/39414] PROCEDURE statement double declaration bug
--- Comment #4 from janus at gcc dot gnu dot org 2009-04-06 08:36 --- Committed as r145583. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39414
[Bug bootstrap/39610] ICE in libstdc++-v3/include in stage 3
--- Comment #5 from rainer at emrich-ebersheim dot de 2009-04-06 08:53 --- This is a regression because it used to work for gcc-4.4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39610
[Bug bootstrap/39659] New: [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc
... /bin/sh ../libtool --tag CXX --mode=compile /home/ayers/gcc/trunk/build/./gcc/xgcc -shared-libgcc -B/home/ayers/gcc/trunk/build/./gcc -nostdinc++ -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include -I/home/ayers/gcc/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -D_GNU_SOURCE-std=gnu++0x -c ../../../../libstdc++-v3/src/functexcept.cc libtool: compile: /home/ayers/gcc/trunk/build/./gcc/xgcc -shared-libgcc -B/home/ayers/gcc/trunk/build/./gcc -nostdinc++ -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/home/ayers/gcc/trunk/build/i686-pc-linux-gnu/libstdc++-v3/include -I/home/ayers/gcc/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -D_GNU_SOURCE -std=gnu++0x -c ../../../../libstdc++-v3/src/functexcept.cc -fPIC -DPIC -o .libs/functexcept.o ../../../../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:L3filter :0 types: 1 cleanup tree_label:L9 7 allowed_exceptions tree_label:L7filter :0 types: 2 cleanup tree_label:L2 3 cleanup tree_label:L0 ../../../../libstdc++-v3/src/functexcept.cc:65: internal compiler error: verify_eh_tree failed configured with: ../configure --enable-languages=obj-c++ --enable-version-specific-runtime-libs --program-suffix=-trunk PS: I claimed ice-on-valid-code as I assume that libstdc++v3 contains valid code here even though that's not something can really confirm... there doesn't seem to be an unadorned ICE keyword. PPS: I still need to figure out how create the preprocessed source during bootstrap... and I'll try to figure out when this showed up. -- Summary: [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build, EH Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ayers at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug c++/39637] ICE on ill-formed sizeof(parameter-pack) in variadic template
--- Comment #1 from dodji at gcc dot gnu dot org 2009-04-06 08:50 --- Confirmed on gcc trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-06 08:50:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39637
[Bug bootstrap/39659] [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc
--- Comment #1 from ayers at gcc dot gnu dot org 2009-04-06 09:04 --- Possibly related: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39610 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug bootstrap/39659] [4.5][bootstrap] ICE building libstdc++v3 functexcept.cc
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-06 09:11 --- *** Bug 39649 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||henrik3 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-06 09:34 --- Thanks Hans-Peter. If you can analyze a bit more the stdint.h issues it would be great. In particular, I would like to know if on such targets stdint.h is available at C++ library configure time, the configure tests succeed and thus _GLIBCXX_USE_C99_STDINT_TR1 is defined. Then, there are two possibilities: if the tests pass, we have to understand why uint_fast32_t is not available, at the moment I have no idea; if the tests do not pass, the issue is probably simpler, just matter of waiting for 448 to be closed and removing all the configure contortions related to stdint.h will likely fix this issue. -- 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 middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #4 from ayers at gcc dot gnu dot org 2009-04-06 10:06 --- The patch fixes the build... a new bootstrap is in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug fortran/36528] Cray pointer to function mishandled
--- Comment #6 from pault at gcc dot gnu dot org 2009-04-06 11:07 --- Fixed on trunk and 4.4 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36528
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #5 from ayers at gcc dot gnu dot org 2009-04-06 11:07 --- Bootstrap completed successfully, thanks for the fast patch! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug fortran/36703] ICE (segfault) in reduce_binary0 (arith.c:1778)
--- Comment #6 from pault at gcc dot gnu dot org 2009-04-06 11:07 --- Fixed on trunk and 4.4 Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36703
[Bug bootstrap/39660] New: Mingw Bootstrap stops with ..host-mingw32.c:140: error: ISO C90 forbids mixed..
Latest svn version (and for the past few weeks) stops in compilation with ../../gcc4svnsource/gcc/config/i386/host-mingw32.c: In function 'mingw32_gt_pch_use_address': ../../gcc4svnsource/gcc/config/i386/host-mingw32.c:140: error: ISO C90 forbids mixed declarations and code Mingw. Using a recent 4.4. -- Summary: Mingw Bootstrap stops with ..host-mingw32.c:140: error: ISO C90 forbids mixed.. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arxeio at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39660
[Bug fortran/38538] ICE with elemental character function
--- Comment #18 from pault at gcc dot gnu dot org 2009-04-06 10:52 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38918] compile time error for DATA of NULL() to pointer structure component
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-06 10:54 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38918
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2009-02-25 18:10:46 |2009-04-06 10:55:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304
[Bug fortran/38917] Can't use DATA to initialize pointer to array to NULL()
--- Comment #5 from pault at gcc dot gnu dot org 2009-04-06 10:54 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38917
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-06 11:14 --- For cris-axis-elf we do not fold one_1 = 1.0e+0; oneL_2 = 1.0e+0; __builtin_sincos (1.0e+0, s, c); to a constant because __builtin_sincos did not get transformed to __builtin_cexpi. We fold it later via the fold-all-builtins pass but nothing promotes memory to registers after that pass with -O1. I have a patch that should fix this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||missed-optimization Last reconfirmed|2009-04-05 22:00:23 |2009-04-06 11:14:36 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug c++/39637] ICE on ill-formed sizeof(parameter-pack) in variadic template
--- Comment #2 from dodji at gcc dot gnu dot org 2009-04-06 10:28 --- Created an attachment (id=17593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17593action=view) candidate fix I am regtesting this fix atm. With it, I get the following error output from g++ trunk from today: test.cc:11: instantiated from here test.cc:5: error: enumerator value for e is not an integer constant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39637
[Bug fortran/36091] false positive in bounds checking with forall
--- Comment #9 from pault at gcc dot gnu dot org 2009-04-06 10:52 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug fortran/38915] wrong results for structure assignment of character components when left and right sides overlap
--- Comment #7 from pault at gcc dot gnu dot org 2009-04-06 10:53 --- Fixed on trunk. I am prepared to backport but the mood appears to be against it. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38915
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-04-06 11:24 --- Subject: Bug 39659 Author: hubicka Date: Mon Apr 6 11:24:32 2009 New Revision: 145589 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145589 Log: PR middle-end/39659 * except.c (remove_unreachable_regions): Propagate may_contain_throw flag. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|bootstrap |middle-end Priority|P3 |P1 Summary|[4.5][bootstrap] ICE|[4.5 Regression] ICE |building libstdc++v3|building libstdc++v3 |functexcept.cc |functexcept.cc Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #3 from hubicka at ucw dot cz 2009-04-06 09:28 --- Subject: Re: [4.5 Regression] ICE building libstdc++v3 functexcept.cc Hi, this does not reproduce on my setup, but the following patch should fix it. Honza Index: except.c === --- except.c(revision 145584) +++ except.c(working copy) @@ -853,6 +853,7 @@ remove_unreachable_regions (sbitmap reac r-region_number, first_must_not_throw-region_number); remove_eh_handler_and_replace (r, first_must_not_throw); + first_must_not_throw-may_contain_throw |= r-may_contain_throw; } else bring_to_root (r); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug target/39573] Linking fails on AMD with -march=native and -fopenmp, works with generic x86_64
--- Comment #17 from jakub at gcc dot gnu dot org 2009-04-06 08:59 ---
Smaller self-contained testcase:
int z;
void __attribute__((noinline))
bar (int *x)
{
#pragma omp atomic
z += x[2];
x[2] += x[3];
}
int
main ()
{
int i;
#pragma omp parallel for
for (i = 0; i 65536; i++)
{
int x[] =
{
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1,
1,
};
bar (x);
}
}
I've increased the size of the array to make it fail regardless of the -mtune=
setting.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Keywords||openmp
Last reconfirmed|-00-00 00:00:00 |2009-04-06 08:59:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39573
[Bug c++/25185] deep typedef substitution in error message
--- Comment #23 from dave at boostpro dot com 2009-04-06 09:35 ---
Subject: Re: deep typedef substitution in error message
On Apr 3, 2009, at 11:45 PM, jason at redhat dot com wrote:
Also, I'm not thrilled that
boost::sequence::detail::range_makerElements, Begin, End,
CalcSize::type
is still present in the signature, even if it's explained below.
Carried to an extreme, you get EDG's nasty nested
={...={...={...}}}
type descriptions. Do you need to do that? Why not just spell out
the
return type?
Because that's the return type specified in the declaration. The
alternative would be for it to say
boost::sequence::range_::rangeElements, Begin, End, typename
boost::result_ofCalcSize()::type
like it used to; do you prefer that?
No, because that contains ::type
I'd want to see
boost::sequence::range_::rangeElements, Begin, End,
mpl_::integral_cunsigned int,5u
It seemed to me that we might as
well just print the typedef in the signature and give the fully
instantiated type in the bindings list rather than give a
still-dependent type in the signature and explain any component
typenames in the bindings list, but I don't feel strongly about that.
I'm confused as to why you think you need to give a still-dependent
type in the signature
--
David Abrahams
BoostPro Computing
http://boostpro.com
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug fortran/35718] deallocating non-allocated pointer target does not fail
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2008-03-27 16:50:00 |2009-04-06 10:55:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718
[Bug tree-optimization/39657] [4.3 Regression] compiling ruby (yacc) output takes inordinate amount of time on x86 with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-06 09:39 --- tree PRE : 362.75 (97%) usr 3.30 (80%) sys 366.55 (97%) wall 7515 kB ( 8%) ggc So you can use -fno-tree-pre to work around this issue or limit the size of the SCCs processed (with the same effect) with the --param sccvn-max-scc-size -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|pending |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-06 09:39:39 date|| Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39657
[Bug c/39661] New: segmentation failed on correctly compiled mixed C and C++ code
I understand C is low-level, but I'd love the compiler to refuse to compile or link a mixed C and C++ code that is not mixed correctly. The story is: parts of the program are implemented in C, parts are in C++. The functions in C++ are made callable from C using the __attribute__((stdcall)) feature, i.e. these are C-type functions implemented in C++. The main program is in C, and attempts to call these functions, which further call -- Summary: segmentation failed on correctly compiled mixed C and C++ code Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pavel dot petrovic at gmail dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39661
[Bug libstdc++/39649] libstdc++-v3/src/functexcept.cc:65 internal compiler error: verify_eh_tree failed in stage3
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-06 09:11 --- *** This bug has been marked as a duplicate of 39659 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39649
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-06 11:00 --- Ok, I can see at least one missed CCP optimization when looking at what the x86_64 target produces. Now building a cross to see why for cris the second CCP pass together with either FRE or DOM or the third CCP pass do not fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
--- Comment #11 from pault at gcc dot gnu dot org 2009-04-06 10:57 --- Enfin, j'aborde le boulot Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|SUSPENDED |ASSIGNED Last reconfirmed|2008-03-14 13:24:43 |2009-04-06 10:57:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
[Bug c/39662] New: segmentation failed on correctly compiled mixed C and C++ code
I understand C is low-level, but I'd love the compiler to refuse to compile or
link a mixed C and C++ code that is not mixed correctly.
The story is: parts of the program are implemented in C, parts are in C++. The
functions in C++ are made callable from C using the __attribute__((stdcall))
feature, i.e. these are C-type functions implemented in C++. The main program
is in C, and attempts to call the C-style C++ function, which only computes a
number. The program crashes on exit from the main() function. It does not crash
if compiled using gcc/g++ version 3.3. However, removing the obsolete line int
a = 1; makes the program crash also when compiled using 3.3 version of the
compliers. Here are the sources:
/* fnc.h - prototype of C++ function with C-style calling style int f2(nt int)
*/
#ifdef __cplusplus
#define EXPORTCALL __attribute__((stdcall))
#else
#define EXPORTCALL
#endif
#ifdef __cplusplus
extern C {
#endif
extern int EXPORTCALL f2(int a, int b);
#ifdef __cplusplus
}
#endif
---
/* fnmc.h - main C program that calls a C++ function int f2(int, int) */
#include stdio.h
#include fnc.h
int main(int argc, char **argv)
{
int a = 1;
printf(f2(2,3)=%d\n, f2(2,3));
printf(exiting...\n);
return;
}
--
/* fnc.cpp - implementation of the C++ function int f2(int, int),
using the C-calling semantics */
#include fnc.h /* function prototype for f2() */
/* the function only returns the result */
int EXPORTCALL f2(int a, int b)
{
return a+b;
}
--
# Makefile
GCC=gcc
GPP=g++
# GCC=gcc-3.3
# GPP=g++-3.3
all:fn3
fn3:fnc.cpp fnmc.c
$(GPP) -v -save-temps -c fnc.cpp -g
$(GCC) -v -save-temps -c fnmc.c -g
$(GPP) -v -save-temps -o fn3 fnc.o fnmc.o -g
clean:
rm -f *.o *.s *.i *.ii
rm -f fn3
Here is the what is obtained when running:
petro...@student03:~/pasCPP2$ make clean
rm -f *.o *.s *.i *.ii
rm -f fn3
petro...@student03:~/pasCPP2$ make
g++ -v -save-temps -c fnc.cpp -g
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -E -quiet -v -D_GNU_SOURCE fnc.cpp
-mtune=generic -fworking-directory -fpch-preprocess -o fnc.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.2.4/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.2
/usr/include/c++/4.2/i486-linux-gnu
/usr/include/c++/4.2/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.2.4/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1plus -fpreprocessed fnc.ii -quiet
-dumpbase fnc.cpp -mtune=generic -auxbase fnc -g -version -fstack-protector
-fstack-protector -o fnc.s
GNU C++ version 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (i486-linux-gnu)
compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128358
Compiler executable checksum: cca9b7b48c023363b938f208576b99cc
as --traditional-format -V -Qy -o fnc.o fnc.s
GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.0.20080103
gcc -v -save-temps -c fnmc.c -g
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
/usr/lib/gcc/i486-linux-gnu/4.2.4/cc1 -E -quiet -v fnmc.c -mtune=generic
-fworking-directory -fpch-preprocess -o fnmc.i
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
[Bug c/39662] segmentation failed on correctly compiled mixed C and C++ code
--- Comment #1 from pavel dot petrovic at gmail dot com 2009-04-06 12:23 --- Created an attachment (id=17594) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17594action=view) archive with all sources, and i. .ii, .s files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39662
[Bug c/39662] segmentation failed on correctly compiled mixed C and C++ code
--- Comment #2 from pavel dot petrovic at gmail dot com 2009-04-06 12:28 --- *** Bug 39661 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39662
[Bug c/39661] segmentation failed on correctly compiled mixed C and C++ code
--- Comment #1 from pavel dot petrovic at gmail dot com 2009-04-06 12:28 --- *** This bug has been marked as a duplicate of 39662 *** -- pavel dot petrovic at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|segmentation failed on |segmentation failed on |correctly compiled mixed C |correctly compiled mixed C |and C++ code|and C++ code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39661
[Bug middle-end/39659] [4.5 Regression] ICE building libstdc++v3 functexcept.cc
--- Comment #7 from ayers at gcc dot gnu dot org 2009-04-06 12:29 --- Fixed. -- ayers at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39659
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #15 from hp at gcc dot gnu dot org 2009-04-06 13:36 --- (In reply to comment #14) In particular, I would like to know if on such targets stdint.h is available at C++ library configure time, the configure tests succeed Well *some* configure tests succeed (see Description), but grep says, of cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */ if the tests do not pass, the issue is probably simpler, just matter of waiting for 448 to be closed I can't see that it is a matter of something depending on that PR since all the target stuff is there, but something definitely goes wrong for libstdc++: checking for ISO C99 support to TR1 in math.h... no Maybe that newlib provides an incomplete stdint.h which is picked up before the gcc-generated one; I definitely see two stdint.h. Anyway, later on that bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug target/39663] New: mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
Mingw hosted arm-elf output differs from linux hosted arm-elf when compiling
with -Os and -mthumb for the code added below. Remove -mthumb and the output
won't differ.
Mingw hosted toolchain:
Target: arm-elf
Configured with: ../gcc-4.2.2/configure --target=arm-elf
--prefix=/proj/crossgcc/arm-elf --disable-nls --with-gnu-as --with-gnu-ld
--enable-languages=c --disable-shared --disable-threads --disable-libssp
--disable-__cxa_atexit --disable-libstdcxx-pch --enable-interwork
--enable-multilib
Thread model: single
gcc version 4.2.2
Linux hosted toolchain:
Target: arm-elf
Configured with: ../gcc-4.2.2/configure --target=arm-elf
--prefix=/proj/crossgcc/arm-elf --disable-nls --with-gnu-as --with-gnu-ld
--enable-languages=c --disable-shared --disable-threads --disable-libssp
--disable-__cxa_atexit --disable-libstdcxx-pch --enable-interwork
--enable-multilib
Thread model: single
gcc version 4.2.2
arm-elf-gcc -Wall -mlittle-endian -mthumb -mthumb-interwork -Os -save-temps -c
main.c
main.c:
typedef struct pic
{
unsigned int soft_set;
unsigned int soft_clear;
} pic_t;
typedef struct isr
{
void (*func)(void *);
void * arg;
} isr_t;
static volatile pic_t * const pSIC = (pic_t *)0xCA00;
static isr_t isr_table[32];
static void isr1 (void * arg)
{
/* Clear high priority IRQ */
pSIC-soft_clear = (1 0);
}
int main (void)
{
/* Install interrupt handlers */
isr_table[0].func = isr1;
isr_table[0].arg = (void *)3;
while(1);
return (1);
}
regards Andreas
--
Summary: mingw hosted arm-elf output differs from linux hosted
arm-elf when compiling with -Os and -mthumb
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: info dot gnu at rt-labs dot com
GCC build triplet: x86_64-unknown-linux-gnu, i686-pc-mingw32
GCC host triplet: x86_64-unknown-linux-gnu, i686-pc-mingw32
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-06 13:49 --- (In reply to comment #15) Well *some* configure tests succeed (see Description), but grep says, of cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: /* #undef _GLIBCXX_USE_C99_STDINT_TR1 */ Ok... if the tests do not pass, the issue is probably simpler, just matter of waiting for 448 to be closed I can't see that it is a matter of something depending on that PR since all the target stuff is there, I'm afraid you didn't get my point completely: *if* that macro above is disabled, then the library *assumes* stdint.h is *not* available, in general. In that case, *any* library code relying on stdint.h should be ifdef-out out completely, disabled. However, the author of the new std::random bits didn't take care of doing that - we have been consistently doing that, elsewhere - and in that case fails are expected. When 448 will be closed, we'll *remove* completely any configure test for stdint.h, we'll assume it's available, similarly to float.h for example, we'll unconditionally include it, and correctly unconditionally enable any facility relying on it. To summarize, right now, for std::random the library is in an inconsistent state for some targets, because the facility is unconditionally enabled but stdint.h is not unconditionally available. I hope my explanation is more clear. The above said, I'm not sure we should spend much time trying to figure out why for your target the configure checks for stdint.h fail, because, as I said above, as soon as 448 is closed, all those tests will go away, the library will simply assume stdint.h (that's the very point of 448, after all, for libstdc++ and all the other target libraries). If, however, you have reasons to believe your stdint.h is still not ok, it's really not ok, that's another matter, does not have much to do with libstdc++ proper. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #1 from info dot gnu at rt-labs dot com 2009-04-06 13:50 --- Created an attachment (id=17595) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17595action=view) source file that cause output difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #2 from info dot gnu at rt-labs dot com 2009-04-06 13:51 --- Created an attachment (id=17596) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17596action=view) sample makefile to genererate output difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #17 from hp at gcc dot gnu dot org 2009-04-06 14:03 --- (In reply to comment #16) I hope my explanation is more clear. Yes, thanks, sorry I didn't get the picture before. The above said, I'm not sure we should spend much time trying to figure out why for your target the configure checks for stdint.h fail, Superficially, it looks as if it fails because stdint.h isn't picked up properly by libstdc++ (in contrast to the C test-suite) so I do think this is worthwhile. I don't think it's worthwhile to try and make a distinction between incomplete-target-stdint and libstdc++-stdint-include-issues before that analysis. :) -- 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
--- Comment #18 from paolo dot carlini at oracle dot com 2009-04-06 14:13 --- (In reply to comment #17) Superficially, it looks as if it fails because stdint.h isn't picked up properly by libstdc++ (in contrast to the C test-suite) so I do think this is worthwhile. I don't think it's worthwhile to try and make a distinction between incomplete-target-stdint and libstdc++-stdint-include-issues before that analysis. :) I see what you mean, but one thing is configure time, another the library proper. Again, when 448 will closed, the library will be cleaned up to not do *any* configure time checks in this area. Otherwise, cstdint, as you can see yourself is *trivial*, cannot do anything wrong with stdint.h, as cfloat doesn't do anything wrong with float.h. That said, if you notice something strange just let us know! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-06 14:16 --- 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=39643
[Bug tree-optimization/39643] [4.5 Regression]: cris-elf gcc.dg/torture/builtin-math-3.c -O1 and -Os sincos one
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-06 14:16 --- Subject: Bug 39643 Author: rguenth Date: Mon Apr 6 14:16:15 2009 New Revision: 145604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145604 Log: 2009-04-06 Richard Guenther rguent...@suse.de PR tree-optimization/39643 * tree-ssa-ccp.c (ccp_fold): Fold REALPART_EXPRs and IMAGPART_EXPRs of complex constants. (execute_fold_all_builtins): If we folded a call queue TODO_update_address_taken. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39643
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #19 from paolo dot carlini at oracle dot com 2009-04-06 14:36 --- One final remark: since you are having problem with uint_fast32_t, unqualified, what really matters is _GLIBCXX_HAVE_STDINT_H, *not* _GLIBCXX_USE_C99_STDINT_TR1. Have a look to include/c_global/cstdint for details: if _GLIBCXX_HAVE_STDINT_H is not defined, then stdint.h isn't really included and any facility including cstdint doesn't really include much. Thus, for your target, the basic issue, at the moment, is why _GLIBCXX_HAVE_STDINT_H is not defined. Certainly in configure.ac we are running AC_CHECK_HEADERS on stdint.h... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug tree-optimization/28868] [4.3/4.4/4.5 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-04-06 14:55 --- Subject: Bug 28868 Author: rguenth Date: Mon Apr 6 14:55:31 2009 New Revision: 145607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145607 Log: 2009-04-06 Richard Guenther rguent...@suse.de PR tree-optimization/28868 * tree-ssa-pre.c (inserted_phi_names): New bitmap to keep track of which PHI results we inserted. (insert_into_preds_of_block): Record inserted PHIs. (eliminate): Eliminate redundant PHI nodes. (init_pre): Init inserted_phi_names. * gcc.dg/tree-ssa/ssa-fre-21.c: New testcase. * gcc.dg/tree-ssa/ssa-sccvn-1.c: Adjust. * gcc.dg/tree-ssa/ssa-sccvn-2.c: Likewise. * gcc.dg/tree-ssa/ssa-sccvn-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-23.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sccvn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sccvn-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sccvn-4.c trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug tree-optimization/28868] [4.3/4.4 Regression] Not eliminating the PHIs which have the same arguments
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-04-06 14:56 --- Fixed for GCC 4.5.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to work|3.3.3 3.2.3 2.95.3 |3.3.3 3.2.3 2.95.3 4.5.0 Summary|[4.3/4.4/4.5 Regression] Not|[4.3/4.4 Regression] Not |eliminating the PHIs which |eliminating the PHIs which |have the same arguments |have the same arguments http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #20 from hp at gcc dot gnu dot org 2009-04-06 15:15 --- (In reply to comment #19) One final remark: since you are having problem with uint_fast32_t, unqualified, what really matters is _GLIBCXX_HAVE_STDINT_H, *not* _GLIBCXX_USE_C99_STDINT_TR1. I see in gccobj/cris-elf/libstdc++-v3/include/cris-elf/bits/c++config.h: #define _GLIBCXX_HAVE_STDINT_H 1 -- 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
--- Comment #21 from paolo dot carlini at oracle dot com 2009-04-06 15:21 --- Interesting. Then you should really look inside the pre-processed using_namespace_std_tr1_neg.cc and see why uint_fast32_t is not known. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug c++/25185] deep typedef substitution in error message
--- Comment #24 from jason at redhat dot com 2009-04-06 15:32 --- Subject: Re: deep typedef substitution in error message dave at boostpro dot com wrote: I'm confused as to why you think you need to give a still-dependent type in the signature Because the signature we're printing is the signature of the template, not the specialization. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug libstdc++/39644] [4.5 Regression]: cris-elf 17_intro/headers/c++200x/all.cc plus 3
--- Comment #22 from paolo dot carlini at oracle dot com 2009-04-06 15:32 --- Probably, somewhere, an _GLIBCXX_USE_C99_STDINT_TR1 is protecting the inclusion of cstdint itself, thus we are back to square one... If you want - as I said, I don't think it's really a good way to spend our time - you should then figure out why the configure-time tests do not enable _GLIBCXX_USE_C99_STDINT_TR1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions
--- Comment #13 from jason at redhat dot com 2009-04-06 15:39 --- Subject: Re: C++ ABI needs clarification on mangling of complex expressions hjl dot tools at gmail dot com wrote: /export/gnu/src/gcc-work/gcc/gcc/testsuite/g++.dg/template/foo.ii:45: sorry, unimplemented: mangling template_id_expr Is this expected? That is in fact still unimplemented, and a good reason not to close the PR. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[Bug fortran/39664] New: [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled
On Linux/ia32 and Linux/x86-64, revision 145573 gave: Running 436.cactusADM ref base o2 default Error with '/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/bin/specinvoke -E -d /export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/benchspec/CPU2006/4 36.cactusADM/run/run_base_ref_o2. -c 1 -e compare.err -o compare.stdout -f c ompare.cmd': check file '/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/b enchspec/CPU2006/436.cactusADM/run/run_base_ref_o2./.err' *** Miscompare of benchADM.out, see /export/gnu/import/svn/gcc-test/spec/2006/x8 6_64/spec/benchspec/CPU2006/436.cactusADM/run/run_base_ref_o2./benchADM.out. mis -- Summary: [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=39664
[Bug libfortran/39664] [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-06 15:42 --- It may be caused by revision 145571: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||d at domob dot eu, jvdelisle ||at gcc dot gnu dot org Component|fortran |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39665] New: Fortran IO using unaligned accesses to read/write doubles.
Many fortran tests, like libgfortran.dg/arrayio_9.f90 and libgfortran.dg/arrayio_10.f90 are failing on IA64 because the IO library is reading and writing double values to unaligned addresses. In gdb I see: (gdb) r Starting program: /proj/opensrc/nightly/build-ia64-hp-hpux11.23-trunk/x Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. 0x9fffbd717700:0 in *_gfortrani_convert_real (dtp=0x9fffef80, dest=0x907c, buffer=0x60021de0 1, length=8) at /proj/opensrc/nightly/src/trunk/libgfortran/io/read.c:154 154 *((GFC_REAL_8*) dest) = strtod (buffer, NULL); The dest address is not 8 byte aligned which is what is required for writing a double out to memory on IA64 due to its strong alignment requirement. -- Summary: Fortran IO using unaligned accesses to read/write doubles. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug libfortran/39665] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #1 from sje at cup dot hp dot com 2009-04-06 16:20 --- I forgot to mention that this failure started with the merging of the fortran-dev brach into the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug c/39621] Delaying operation to end of function causes high stack usage
--- Comment #2 from hp at gcc dot gnu dot org 2009-04-06 17:16 --- It'd be nice to know if -fno-tree-reassoc helped here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
[Bug middle-end/39666] New: spurious warning with ranged-switch statements
[Follow-up to http://gcc.gnu.org/ml/gcc/2009-04/msg00175.html]
$ cat range.f90
FUNCTION f(n)
INTEGER, INTENT(in) :: n
REAL:: f
SELECT CASE (n)
CASE ( :-1); f = -1.0
CASE (0); f = 0.0
CASE (1: ); f = 1.0
END SELECT
END FUNCTION
$ gfortran-svn -c -O -Wall -fdump-tree-original -fdump-tree-optimized
range.f90
range.f90: In function 'f':
range.f90:1: warning: '__result_f' may be used uninitialized in this function
The dump after optimization shows a 'default' clause that is never reached:
bb 2:
switch (*n;) default: L6, case -2147483648 ... -1: L7, case 0: L.3, case
1 ... 2147483647: L.4
If above code is changed to
$ cat range.f90
FUNCTION f(n)
INTEGER, INTENT(in) :: n
REAL:: f
SELECT CASE (n)
CASE ( :-1); f = 0.0 ! was -1.0
CASE (0); f = 0.0
CASE (1: ); f = 0.0 ! was 1.0
END SELECT
END FUNCTION
$ gfortran-svn -c -O -Wall -fdump-tree-original -fdump-tree-optimized
range.f90
[no warning]
The dump after optimization shows:
f (integer(kind=4) n)
{
bb 2:
return 0.0;
}
The initial dump has the same structure for both cases (second case shown):
switch (*n)
{
case -2147483648 ... -1:;
__result_f = 0.0;
goto L.1;
case 0:;
__result_f = 0.0;
goto L.1;
case 1 ... 2147483647:;
__result_f = 0.0;
goto L.1;
}
L.1:;
In the first case, somewhere during optimization a 'default' is added although
the whole range of an INTEGER(kind=4) is covered - which is found in the second
case.
--
Summary: spurious warning with ranged-switch statements
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
[Bug fortran/39667] New: Possibly unneccesary truncations
See: http://gcc.gnu.org/ml/fortran/2009-04/msg00054.html Some namelist and utf8/widechar tests now require a working fd_truncate, which causes failures on systems not offering this. Thus one should check whether the truncations are really needed. -- Summary: Possibly unneccesary truncations Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug libfortran/39665] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #2 from domob at gcc dot gnu dot org 2009-04-06 18:16 --- See also this thread: http://gcc.gnu.org/ml/fortran/2009-04/msg00065.html -- domob 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-06 18:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug rtl-optimization/38603] [4.4/4.5 Regression] IRA does not accommodate LOAD_EXTEND_OP transformations done by combine
--- Comment #5 from ubizjak at gmail dot com 2009-04-06 18:18 --- It looks to me that this is a reload bug, independent of IRA. See thread [1] for analysis of what seems to be the same problem. [1] http://gcc.gnu.org/ml/gcc/2009-04/msg00033.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
[Bug rtl-optimization/38603] [4.4/4.5 Regression] IRA does not accommodate LOAD_EXTEND_OP transformations done by combine
--- Comment #6 from ubizjak at gmail dot com 2009-04-06 18:20 --- (In reply to comment #5) It looks to me that this is a reload bug, independent of IRA. See thread [1] for analysis of what seems to be the same problem. [1] http://gcc.gnu.org/ml/gcc/2009-04/msg00033.html Thread continues at http://gcc.gnu.org/ml/gcc/2009-04/msg00038.html. -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
Re: Register Allocation Bug?
#define ESP (rel,value,addr) \ asm volatile (mov (%%esp, %2, 4), %0\n \t \ lea (%%esp, %2, 4), %1\n \t \ : =r (value), =r (addr) \ : r (rel)); \ It didn't work as expected so I looked at the assembler code generated for the above: 1: b8 00 00 00 00 mov$0x0,%eax 2: 8b 04 84mov(%esp,%eax,4),%eax 3: 8d 14 84lea(%esp,%eax,4),%edx 4: 89 45 f8mov%eax,0xfff8(%ebp) 5: 89 55 fcmov%edx,0xfffc(%ebp) As it turns out, %eax is being used for both input and output in line 2, clobbering %eax, so of course line 3 does not give the expected result... Is this a compiler error? It's not a compiler bug: you need to use an early clobber, namely =r(value) . See the Fine Manual. Segher
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #8 from js-gcc at webkeks dot org 2009-04-06 19:41 --- Any news on this? Any way how I could compile libobjc as a shared library? Specifying --enable-shared breaks basically every library that gcc ships and I haven't found a way to only enable it for libobjc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libfortran/39664] [4.5 Regression] 436.cactusADM in SPEC CPU 2006 is miscompiled
--- Comment #2 from burnus at gcc dot gnu dot org 2009-04-06 19:49 --- Could you try to reduce the problem - as SPEC is not publicly available it is a bit hard to debug (by far most gfortraners do not have access to SPEC). (In reply to comment #1) It may be caused by revision 145571: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html Could you confirm that it was indeed caused by that patch? (You wrote may ... ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 caused 436.cactusADM in SPEC CPU 2006 to fail
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-06 19:52 --- (In reply to comment #2) Could you try to reduce the problem - as SPEC is not publicly available it is a bit hard to debug (by far most gfortraners do not have access to SPEC). I am working on it. (In reply to comment #1) It may be caused by revision 145571: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00193.html Could you confirm that it was indeed caused by that patch? (You wrote may ... ;-) Yes, revision 145571 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression]|[4.5 Regression] Revision |436.cactusADM in SPEC CPU |145571 caused 436.cactusADM |2006 is miscompiled |in SPEC CPU 2006 to fail http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #7 from pault at gcc dot gnu dot org 2009-04-06 20:13 --- Subject: Bug 38863 Author: pault Date: Mon Apr 6 20:13:39 2009 New Revision: 145621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145621 Log: 2009-04-06 Paul Thomas pa...@gcc.gnu.org PR fortran/38863 * dependency.c (ref_same_as_full_array): New function. (gfc_dep_resolver): Call it. 2009-04-06 Paul Thomas pa...@gcc.gnu.org PR fortran/38863 * gfortran.dg/dependency_23.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dependency_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #8 from jason at gcc dot gnu dot org 2009-04-06 20:14 --- The testcase in comment #2 is ill-formed; templatevoid foo(Sdouble, Sdouble*); is not a specialization of any function template in scope. But we're giving very much the wrong error for that. Testing a patch now. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-03-31 15:10:20 |2009-04-06 20:14:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #8 from pault at gcc dot gnu dot org 2009-04-06 20:17 --- Fixed on trunk. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #9 from jason at gcc dot gnu dot org 2009-04-06 20:29 --- ...and GCC miscompiles the original testcase due to the same bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug libfortran/39668] New: Wrongly read namelist with two dimensional array.
Fortran code: INTEGER :: i(3,3) namelist/namtest/i i=0 OPEN(10) CLOSE(10) READ(10,namtest) WRITE(6,namtest) END Namelist in fort.10: namtest i(1,1)=1,2,3, i(2,1)=4,5,6, i(3,1)=7,8,9, / Print out of program: NAMTEST I= 1, 4, 7, 0, 6, 8, 2*0 , 9, / Output should have been: NAMTEST I= 1, 4, 7, 2, 5, 8, 3, 6, 9, / -- Summary: Wrongly read namelist with two dimensional array. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: toon at moene dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39668
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #10 from jason at gcc dot gnu dot org 2009-04-06 20:55 --- Subject: Bug 35146 Author: jason Date: Mon Apr 6 20:55:04 2009 New Revision: 145625 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145625 Log: PR c++/35146 * pt.c (fn_type_unification): For DEDUCE_EXACT check that the deduced template arguments give us the parameter types we're looking for. Added: trunk/gcc/testsuite/g++.dg/template/fnspec1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #9 from ayers at gcc dot gnu dot org 2009-04-06 21:22 --- I'm sorry, I'm simply not familiar with cygwin/mingw environments and cross builds. But I'm surprised that --enable-shared doesn't work. Is that a native build? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libfortran/39664] [4.5 Regression] Revision 145571 caused 436.cactusADM in SPEC CPU 2006 to fail
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-06 21:34 --- It is very hard to extract a small testcase. However, you can download Cactus from http://www.cactuscode.org/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug c++/35146] [4.3/4.4/4.5 regression] weird error in template function specialization
--- Comment #11 from jason at gcc dot gnu dot org 2009-04-06 21:35 --- Subject: Bug 35146 Author: jason Date: Mon Apr 6 21:35:29 2009 New Revision: 145634 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145634 Log: PR c++/35146 * pt.c (fn_type_unification): For DEDUCE_EXACT check that the deduced template arguments give us the parameter types we're looking for. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/fnspec1.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35146
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #10 from js-gcc at webkeks dot org 2009-04-06 21:39 --- What exactly do you mean by native build? Do you mean if I build a compiler to run on Linux and not on win32, but which targets win32? If so, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug bootstrap/39617] bootstrap failure with ICE building libiberty in stage3
--- Comment #2 from janis at gcc dot gnu dot org 2009-04-06 21:39 --- Surprise, Richard, you fixed this! The failure goes away with r145494, the merge of the alias-improvements branch. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39617
[Bug libobjc/39465] libobjc does not find classes of DLLs
--- Comment #11 from ayers at gcc dot gnu dot org 2009-04-06 21:59 --- With 'native' I meant mingw := build=host=target so no... it's not native in the sense that I was talking about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39465
[Bug libfortran/39664] [4.5 Regression] Revision 145571 caused 436.cactusADM in SPEC CPU 2006 to fail
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-06 22:15 --- cactusADM has both C and Fortran. The following code printf(\n); printf(Done.\n); in C won't show up when the output is redirected to a file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-06 22:20 ---
Revision 145571 breaks stdio when the output was redirected to a file:
[h[...@gnu-16 pr39664]$ cat foo.c
#include stdio.h
int
main ()
{
printf(\n);
printf(Done.\n);
return 0;
}
j...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gcc -O2 -c -o
foo.o
foo.c
[...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gfortran -o foo
foo.o
[...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
./foo 1
[...@gnu-16 pr39664]$ cat 1
[...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
./foo
Done.
[...@gnu-16 pr39664]$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Summary|[4.5 Regression] Revision |[4.5 Regression] Revision
|145571 caused 436.cactusADM |145571 breaks stdio
|in SPEC CPU 2006 to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-06 22:22 --- I don't know if this is really a bug. The interaction between Fortran I/O and C FILE I/O is not defined anywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug target/39593] [avr] faulty value assignment
--- Comment #10 from eric dot weddington at atmel dot com 2009-04-06 22:38 --- This looks like a duplicate of bug #37466. *** This bug has been marked as a duplicate of 37466 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39593
[Bug target/37466] [AVR] avr-gcc generating incorrect assembly for expression with the long constant operands
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-06 22:38 --- *** Bug 39593 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||szir at sch dot bme dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37466
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-06 22:41 --- (In reply to comment #7) I don't know if this is really a bug. The interaction between Fortran I/O and C FILE I/O is not defined anywhere. Does it mean that gcc doesn't support mixing C codes which contain stdio with Fortran I/O? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #9 from hjl dot tools at gmail dot com 2009-04-06 22:43 ---
This patch seems to work for the small testcase:
Index: io/unix.c
===
--- io/unix.c (revision 145571)
+++ io/unix.c (working copy)
@@ -344,7 +344,12 @@ raw_close (unix_stream * s)
{
int retval;
- retval = close (s-fd);
+ if (s-fd != STDOUT_FILENO
+ s-fd != STDERR_FILENO
+ s-fd != STDIN_FILENO)
+retval = close (s-fd);
+ else
+retval = SUCCESS;
free_mem (s);
return retval;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #10 from kargl at gcc dot gnu dot org 2009-04-06 22:46 ---
(In reply to comment #6)
Revision 145571 breaks stdio when the output was redirected to a file:
[h[...@gnu-16 pr39664]$ cat foo.c
#include stdio.h
int
main ()
{
printf(\n);
printf(Done.\n);
return 0;
}
j...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gcc -O2 -c -o
foo.o
foo.c
[...@gnu-16 pr39664]$ /export/gnu/import/rrs/145571/usr/bin/gfortran -o foo
foo.o
[...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
./foo 1
[...@gnu-16 pr39664]$ cat 1
[...@gnu-16 pr39664]$ LD_LIBRARY_PATH=/export/gnu/import/rrs/145571/usr/lib64
./foo
Done.
[...@gnu-16 pr39664]$
Works for me.
troutmask:sgk[204] ~/work/4x/bin/gcc -c g.c
troutmask:sgk[205] gfc4x -o z g.o
troutmask:sgk[206] ./z zxc
troutmask:sgk[207] cat zxc
Done.
troutmask:sgk[208] gfc4x --version
GNU Fortran (GCC) 4.5.0 20090406 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-06 22:47
---
(In reply to comment #9)
This patch seems to work for the small testcase:
This patch looks correct based on the old code:
- if (s-fd != STDOUT_FILENO s-fd != STDERR_FILENO s-fd !=
STDIN_FILENO)
-{
- if (close (s-fd) 0)
- return FAILURE;
-}
-
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-06 22:53 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00464.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||04/msg00464.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #13 from hjl dot tools at gmail dot com 2009-04-06 22:57 --- (In reply to comment #10) Works for me. troutmask:sgk[204] ~/work/4x/bin/gcc -c g.c troutmask:sgk[205] gfc4x -o z g.o troutmask:sgk[206] ./z zxc troutmask:sgk[207] cat zxc Done. Did you try it on Linux? libgfortran closes FDs which are the parts of C library. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #14 from hjl at gcc dot gnu dot org 2009-04-06 23:08 --- Subject: Bug 39664 Author: hjl Date: Mon Apr 6 23:07:51 2009 New Revision: 145636 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145636 Log: 2009-04-06 H.J. Lu hongjiu...@intel.com PR libgfortran/39664 * io/unix.c (raw_close): Don't close STDOUT_FILENO, STDERR_FILENO nor STDIN_FILENO. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug libfortran/39664] [4.5 Regression] Revision 145571 breaks stdio
--- Comment #15 from hjl dot tools at gmail dot com 2009-04-06 23:16 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39664
[Bug gcov-profile/39669] New: gcov --preserve-paths causes mangled filenames on windows
using a MinGW build of gcov 'gcov (GCC) 3.4.5 (mingw-vista special r3)' --preserve paths cause mangled output filenames. Say there is a file called C:/foo/bar.gcda calling 'gcov C:/foo/bar.gcda -o foo --preserve-paths -b' from 'C:\' causes the file 'foo#bar.gcov' to be output in in 'c:\' instead of 'bar.gcov' being produced in 'c:\foo\' -- Summary: gcov --preserve-paths causes mangled filenames on windows Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: gcov-profile AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kazeits at rockwellcollins dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows
--- Comment #1 from kazeits at rockwellcollins dot com 2009-04-06 23:50 --- Created an attachment (id=17597) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17597action=view) test case: zip file containing example project. unzipping and runing 'make coverage_bad' shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug gcov-profile/39669] gcov --preserve-paths causes mangled filenames on windows
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-06 23:51 --- Can you try a newer GCC? 3.4.x has not been supported for a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39669
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #3 from hp at gcc dot gnu dot org 2009-04-07 00:38 --- The issue is rather 64-bit HOST_WIDE_INT host compared to 32-bit HOST_WIDE_INT host. (To prove wrong, compare with i686-unknown-linux-gnu instead x86_64-unknown-linux-gnu or configure and build with 'CC=gcc -m32'.) You *will* see some differences for code where 64-bit entities appear (maybe your pic_t and isr_t); known issue. I think there's another PR which to which this is a duplicate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug target/39634] powerpc64 libgcc contains useless softfp functions
--- Comment #1 from amodra at gcc dot gnu dot org 2009-04-07 00:47 --- Subject: Bug 39634 Author: amodra Date: Tue Apr 7 00:47:21 2009 New Revision: 145641 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145641 Log: PR target/39634 * config.gcc: Merge powerpc-*-linux* and powerpc64-*-linux*. Include soft-fp/t-softfp after rs6000/t-linux64. * config.host: Reorder and merge to match config.gcc change. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/libgcc/ChangeLog trunk/libgcc/config.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39634
