[Bug fortran/36824] gfortran does not recognize constant array bounds in dimension attribute of type component
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-17 05:55 --- Subject: Bug 36824 Author: burnus Date: Thu Jul 17 05:54:42 2008 New Revision: 137910 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137910 Log: 2008-07-17 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36825 PR fortran/36824 * array.c (gfc_match_array_spec): Fix array-rank check. * resolve.c (resolve_fl_derived): Fix constentness check for the array dimensions. 2008-07-17 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36825 PR fortran/36824 * gfortran.dg/rank_2.f90: Add additional array-rank test. * gfortran.dg/array_4.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/rank_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36824
[Bug fortran/36825] Problems with dimensions > 7
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-17 05:55 --- Subject: Bug 36825 Author: burnus Date: Thu Jul 17 05:54:42 2008 New Revision: 137910 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137910 Log: 2008-07-17 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36825 PR fortran/36824 * array.c (gfc_match_array_spec): Fix array-rank check. * resolve.c (resolve_fl_derived): Fix constentness check for the array dimensions. 2008-07-17 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/36825 PR fortran/36824 * gfortran.dg/rank_2.f90: Add additional array-rank test. * gfortran.dg/array_4.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/rank_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
[Bug middle-end/36859] Caller/callee mismatch for vararg on stack
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-17 05:25 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01247.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||07/msg01247.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36859
[Bug middle-end/36858] Incorrect alignment attribute on stack parameter
--- Comment #1 from hjl dot tools at gmail dot com 2008-07-17 05:19 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01241.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||07/msg01241.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36858
[Bug testsuite/36443] [4.3/4.4 Regression]: HOSTCC doesn't work with installed gcc
--- Comment #28 from hjl at gcc dot gnu dot org 2008-07-17 05:14 --- Subject: Bug 36443 Author: hjl Date: Thu Jul 17 05:13:27 2008 New Revision: 137909 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137909 Log: 2008-07-17 H.J. Lu <[EMAIL PROTECTED]> PR testsuite/36443 * objc.dg/gnu-encoding/gnu-encoding.exp: Temporarily unset GCC_EXEC_PREFIX from environment when running $HOSTCC. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36443
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #13 from kkojima at gcc dot gnu dot org 2008-07-17 02:08 --- > Try changing the "reloaded != 1" condition in find_reloads_subreg_address > to "reloaded == 0" (as a replacement for my m32c patch, and probably for > the SH patch as well). I hope that should avoid these problems in the > cases where LEGITIMIZE_RELOAD_ADDRESS does something like this, and I've > verified the original ARM testcase that motivated my reload change still > works with that change. This works fine on SH. With this and backing out the workaround in GO_IF_LEGITIMATE_ADDRESS, sh4-unknown-linux-gnu cross x86 is built successfully and the result of regtest looks very clean. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug c++/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
--- Comment #3 from jeff at jeffunit dot com 2008-07-17 02:07 --- Created an attachment (id=15920) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15920&action=view) Here is the subroutine, run throuh the preprocessor using gcc-3.4.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
--- Comment #2 from jeff at jeffunit dot com 2008-07-17 01:59 --- In order to run the entire program, you will need a fair amount of code. All needed code can be found at the above URL, along with test data. -- jeff at jeffunit dot com changed: What|Removed |Added URL||www.weasel.com/sim_test.tar. ||gz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/36860] gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
--- Comment #1 from jeff at jeffunit dot com 2008-07-17 01:57 --- Created an attachment (id=15919) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15919&action=view) this is the preprocessed subroutine that is poorly optimized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/36860] New: gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia
I have a subroutine that is heavily used by a program I frequently run called UKKA_Dist_With_Max. I had benchmarked it using mandriva linux 2005LE. When I ran it using mandriva 2008.1, it ran much slower. Using the compiler from mandriva linux 2005LE (gcc-3.4.3) and mandriva 2008.1, I was able to reproduce the problem. For example, with gcc-3.4.3 a small run takes 191 seconds, but with gcc-4.2.3 the same run takes 247 seconds. The switches I am using to compile, with both compilers are: -O3 -march=pentium4 -mtune=pentium4 -g -pthread \ -finline-functions -fschedule-insns2 -fbounds-check \ -W -Wall -pedantic -Wshadow -Wpointer-arith -Weffc++ \ -Wcast-qual -Wcast-align -Wwrite-strings -Wunused \ -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder \ -Woverloaded-virtual -Wsign-promo -Wunused-parameter \ -Wpointer-arith -Wreturn-type -Wcast-qual -Wswitch \ -Wshadow -Wcast-align \ -Wchar-subscripts -Winline -Wredundant-decls gcc-4.2.3 was prebuilt by mandriva with the following: Using built-in specs. Target: i586-manbo-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=i586-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.3 (4.2.3-6mnb1) gcc-3.4.3 was built by me with the following: Reading specs from /home/jdeifik_2008.1/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: ../gcc-3.4.3/configure --prefix=/home/jdeifik_2008.1 Thread model: posix gcc version 3.4.3 Here is the subroutine file, run through the preprocessor using gcc-4.2.3: -- Summary: gcc 4.2.3 produces poor code compared to gcc-3.4.3 on xeon prestonia Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jeff at jeffunit dot com GCC build triplet: i586-manbo-linux-gnu GCC host triplet: i586-manbo-linux-gnu GCC target triplet: i586-manbo-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36860
[Bug c++/13699] Extern "C" routine in different namespaces accepted with different exception signature
--- Comment #8 from dodji at gcc dot gnu dot org 2008-07-16 23:52 --- fixed in trunk. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13699
[Bug c++/13699] Extern "C" routine in different namespaces accepted with different exception signature
--- Comment #7 from dodji at gcc dot gnu dot org 2008-07-16 23:44 --- Subject: Bug 13699 Author: dodji Date: Wed Jul 16 23:44:02 2008 New Revision: 137904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137904 Log: 2008-07-16 Dodji Seketeli <[EMAIL PROTECTED]> PR c++/13699 * gcc/cp/name-lookup.c (lookup_extern_c_fun_binding_in_all_ns): New function. (pushdecl_maybe_friend): Check if a redeclaration of extern C function complies with exception specification constraints. Added: trunk/gcc/testsuite/g++.dg/lookup/extern-c-redecl.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13699
[Bug debug/36589] [4.4 Regression]: No debug info for local static variable at -O0
--- Comment #3 from hubicka at gcc dot gnu dot org 2008-07-16 23:14 --- Fix comitted. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36589
[Bug middle-end/36859] New: Caller/callee mismatch for vararg on stack
locate_and_pad_parm never align parameters on stack for
callers. It only caps parameter alignment to
PREFERRED_STACK_BOUNDARY. But std_gimplify_va_arg_expr
tries to align stack for callee:
/* va_list pointer is aligned to PARM_BOUNDARY. If argument actually
requires greater alignment, we must perform dynamic alignment. */
if (boundary > align
&& !integer_zerop (TYPE_SIZE (type)))
{
t = build2 (MODIFY_EXPR, TREE_TYPE (valist), valist_tmp,
fold_build2 (POINTER_PLUS_EXPR, TREE_TYPE (valist),
valist_tmp, size_int (boundary - 1)));
gimplify_and_add (t, pre_p);
t = fold_convert (sizetype, valist_tmp);
t = build2 (MODIFY_EXPR, TREE_TYPE (valist), valist_tmp,
fold_convert (TREE_TYPE (valist),
fold_build2 (BIT_AND_EXPR, sizetype, t,
size_int (-boundary;
gimplify_and_add (t, pre_p);
}
else
boundary = align;
We have a mismatch between caller and callee. I have a testcase for ia32.
But it depends on PR 36858.
--
Summary: Caller/callee mismatch for vararg on stack
Product: gcc
Version: 4.4.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
BugsThisDependsOn: 36858
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36859
[Bug libfortran/36773] zero-sized arrays with cshift and eoshift
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-07-16 21:24 --- Created an attachment (id=15918) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15918&action=view) better patch This one actually works for eoshift and passes all zero* and *shift* tests in gfortran.dg. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Attachment #15917|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36773
[Bug middle-end/36858] New: Incorrect alignment attribute on stack parameter
locate_and_pad_parm has where_pad = FUNCTION_ARG_PADDING (passed_mode, type); boundary = FUNCTION_ARG_BOUNDARY (passed_mode, type); locate->where_pad = where_pad; locate->boundary = boundary; /* Remember if the outgoing parameter requires extra alignment on the calling function side. */ if (boundary > PREFERRED_STACK_BOUNDARY) boundary = PREFERRED_STACK_BOUNDARY; When boundary > PREFERRED_STACK_BOUNDARY, boundary is capped to PREFERRED_STACK_BOUNDARY. But locate->boundary has the wrong value. The following patch should correct this: Index: function.c === --- function.c (revision 137896) +++ function.c (working copy) @@ -3258,13 +3258,13 @@ locate_and_pad_parm (enum machine_mode p = type ? size_in_bytes (type) : size_int (GET_MODE_SIZE (passed_mode)); where_pad = FUNCTION_ARG_PADDING (passed_mode, type); boundary = FUNCTION_ARG_BOUNDARY (passed_mode, type); + if (boundary > PREFERRED_STACK_BOUNDARY) +boundary = PREFERRED_STACK_BOUNDARY; locate->where_pad = where_pad; locate->boundary = boundary; /* Remember if the outgoing parameter requires extra alignment on the calling function side. */ - if (boundary > PREFERRED_STACK_BOUNDARY) -boundary = PREFERRED_STACK_BOUNDARY; if (crtl->stack_alignment_needed < boundary) crtl->stack_alignment_needed = boundary; -- Summary: Incorrect alignment attribute on stack parameter Product: gcc Version: 4.4.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=36858
[Bug libfortran/36857] Non-English locale breaks gfortran float formatting ("printf is broken")
--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-16 20:45 --- > program main > CALL badlocale() > WRITE(*,'(G2.4)') 1.2345 > end program main > > If the code executed correctly, the expected output would be > 1,235 No, the expected output would be "1.235" according to the Fortran standard. You need to use, e.g., WRITE(*, '(G2.4)',decimal='comma') 1.2345 to get the "1,235". (decimal="comma" and "dc" are supported since gfortran 4.4 and part for the Fortran 2003 standard.) However, I agree that gfortran should not print an internal error as setting the locale might happen in mixed-language programming. The question is only how to enforce a LC_ALL = "C" for libgfortran's printf calls without causing other problems such has performance hits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36857
[Bug fortran/36825] Problems with dimensions > 7
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-16 20:36 --- Jerry, you know libgfortran better than me. Can one simply change in libgfortran.h: #define GFC_DTYPE_RANK_MASK 0x07 to 0x0F (= 15) or does this cause some problems with the gcc 4.3 compatibility or ... ? Actually, why is this defined as "0x07" and not as "7"? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36825
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #12 from joseph at codesourcery dot com 2008-07-16 20:25 --- Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload On Wed, 16 Jul 2008, dj at redhat dot com wrote: > Last night's builds showed a flaw in the patch. The "++rii" address > created by m32c_legitimize_reload_address is *not* legitimate, it's > used as a marker for addresses that need to be reloaded into an > address register. If I fix m32c_print_operand() to print those, it > ends up printing an address that exceeds the displacement range of the > FB register: Try changing the "reloaded != 1" condition in find_reloads_subreg_address to "reloaded == 0" (as a replacement for my m32c patch, and probably for the SH patch as well). I hope that should avoid these problems in the cases where LEGITIMIZE_RELOAD_ADDRESS does something like this, and I've verified the original ARM testcase that motivated my reload change still works with that change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug libfortran/36857] New: Non-English locale breaks gfortran float formatting ("printf is broken")
GFortran float printing breaks when a non-English locale is selected. Instead,
"Internal error: printf is broken" appears. The failing part is a sanity check
in libgfortran, where it was forgotten that in some non-English locales,
sprintf will format floats using a comma instead of a period as the decimal
separator.
Tested gcc version 4:4.2.3-1ubuntu6 as bundled on Ubuntu Hardy, but probably
present also in trunk.
The following code triggers this bug:
bug.f90:
program main
CALL badlocale()
WRITE(*,'(G2.4)') 1.2345
end program main
bug.c:
--
#include
void badlocale_() { setlocale(LC_ALL, "fi_FI.UTF-8"); }
The compiled program to fails with internal error:
gcc -c -o bug.o bug.c; gfortran -o bug bug.f90 bug.o -lc ; ./bug
At line 3 of file bug.f90
Internal Error: printf is broken
If the code executed correctly, the expected output would be
1,235
To my understanding the failing code appears to be in
libgfortran/io/write_float.def:output_float (around line 126):
/* Check the given string has punctuation in the correct places. */
if (d != 0 && (buffer[2] != '.' || buffer[ndigits + 2] != 'e'))
internal_error (&dtp->common, "printf is broken");
Before execution arrives here, the buffer is filled by sprintf in write_float,
and as said, in some locales the correct formatting of a float will contain a
comma instead of a period.
--
Summary: Non-English locale breaks gfortran float formatting
("printf is broken")
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pav at iki dot fi
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=36857
[Bug c++/36856] [c++0x] __is_pod() fails for some pod types
--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-16 19:30 --- Of course, but really doesn't make sense trying now implementing that, simply there is no infrastructure in the front-end for C++0x POD-ness, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug c++/36856] [c++0x] __is_pod() fails for some pod types
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-16 19:30 --- (In reply to comment #4) > We're using -std=gnu++0x, so we're expecting the implementation to follow > C++ 0x rules. Except the ABI says something different from C++0x ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug c++/36856] [c++0x] __is_pod() fails for some pod types
--- Comment #4 from sebor at roguewave dot com 2008-07-16 19:26 --- We're using -std=gnu++0x, so we're expecting the implementation to follow C++ 0x rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug c++/36856] [c++0x] __is_pod() fails for some pod types
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-16 19:10 --- derived_pod_t is still a non POD type according to the C++98/C++03 standard. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Version|3.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #11 from dj at redhat dot com 2008-07-16 19:08 --- Subject: Re: [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload Last night's builds showed a flaw in the patch. The "++rii" address created by m32c_legitimize_reload_address is *not* legitimate, it's used as a marker for addresses that need to be reloaded into an address register. If I fix m32c_print_operand() to print those, it ends up printing an address that exceeds the displacement range of the FB register: regex.s:11903: Error: unrecognized keyword/register name `mov.w mem0,-198[fb]' The original idea was to reload $fb of $sp itself into an address register, and use a displacement off that, so that only one address register is needed for all frame address reloads. I never quite got gcc to do it right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug c++/36856] __is_pod() fails for some pod types
--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-16 19:00 --- Note, I'm going to suspend this, because, besides the traits "builtins" we are not implementing anything in the front-end having to do with the new characterization in C++0x of POD. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug c++/36856] __is_pod() fails for some pod types
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-16 18:58:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36856
[Bug c++/36855] __has_trivial_destructor() returns false for reference types.
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-07-16 18:58:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36855
[Bug c++/36856] New: __is_pod() fails for some pod types
The __is_pod() built-in returns false for pod class types that have base
classes, which is allowed by c++0x.
Environment:
System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007
x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: /build/sebor/src/gcc-4.3.0/configure
--prefix=/nfs/devco/contrib/linux/gcc-4.3.0
--with-gmp=/nfs/devco/contrib/linux/gmp-4.2
--with-mpfr=/nfs/devco/contrib/linux/mpfr-2.3.1
How-To-Repeat:
Compile the following code as g++ -std=gnu++0x t.cpp
struct pod_t { };
struct derived_pod_t : pod_t { };
typedef char assert [__is_pod (derived_pod_t) ? 1 : -1];
--- Comment #1 from vitek at roguewave dot com 2008-07-16 18:54 ---
Fix:
No known workaround.
--
Summary: __is_pod() fails for some pod types
Product: gcc
Version: 3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vitek at roguewave 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=36856
[Bug libfortran/36773] zero-sized arrays with cshift and eoshift
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-16 18:51 --- (In reply to comment #1) > Created an attachment (id=15917) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15917&action=view) [edit] > proposed patch ... which doesn't work in all cases. Still investigating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36773
[Bug c++/36855] New: __has_trivial_destructor() returns false for reference types.
__has_trivial_destructor() returns false for all reference types, but should return true according to documentation. The documented behavior is consistent with what is required by the c++0x draft. Environment: System: Linux cranium 2.6.18-8.el5xen #1 SMP Fri Jan 26 14:29:35 EST 2007 x86_64 x86_64 x86_64 GNU/Linux Architecture: x86_64 host: x86_64-unknown-linux-gnu build: x86_64-unknown-linux-gnu target: x86_64-unknown-linux-gnu configured with: /build/sebor/src/gcc-4.3.0/configure --prefix=/nfs/devco/contrib/linux/gcc-4.3.0 --with-gmp=/nfs/devco/contrib/linux/gmp-4.2 --with-mpfr=/nfs/devco/contrib/linux/mpfr-2.3.1 How-To-Repeat: Attempt to compile the following code as g++ -std=gnu++0x t.cpp typedef char assert_0 [__has_trivial_destructor (int&) ? 1 : -1]; --- Comment #1 from vitek at roguewave dot com 2008-07-16 18:45 --- Fix: A workaround would be to use a wrapper template that has a special case for reference types. -- Summary: __has_trivial_destructor() returns false for reference types. Product: gcc Version: 3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vitek at roguewave 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=36855
[Bug libfortran/36773] zero-sized arrays with cshift and eoshift
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-16 18:43 --- Created an attachment (id=15917) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15917&action=view) proposed patch -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36773
[Bug fortran/36854] New: [meta] fortran front-end optimization
This is just a collector of optimizations that the front end could do before generating tree codes. -- Summary: [meta] fortran front-end optimization Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: meta-bug Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org BugsThisDependsOn: 36841 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug bootstrap/36853] New: Compiling gcc 4.3.1 with Ada fails with Gnat bug detection
Compiling gcc 4.3.1 on my machine fails with the following error message: -- make profiledbootstrap ... /tmp/bitti/gccobj/./prev-gcc/xgcc -B/tmp/bitti/gccobj/./prev-gcc/ -B/share/gcc/gcc-4.3.1/i686-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -fprofile-generate -gnatpg -gnata -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I../../gcc-4.3.1/gcc/ada ../../gcc-4.3.1/gcc/ada/a-except.adb -o ada/a-except.o ../../gcc-4.3.1/gcc/ada/a-except.adb: In function 'Ada.Exceptions.Raise_From_Controlled_Operation': ../../gcc-4.3.1/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc-4.3.1/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc-4.3.1/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc-4.3.1/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 ../../gcc-4.3.1/gcc/ada/a-except.adb:1305: error: control flow in the middle of basic block 20 +===GNAT BUG DETECTED==+ | 4.3.1 (i686-pc-linux-gnu) verify_flow_info failed| | Error detected around ../../gcc-4.3.1/gcc/ada/a-except.adb:1305 | | 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). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:398 make[3]: *** [ada/a-except.o] Error 1 make[3]: Leaving directory `/tmp/bitti/gccobj/gcc' make[2]: *** [all-stageprofile-gcc] Error 2 make[2]: Leaving directory `/tmp/bitti/gccobj' make[1]: *** [stageprofile-bubble] Error 2 make[1]: Leaving directory `/tmp/bitti/gccobj' The compiler was configured like this: ../gcc-4.3.1/configure --prefix=/share/gcc/gcc-4.3.1 --with-arch=i686 --enable-languages=c,c++,java,ada,fortran --enable-__cxa_atexit --enable-java-awt=gtk --with-mpfr=/share/gcc/mpfr-2.3.1 (Where /share/gcc/mpfr-2.3.1 contains a freshly compiled static mpfr libraries and includes) -- Summary: Compiling gcc 4.3.1 with Ada fails with Gnat bug detection Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bitti at iki dot fi 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=36853
[Bug c++/36852] Two dimensional array in template method argument list incorrectly interpreted.
--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-16 16:37
---
We badly need a self-contained testcase (per our general guidelines) because
something trivial inspired by your PR, like the below compiles just fine.
template
T A::determinant3(T matrix[3][3])
{
// NB: not the real formula ;)
return matrix[0][0] + matrix[1][1] + matrix[2][2];
}
int main()
{
double array[3][3];
A::determinant3(array);
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36852
[Bug c++/36852] New: Two dimensional array in template method argument list incorrectly interpreted.
We have a class more or less like this: (please bear with me, this is only an
approximation.
class A
{
template static T determinant4(T matrix[4][4]);
template static T determinant3(T matrix[3][3]);
template static T determinant2(T matrix[2][2]);
};
template
T A::determinant3(T matrix[3][3])
{
// do stuff
}
When this header file is included in a cpp file, its compilation with gcc 4.3.1
tells me it can't find the determinant3 method.
GCC tells me:
common_Math.h:270: error: prototype for T common_Math::determinant3(T (*)[3])
does not match any in class common_Math
common_Math.h:179: error: candidate is: template static T
common_Math::determinant3(T (*)[3])
I have had trouble reproducing this example in an isolated environment. What I
can tell you thought is that if you modify the array to be only of single
dimension, it compiles happily.
Also all the methods that are not 3x3 matrices, the 4x4 method for example
compiles correctly.
For this instance of the compilation, T is of type double. It was compiled on
a 32 bit machine.
--
Summary: Two dimensional array in template method argument list
incorrectly interpreted.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: djh at emss dot co dot za
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36852
[Bug bootstrap/36851] New: [4.4 regression] cc1plus SEGV compiling strstream.cc on Tru64 UNIX
Bootstrapping mainline on Tru64 UNIX V5.1B fails as of 20080613:
libtool: compile: /vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/./gcc/xgcc
-shared-libgcc -B/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/./gcc -nostdinc++
-L/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src
-L/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src/.libs
-B/vol/gcc/alpha-dec-osf5.1b/bin/ -B/vol/gcc/alpha-dec-osf5.1b/lib/ -isystem
/vol/gcc/alpha-dec-osf5.1b/include -isystem
/vol/gcc/alpha-dec-osf5.1b/sys-include
-I/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/alpha-dec-osf5.1b
-I/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include
-I/vol/gccsrc/src/gcc-dist/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall
-Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -g -O2
-mieee
-I/vol/gccsrc/obj/gcc-4.4.0-20080613/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/backward
-Wno-deprecated -c /vol/gcc/src/gcc-dist/libstdc++-v3/src/strst!
ream.cc -DPIC -o .libs/strstream.o
/vol/gcc/src/gcc-dist/libstdc++-v3/src/strstream.cc: In member function 'void
std::ostrstream::_ZTv0_n24_NSt10ostrstreamD0Ev()':
/vol/gcc/src/gcc-dist/libstdc++-v3/src/strstream.cc:419: internal compiler
error: Segmentation fault
Running cc1plus on strstream.ii under gdb reveals:
virtual std::strstream::~strstream()
Program received signal SIGSEGV, Segmentation fault.
alpha_end_function (file=0x300408000f8, fnname=0xe337c0
"_ZTv0_n24_NSt9strstreamD0Ev", decl=0xe8cc30) at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.c:8216
(gdb) where
#0 alpha_end_function (file=0x300408000f8, fnname=0xe337c0
"_ZTv0_n24_NSt9strstreamD0Ev", decl=0xe8cc30) at
/vol/gcc/src/gcc-dist/gcc/config/alpha/alpha.c:8216
#1 0x0001203c9450 in assemble_end_function (decl=0xe8cc30,
fnname=0x14003e900 "") at /vol/gcc/src/gcc-dist/gcc/varasm.c:1775
#2 0x0001201f3e70 in use_thunk (thunk_fndecl=0xe8cc30, emit_p=64 '@') at
/vol/gcc/src/gcc-dist/gcc/cp/method.c:446
#3 0x000120202914 in emit_associated_thunks (fn=0x1402f3a60) at
/vol/gcc/src/gcc-dist/gcc/cp/semantics.c:3144
#4 0x00012047ca98 in cgraph_expand_function (node=0x10d2800) at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1147
#5 0x00012048041c in cgraph_optimize () at
/vol/gcc/src/gcc-dist/gcc/cgraphunit.c:1211
#6 0x000120170564 in cp_write_global_declarations () at
/vol/gcc/src/gcc-dist/gcc/cp/decl2.c:3524
#7 0x0001204a1e3c in toplev_main (argc=1073993808, argv=0x140042f00) at
/vol/gcc/src/gcc-dist/gcc/toplev.c:976
#8 0x0001202c9b98 in main (argc=1082130680, argv=0xe337c0) at
/vol/gcc/src/gcc-dist/gcc/main.c:35
void
alpha_end_function (FILE *file, const char *fnname, tree decl ATTRIBUTE_UNUSED)
{
rtx insn;
/* We output a nop after noreturn calls at the very end of the function to
ensure that the return address always remains in the caller's code range,
as not doing so might confuse unwinding engines. */
insn = get_last_insn ();
if (!INSN_P (insn))
insn = prev_active_insn (insn);
insn is NULL at INSN_P (insn).
A reghunt reveals that this patch is the culprit:
2008-04-01 Jan Hubicka <[EMAIL PROTECTED]>
* function.c (free_after_compilation): Free epilogue_delay_list.
(prepare_function_start): Assert that previous compilation was freed.
Jan, would you please have a look?
Rainer
--
Summary: [4.4 regression] cc1plus SEGV compiling strstream.cc on
Tru64 UNIX
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: hubicka at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
GCC build triplet: alpha-dec-osf5.1b
GCC host triplet: alpha-dec-osf5.1b
GCC target triplet: alpha-dec-osf5.1b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36851
[Bug web/36850] New: missing onlinedocs for 4.3.1
http://gcc.gnu.org/onlinedocs/ only carries docs for 4.3.0 but not for the current 4.3.1-release. Generating the onlinedocs is rumored to be the person's duty who rolled the release (apparently jakub for 4.3.1). -- Summary: missing onlinedocs for 4.3.1 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36850
[Bug c++/36407] [4.3/4.4 regression] ICE with conversion and -fpermissive
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-16 15:02 --- Reproced on trunk. I'd like to look into this bug, if nobody is working on it already. -- 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|NEW |ASSIGNED Last reconfirmed|2008-06-01 21:16:43 |2008-07-16 15:02:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407
[Bug libfortran/36657] Namelist reading bug with string constant immediately followed by comment
--- Comment #8 from aldot at gcc dot gnu dot org 2008-07-16 14:35 --- The target milestone does not matter in this case. The fix will be in the next 4.3.x release which will be 4.3.2, from the looks. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.3 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36657
[Bug libfortran/36546] Namelist error with tab following a comma and newline
--- Comment #10 from aldot at gcc dot gnu dot org 2008-07-16 14:33 --- Will be in the next 4.3.x release which will be 4.3.2, from the looks. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.3 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36546
[Bug libfortran/36657] Namelist reading bug with string constant immediately followed by comment
--- Comment #7 from cnstar9988 at gmail dot com 2008-07-16 14:24 --- Target Milestone is 4.3.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36657
[Bug libfortran/36546] Namelist error with tab following a comma and newline
--- Comment #9 from cnstar9988 at gmail dot com 2008-07-16 14:24 --- Target Milestone is 4.3.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36546
[Bug bootstrap/36831] sparc-sun-solaris2.6: Bootstrap comparison failure
--- Comment #3 from mmokrejs at ribosome dot natur dot cuni dot cz 2008-07-16 13:59 --- This gave me a working bootstrapped compiler: AS=/usr/ccs/bin/as LD=/usr/ccs/bin/ld NM=/usr/local/bin/nm RANLIB=/usr/local/bin/ranlib STRIP=/usr/local/bin/strip BOOT_CFLAGS="-pipe -fno-strict-aliasing -mcpu=ultrasparc -mtune=ultrasparc" CFLAGS="-pipe -fno-strict-aliasing -mcpu=ultrasparc -mtune=ultrasparc" ../configure --disable-nls --with-mpfr=/usr/local --with-gmp=/usr/local --with-cpu=ultrasparc --with-tune=ultrasparc --enable-languages=c,c++,fortran,objc --enable-obsolete --without-gnu-ld --without-gnu-as --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld; AR=/usr/local/bin/ar AS=/usr/ccs/bin/as LD=/usr/ccs/bin/ld NM=/usr/local/bin/nm RANLIB=/usr/local/bin/ranlib STRIP=/usr/local/bin/strip BOOT_CFLAGS="-pipe -fno-strict-aliasing -mcpu=ultrasparc -mtune=ultrasparc" make bootstrap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36831
[Bug c++/13699] Extern "C" routine in different namespaces accepted with different exception signature
--- Comment #6 from dodji at gcc dot gnu dot org 2008-07-16 13:39 --- Created an attachment (id=15916) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15916&action=view) more work in the matter This patch performs a more accurate lookup of the extern C functions to be able to emit pedwarnings on redeclarations that don't comply with exception specification constraints. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #15911|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13699
[Bug tree-optimization/36835] Trunk 137774 miscompile cpu2006.473.astar
--- Comment #1 from Joey dot ye at intel dot com 2008-07-16 13:14 --- Fixed by revision 137859 -- Joey dot ye at intel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36835
[Bug middle-end/36849] New: IMA rejects to merge (function)decls with va_args
$ cat > m.h <<-EOF
typedef long unsigned int size_t;
#define __THROW
/* Remap pages mapped by the range [ADDR,ADDR+OLD_LEN) to new length
NEW_LEN. If MREMAP_MAYMOVE is set in FLAGS the returned address
may differ from ADDR. If MREMAP_FIXED is set in FLAGS the function
takes another paramter which is a fixed address at which the block
resides after a successful call. */
extern void *mremap (void *__addr, size_t __old_len, size_t __new_len,
int __flags, ...) __THROW;
EOF
$ cat >m.c<<-EOF
#define mremap _hidemremap
#include "m.h"
#undef mremap
/* normally the syscall is here */
void *mremap(void *addr, size_t osz, size_t nsz, int fl, void *ptr){return
(void*)0;}
EOF
$ cat >m_user.c<<-EOF
#include "m.h"
void *user(void)
{
return mremap((char*)0, 0, 0, 0);
}
EOF
$ gcc-4.4-HEAD -c -combine m.c m_user.c
In file included from m_user.c:1:
m.h:9: error: conflicting types for mremap
m.c:5: error: previous definition of mremap was here
Ideally the __VA_ARGS__ would be dealt with as "any or none" param decl, so the
function(s) above would be considered equal.
--
Summary: IMA rejects to merge (function)decls with va_args
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aldot at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36849
[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106
--- Comment #15 from aldot at gcc dot gnu dot org 2008-07-16 12:48 --- Fixed on trunk, thanks! Can we have the testcase in the testsuite and the fix applied to the 4_3-branch, too? -- aldot at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Known to fail||4.3.1 Known to work||4.4.0 Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28779
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #10 from jsm28 at gcc dot gnu dot org 2008-07-16 10:47 --- Subject: Bug 36827 Author: jsm28 Date: Wed Jul 16 10:46:32 2008 New Revision: 137876 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137876 Log: PR target/36827 * config/m32c/m32c.c (BIG_FB_ADJ): Move definition earlier. (m32c_legitimate_address_p): Handle "++rii" addresses created by m32c_legitimize_reload_address. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/m32c/m32c.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug target/36827] [4.3/4.4 Regression] newlib:libm/math/k_rem_pio2.c fails in reload
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-07-16 10:46 --- Subject: Bug 36827 Author: jsm28 Date: Wed Jul 16 10:45:57 2008 New Revision: 137875 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137875 Log: PR target/36827 * config/m32c/m32c.c (BIG_FB_ADJ): Move definition earlier. (m32c_legitimate_address_p): Handle "++rii" addresses created by m32c_legitimize_reload_address. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32c/m32c.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36827
[Bug tree-optimization/36830] [4.4 Regression] STORAGE_ERROR raised compiling s-os_lib.adb
--- Comment #2 from andreasmeier80 at gmx dot de 2008-07-16 09:52 --- For me it was working in revision 137687 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36830
