[Bug fortran/36492] incorrect error when compiling
--- Comment #9 from domob at gcc dot gnu dot org 2008-06-21 07:59 --- (In reply to comment #8) I just downloaded the latest trunk version, which is GNU Fortran (GCC) 4.4.0 20080616 (experimental) [trunk revision 136838] Copyright (C) 2008 Free Software Foundation, Inc. I committed my patch as rev 136894, so that might be the cause. Otherwise it could be a problem with 64 bit although I can't imagine that; if so, I'd be happy to rework the fix. Daniel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-21 08:32 --- I am not sure what is meant by regression. Regression means that it used to work in a previous version of gfortran and someone managed to break it. This is especially bad as code which worked before then stops working. This is the reason why all Priority 1 (and possibly P2) regressions need to be fixed or downgraded before any new GCC release is done. Regressions are also the only bugs which may be fixed for minor releases (e.g. for the next 4.3.x version), though exceptions are made for serious bugs especially if the fix is algorithmically simple. (Otherwise not as by fixing one thing, one might create another bug - a regression.) Am I correct in assuming that you do not regard it as an error? No, if it is valid (ISO standard) Fortran then we definitely want to fix it. (If it is a vendor extension, we only might fix it.) In your case it seems to be valid Fortran and I believe it will be fixed soonish, though possibly only for GCC 4.4.0 and not for 4.3.2 [or 4.2.x]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug fortran/36492] incorrect error when compiling
--- Comment #10 from burnus at gcc dot gnu dot org 2008-06-21 08:43 --- I just downloaded the latest trunk version, which is GNU Fortran (GCC) 4.4.0 20080616 (experimental) [trunk revision 136838] Copyright (C) 2008 Free Software Foundation, Inc. Somehow my x86-64-linux build server failed to create a newer 4.4.0 version after the 20080616. It should be fixed now and in a few hours today's build should be available. Sorry for the failure and thanks for finding the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36492
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #7 from fmuldoo at me dot lsu dot edu 2008-06-21 08:47 --- Subject: Re: Namelist I/O error: Bogus Cannot match namelist object Hello Burnus, Thanks for explaining that to me. It is clear now. Regards, Frank On Sat, 2008-06-21 at 08:32 +, burnus at gcc dot gnu dot org wrote: --- Comment #6 from burnus at gcc dot gnu dot org 2008-06-21 08:32 --- I am not sure what is meant by regression. Regression means that it used to work in a previous version of gfortran and someone managed to break it. This is especially bad as code which worked before then stops working. This is the reason why all Priority 1 (and possibly P2) regressions need to be fixed or downgraded before any new GCC release is done. Regressions are also the only bugs which may be fixed for minor releases (e.g. for the next 4.3.x version), though exceptions are made for serious bugs especially if the fix is algorithmically simple. (Otherwise not as by fixing one thing, one might create another bug - a regression.) Am I correct in assuming that you do not regard it as an error? No, if it is valid (ISO standard) Fortran then we definitely want to fix it. (If it is a vendor extension, we only might fix it.) In your case it seems to be valid Fortran and I believe it will be fixed soonish, though possibly only for GCC 4.4.0 and not for 4.3.2 [or 4.2.x]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug c++/36576] gcc 4.3.1 doesn't build for me on openSUSE 10.3
--- Comment #14 from karx11erx at hotmail dot com 2008-06-21 08:57 ---
(In reply to comment #13)
think of:
templateclass T struct CBaseT
{
protected:
T *i;
};
template struct CBaseint
{
protected: typedef int i;
};
templateclass T struct CDerived : public CBaseT
{
inline T* foo (void) { return const_cast T* i; }
}
What happens then?
That was not the code, and is not contained anywhere in that code. Your case
seems totally theoretical and constructed, rather like look what crazy things
could be done with templates! To be honest, while I have some basic
understanding of templates and healthy applications for them, I don't even
understand template struct CBaseint and wonder why one would declare a
type inside of it. But anyway, as the required changes are ISO conformant, our
source code will be changed accordingly (and I won't have to do it, hah).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36576
[Bug fortran/36276] [4.3 Regression] possible issue with opening fortran files?
--- Comment #9 from burnus at gcc dot gnu dot org 2008-06-21 10:02 --- Fixed on the trunk, leave open for 4.3.x. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch Summary|[4.3/4.4 Regression]|[4.3 Regression] possible |possible issue with opening |issue with opening fortran |fortran files? |files? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug debug/34908] valgrind error indication from testsuite hashtab.c : htab_hash_string
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-21 10:04 --- Close as FIXED (on the trunk/4.4). For follow up, see PR 36342 (for fixing 4.3) and PR 36276. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34908
[Bug c/36588] New: Request warnings about the precedence of the unary - over the binary * and /
The problem: it is too easy to write incorrect code with the unary -, e.g.
- i / 2 (which means (- i) / 2)
when one really wants - (i / 2). The reasons are:
1. Whereas the binary - has a lower precedence than the binary * (multiply)
and / (divide), the unary - has a higher precedence. It is easy to forget
this difference, in particular because the same symbol is used with two
different precedences. For instance, the expressions 0 - i / 2 and - i / 2
look the same, but the former corresponds to 0 - (i / 2) and the latter
corresponds to (- i) / 2.
2. Mathematically (in a ring), the precedence of the unary - (for the
opposite) vs * (multiply) does not matter since the result does not depend on
the precedence, so that it is never explicited in practice and what the writer
of a math expression really thinks depends on the context.
The following code shows such a problem that can occur in practice: the unary
- in k = - i / 2 yields an integer overflow, hence undefined behavior. The
user may not be aware of it. And the fact that this bug is hidden with -O2
optimizations makes it worse. For instance, when compiling this code without
optimizations, I get:
j = 1073741824
k = -1073741824
(which is not the intended result). With -O2 optimizations, I get:
j = 1073741824
k = 1073741824
Adding the following warnings could avoid bugs like this one:
warning: suggest parentheses around unary - in operand of *
warning: suggest parentheses around unary - in operand of /
Note: such warnings should also apply to floating-point expressions as they can
be affected in the rounding directions FE_DOWNWARD and FE_UPWARD.
#include stdio.h
#include limits.h
int main (void)
{
int i, j, k;
i = INT_MIN;
j = 0 - i / 2;
k = - i / 2;
printf (j = %d\n, j);
printf (k = %d\n, k);
return 0;
}
--
Summary: Request warnings about the precedence of the unary -
over the binary * and /
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36588
[Bug libstdc++/17995] gcc-3.4.2/libstdc++-v3/libsupc++/eh_alloc.cc:34
--- Comment #11 from paolo dot carlini at oracle dot com 2008-06-21 11:50 --- Close, close. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17995
[Bug target/36584] [4.3/4.4 Regression] Stack is not aligned correctly in recursive function
--- Comment #2 from ubizjak at gmail dot com 2008-06-21 13:25 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg01361.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-21 13:25:05 date|| Summary|Stack is not aligned|[4.3/4.4 Regression] Stack |correctly in recursive |is not aligned correctly in |function|recursive function Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug debug/36589] New: [4.4 Regression]: gcc.dg/debug/dwarf2/var1.c scan-assembler xyzzy[^\\\\n\\\\r]+DW_AT_name
Revision 136903: http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01170.html breaks DWARF at -O0: FAIL: gcc.dg/debug/dwarf2/var1.c scan-assembler xyzzy[^nr]+DW_AT_name -- Summary: [4.4 Regression]: gcc.dg/debug/dwarf2/var1.c scan- assembler xyzzy[^nr]+DW_AT_name Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug 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=36589
[Bug fortran/36276] [4.3 Regression] possible issue with opening fortran files?
--- Comment #10 from lauras at gcc dot gnu dot org 2008-06-21 15:30 --- Subject: Bug 36276 Author: lauras Date: Sat Jun 21 15:29:44 2008 New Revision: 137001 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137001 Log: 2008-06-20 Laurynas Biveinis [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/34908 PR fortran/36276 * scanner.c (preprocessor_line): do not call gfc_free for current_file-filename if it differs from filename. Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug debug/34908] valgrind error indication from testsuite hashtab.c : htab_hash_string
--- Comment #4 from lauras at gcc dot gnu dot org 2008-06-21 15:30 --- Subject: Bug 34908 Author: lauras Date: Sat Jun 21 15:29:44 2008 New Revision: 137001 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137001 Log: 2008-06-20 Laurynas Biveinis [EMAIL PROTECTED] Tobias Burnus [EMAIL PROTECTED] PR fortran/34908 PR fortran/36276 * scanner.c (preprocessor_line): do not call gfc_free for current_file-filename if it differs from filename. Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34908
[Bug debug/36589] [4.4 Regression]: No debug info for local static variable at -O0
--- Comment #1 from hjl dot tools at gmail dot com 2008-06-21 15:49 --- varpool_output_debug_info has /* Local static variables are never seen by check_global_declarations so we need to output debug info by hand. */ if (DECL_CONTEXT (node-decl) (TREE_CODE (DECL_CONTEXT (node-decl)) == BLOCK || TREE_CODE (DECL_CONTEXT (node-decl)) == FUNCTION_DECL) errorcount == 0 sorrycount == 0) (*debug_hooks-global_decl) (node-decl); This is no longer called with -O0. Should cgraph_output_in_order handle local static variable? Index: cgraphunit.c === --- cgraphunit.c(revision 136905) +++ cgraphunit.c(working copy) @@ -1303,7 +1303,15 @@ cgraph_output_in_order (void) break; case ORDER_VAR: - varpool_assemble_decl (nodes[i].u.v); + pv = nodes[i].u.v; + varpool_assemble_decl (pv); + /* Since check_global_declarations never sees local static +variables, we need to output debug info by hand. */ + if (DECL_CONTEXT (pv-decl) +(TREE_CODE (DECL_CONTEXT (pv-decl)) == BLOCK + || (TREE_CODE (DECL_CONTEXT (pv-decl)) + == FUNCTION_DECL))) +(*debug_hooks-global_decl) (pv-decl); break; case ORDER_ASM: -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression]: |[4.4 Regression]: No debug |gcc.dg/debug/dwarf2/var1.c |info for local static |scan-assembler |variable at -O0 |xyzzy[^nr]+DW_AT_nam| |e | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36589
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #25 from ubizjak at gmail dot com 2008-06-21 15:49 --- The testcase at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html will fail for -mfpmath=sse on x86_32. Related PR is PR 36584. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug target/36584] [4.3/4.4 Regression] Stack is not aligned correctly in recursive function
--- Comment #3 from hjl dot tools at gmail dot com 2008-06-21 16:00 --- *** Bug 35271 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||tege-gcc at swox dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #26 from hjl dot tools at gmail dot com 2008-06-21 16:00 --- I am closing it as an dup for PR 36584. Please reoopen it if it isn't fixed after http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html is checked in. *** This bug has been marked as a duplicate of 36584 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug middle-end/36548] remainder gives the wrong result for wrapping case with unsigned types
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-21 16:20 --- Hm, but multiplication overflow behaves sane. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36548
[Bug fortran/36590] New: internal error
Hello, The build of my program terminates on file mtfcontrolargsM.f90, and I see the following message: mtfcontrolargsM.f90:805.25: end module MTFControlArgs 1 Internal Error at (1): mtfcontrolargsM.f90:631.32: This % NLam = count (.not. Near0 (This % PolyMTFWeight(1: NO_MTF_WAVES))) 1 Can't convert LOGICAL(1) to LOGICAL(1) at (1) As soon as I am assigned a bug number, I will upload a tar file, bug3.tgz to the following address: [EMAIL PROTECTED] Unpack the file and invoke the shell script bug3.sh to reproduce the problem. I'll indicate the bug number in the subject line. I am running Open SuSE 10.1 on a dual core Athlon chip. I'm using the gcc-trunk build: [EMAIL PROTECTED]:~/design/gfortran/bug3/test gfortran --version GNU Fortran (GCC) 4.4.0 20080621 (experimental) [trunk revision 137000] Copyright (C) 2008 Free Software Foundation, Inc. I am not able to reduce the size of the problem. Yours truly, Norm Clerman -- Summary: internal error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: clerman at fuse dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36590
[Bug tree-optimization/36561] store using long array index not hoisted out of loop
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-21 16:22 --- Confirmed. See also related XFAILs on LP64 targets. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias, missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-06-21 16:22:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36561
[Bug fortran/36590] internal error
--- Comment #1 from clerman at fuse dot net 2008-06-21 16:28 --- Subject: gfortran bug 36590 Hello, Attached is the zipped tar archive that will enable you to reproduce gfortran bug 36590. Unpack the archive in a directory and then invoke file bug3.sh to reproduce it. If there are any problems or questions, do not hesitate to send me an e-mail Thank you for your attention. Norm Clerman --- Comment #2 from clerman at fuse dot net 2008-06-21 16:28 --- Created an attachment (id=15799) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15799action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36590
[Bug c++/36565] Wrong code generation with -O2 and segfault with -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-21 16:31 --- sth strange, also segfaults at -O3 with 4.1, 4.2 and 4.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36565
[Bug ada/36575] [4.3/4.4 Regression][Ada] ACATS c460011 runtime fails at -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-21 16:33 --- I would bet this is VRP triggered by more inlining. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36575
[Bug pch/34909] valgrind error indication from testsuite c-pch.c: c_common_write_pch
--- Comment #2 from laurynas dot biveinis at gmail dot com 2008-06-21 16:38 --- Confirmed with r137000 with a different valgrind backtrace: [EMAIL PROTECTED]:~/src/gcc-trunk/gcc/gcc/testsuite/objc.dg/pch$ valgrind /home/lauris/src/gcc-trunk/obj/gcc/cc1obj -quiet -I/home/lauris/src/gcc-trunk/gcc/gcc/testsuite/../../libobjc -iprefix /home/lauris/src/gcc-trunk/obj/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/ -isystem /home/lauris/src/gcc-trunk/obj/gcc/include -isystem /home/lauris/src/gcc-trunk/obj/gcc/include-fixed ./interface-1.h -quiet -dumpbase interface-1.h -mtune=generic -auxbase interface-1 -g -O0 -o /tmp/cc8Pabsb.s --output-pch= interface-1.h.gch ==12173== Memcheck, a memory error detector. ==12173== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==12173== Using LibVEX rev 1804, a library for dynamic binary translation. ==12173== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==12173== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==12173== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==12173== For more details, rerun with: -v ==12173== ==12173== Syscall param write(buf) points to uninitialised byte(s) ==12173==at 0x5370BB0: __write_nocancel (in /usr/lib/debug/libc-2.7.so) ==12173==by 0x5314CE2: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1266) ==12173==by 0x5314BC3: _IO_do_write@@GLIBC_2.2.5 (fileops.c:520) ==12173==by 0x531610C: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1348) ==12173==by 0x5314190: fwrite_unlocked (iofwrite_u.c:47) ==12173==by 0xB258E3: write_macdef (pch.c:80) ==12173==by 0xB25E40: ht_forall (symtab.c:235) ==12173==by 0xB2576A: cpp_save_state (pch.c:202) ==12173==by 0x48A951: pch_init (c-pch.c:166) ==12173==by 0x47E8AD: c_common_parse_file (c-opts.c:1261) ==12173==by 0x6E8F71: toplev_main (toplev.c:965) ==12173==by 0x52C51C3: (below main) (libc-start.c:220) ==12173== Address 0x418701b is not stack'd, malloc'd or (recently) free'd ==12173== ==12173== Syscall param write(buf) points to uninitialised byte(s) ==12173==at 0x5370BB0: __write_nocancel (in /usr/lib/debug/libc-2.7.so) ==12173==by 0x5314CE2: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1266) ==12173==by 0x5314BC3: _IO_do_write@@GLIBC_2.2.5 (fileops.c:520) ==12173==by 0x5316908: _IO_switch_to_get_mode (genops.c:189) ==12173==by 0x5314EF7: _IO_file_seekoff@@GLIBC_2.2.5 (fileops.c:976) ==12173==by 0x5311E79: fseek (fseek.c:41) ==12173==by 0x4ABFC3: ggc_pch_write_object (ggc-page.c:2205) ==12173==by 0x5FC666: gt_pch_save (ggc-common.c:515) ==12173==by 0x48A66F: c_common_write_pch (c-pch.c:212) ==12173==by 0x47E8C4: c_common_parse_file (c-opts.c:1265) ==12173==by 0x6E8F71: toplev_main (toplev.c:965) ==12173==by 0x52C51C3: (below main) (libc-start.c:220) ==12173== Address 0x418724c is not stack'd, malloc'd or (recently) free'd ==12173== ==12173== ERROR SUMMARY: 13 errors from 2 contexts (suppressed: 8 from 1) ==12173== malloc/free: in use at exit: 492,967 bytes in 1,518 blocks. ==12173== malloc/free: 15,936 allocs, 14,418 frees, 2,778,332 bytes allocated. ==12173== For counts of detected errors, rerun with: -v ==12173== searching for pointers to 1,518 not-freed blocks. ==12173== checked 3,563,304 bytes. ==12173== ==12173== LEAK SUMMARY: ==12173==definitely lost: 152,024 bytes in 289 blocks. ==12173== possibly lost: 0 bytes in 0 blocks. ==12173==still reachable: 340,943 bytes in 1,229 blocks. ==12173== suppressed: 0 bytes in 0 blocks. ==12173== Rerun with --leak-check=full to see details of leaked memory. -- laurynas dot biveinis at gmail dot com changed: What|Removed |Added CC||laurynas dot biveinis at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34909
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-06-21 16:38 --- Status: I have started investigating this bug. It is not typical in the sense that the last several namelist bugs involved parsing and whitespace issues. With this bug, we appear to end up with a namelist object whose name is '\0'. I am only just getting started, so more later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug middle-end/36578] cast to long double not taken into account when result stored to a double
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-21 16:41 ---
Testcase
double foo (double x, double y)
{
return (long double)x * (long double)y;
}
where we fold the multiplication to x * y. This is only ok with
-funsafe-math-optimizations (like any other conversions removing
FP operations). It is of course also ok if we for some reason
know that x * y is exactly representable in both double and
long double.
It is convert_to_real doing this optimization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2008-06-21 16:41:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578
[Bug c++/36565] Wrong code generation with -O2 and segfault with -O3
--- Comment #2 from rlblaster at gmail dot com 2008-06-21 16:45 --- Ah, sorry, my bad. I was overindexing at the line of arr[i] = prefix_sz % 5; The behaviour just seemed too odd to me. Sorry for the inconvenience! -- rlblaster at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36565
[Bug ada/36591] New: error: a-reatim.adb must be compiled
I am seeing quite a few errors in the acats testsuite with the following errors: BUILD a83a02b.adb gnatmake --GCC=/xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/xxx/gnu/gcc/objdir/gcc/testsuite/ada/acats/support a83a02b.adb -largs -- GCC=/xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc//xxx/gnu/gcc/objdir/gcc/xgcc -c -B/xxx/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/xxx/gnu/gcc/objdir/gcc/testsuite/ada/acats/support a83a02b.adb gnatbind -I/xxx/gnu/gcc/objdir/gcc/testsuite/ada/acats/support -x a83a02b.alierror: a-reatim.adb must be compiled error: (/xxx/gnu/gcc/objdir/gcc/ada/rts/a-reatim.ali is obsolete and read-only )error: s-inmaop.adb must be compiled error: (/xxx/gnu/gcc/objdir/gcc/ada/rts/s-inmaop.ali is obsolete and read-only ) gnatmake: *** bind failed. FAIL: a83a02b -- Summary: error: a-reatim.adb must be compiled Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36591
[Bug middle-end/36578] cast to long double not taken into account when result stored to a double
--- Comment #3 from joseph at codesourcery dot com 2008-06-21 16:58 --- Subject: Re: cast to long double not taken into account when result stored to a double On Sat, 21 Jun 2008, rguenth at gcc dot gnu dot org wrote: It is convert_to_real doing this optimization. convert_to_real is also responsible for the problematic conversions in bug 35202. I didn't try to argue the double rounding issues for those conversions, only the errno issue, since I don't have an example for the double rounding affecting those function call conversions (and right now implementations of many of the functions will not typically be correctly rounding - but that could change if C1x follows the new IEEE 754 revision's recommendation of many more correctly rounded functions). But it is potentially an issue for the conversions of function calls as well as the plain arithmetic example of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578
Re: [Bug ada/36591] New: error: a-reatim.adb must be compiled
I am seeing quite a few errors in the acats testsuite with the following errors: Most likely, your Ada run-time has not been rebuilt since your last incremental build. I'd suggest either redoing a build from scratch, or at least removing the target/libada/stamp-libada and gcc/stamp-* files and redoing a make. Arno
[Bug ada/36591] error: a-reatim.adb must be compiled
--- Comment #1 from charlet at adacore dot com 2008-06-21 17:08 --- Subject: Re: New: error: a-reatim.adb must be compiled I am seeing quite a few errors in the acats testsuite with the following errors: Most likely, your Ada run-time has not been rebuilt since your last incremental build. I'd suggest either redoing a build from scratch, or at least removing the target/libada/stamp-libada and gcc/stamp-* files and redoing a make. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36591
[Bug middle-end/34905] valgrind error indication from testsuite typeck.c:comptypes
--- Comment #2 from laurynas dot biveinis at gmail dot com 2008-06-21 17:12 --- Valgrind output is clean with r137000. -- laurynas dot biveinis at gmail dot com changed: What|Removed |Added CC||laurynas dot biveinis at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34905
[Bug ada/36591] error: a-reatim.adb must be compiled
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-21 17:20 --- Subject: Re: error: a-reatim.adb must be compiled Most likely, your Ada run-time has not been rebuilt since your last incremental build. I did apply the patch to s-osinte-hpux-dce.ads mid-build. Possibly, that is the cause. I'd suggest either redoing a build from scratch, or at least removing the target/libada/stamp-libada and gcc/stamp-* files and redoing a make. Since a complete rebuild from scratch takes quite a bit of time, I'll give this a try when the current check completes. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36591
[Bug middle-end/34906] valgrind error indication from testsuite gimplify.c: gimplify_asm_expr
--- Comment #2 from laurynas dot biveinis at gmail dot com 2008-06-21
17:40 ---
Reproduced with r137000.
Basically we have:
gimplify_asm_expr(...)
{
...
bool is_inout;
...
for (...)
{
parse_output_constraint (is_inout);
if (is_inout)
{
...
Now the problem is that parse_output_constraint reports an error and exits
early, before setting is_inout value.
--
laurynas dot biveinis at gmail dot com changed:
What|Removed |Added
CC||laurynas dot biveinis at
||gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
[Bug pch/34909] valgrind error indication from testsuite c-pch.c: c_common_write_pch
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-21 18:21 --- c_common_write_pch walks all GC allocated memory. Of course sth could be uninitialized there. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34909
[Bug fortran/36590] internal error
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-06-21 19:26 --- I have not confirmed this but its not a blocker. Next step will be to see if someone can reduce this. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36590
[Bug fortran/36592] New: F2003: Procedure pointer in COMMON
Procedure pointers in COMMON are currently rejected (gfc_error), but they are valid and should thus be supported. 5.5.2 COMMON statement R558 common-block-object is variable-name [ ( explicit-shape-spec-list ) ] or proc-pointer-name Test program (hopefully correct): subroutine one() implicit none integer :: a,b procedure(real), pointer :: p common /com/ a,b if(a /= 5 .or. b /= -9) call abort() if(p(0.0)/= 1.0) call abort end subroutine one program main implicit none integer x integer y intrinsic cos external func1 pointer func1 procedure(real), pointer :: func2 common /com/ x,func1,y,func2 x = 5 y = -9 func1 = cos func2 = cos call one() end program main First patch: --- symbol.c(revision 136801) +++ symbol.c(working copy) @@ -1114,7 +1131,7 @@ gfc_add_in_common (symbol_attribute *att if (check_conflict (attr, name, where) == FAILURE) return FAILURE; - if (attr-flavor == FL_VARIABLE) + if (attr-flavor == FL_VARIABLE || attr-proc_pointer) return SUCCESS; return gfc_add_flavor (attr, FL_VARIABLE, name, where); Actually, there is probably the following missing as well: || (attr-pointer attr-external attr-if_source != IFSRC_IFBODY) But this is not enough and produces tons of ICEs. -- Summary: F2003: Procedure pointer in COMMON Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org BugsThisDependsOn: 32580 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug fortran/36590] internal error
--- Comment #4 from burnus at gcc dot gnu dot org 2008-06-21 20:16 --- CONFIRM. Reduced test case: MODULE MTFControlArgs TYPE, PUBLIC :: TMTFControlArgs Real(8) :: PolyMTFWeight (1:10) end type TMTFControlArgs interface Near0 elemental function Near0_dp (TestNumber) result (NumberNear0) real (8), intent(in) :: TestNumber logical (1) :: NumberNear0 end function Near0_dp elemental function Near0_sp (TestNumber) result (NumberNear0) real (4), intent(in) :: TestNumber logical (1) :: NumberNear0 end function Near0_sp end interface contains subroutine getSpc_MTFCA (This) type (TMTFControlArgs), intent(inout) :: This integer(1) :: i i = count (.not. Near0 (This % PolyMTFWeight(1: 10))) end subroutine GetSpc_MTFCA end module MTFControlArgs -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-21 20:17:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36590
[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-06-21 20:57 --- Also fixed on the 4.3 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.0 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35336
[Bug debug/34908] valgrind error indication from testsuite hashtab.c : htab_hash_string
-- lauras at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34908
[Bug fortran/36276] [4.3 Regression] possible issue with opening fortran files?
--- Comment #11 from lauras at gcc dot gnu dot org 2008-06-21 21:40 --- Closing the bug as the fix has been commited to the 4.3 branch too -- lauras at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #112 from pepalogik at seznam dot cz 2008-06-21 22:38 --- (In reply to comment #111) Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard, which *allows* extended precision, and double precision is *available*. It's true that double *precision* is available on x87. But not the *IEEE-754 double precision type*. Beside the precision of mantissa, this includes also the range of exponent. On the x87, it is possible to set the precision of mantissa but not the range of exponent. That's why I believe it doesn't obey the IEEE. (I haven't ever seen the IEEE-754 standard but I base on the work of David Monniaux.) Note: the solution chosen by some OS'es (*BSD, MS-Windows...) is to configure the processor to the IEEE double precision by default (thus long double is also in double precision, but this is OK as far as the C language is concerned, there's still a problem with float, but in practice, nobody cares AFAIK). Do you mean that on Windows, long double has (by default) no more precision than double? I don't think so (it's confirmed by my experience). According to the paper of David Monniaux, only FreeBSD 4 sets double precision by default (but I know almost nothing about BSD). (1) A very simple solution: Use long double everywhere. This avoids the bug, but this is not possible for software that requires double precision exactly, e.g. XML tools that use XPath. Yes, of course. I don't say this can be used everywhere. (But be careful when transfering binary data in long double format between computers because this format is not standardized and so the concrete bit representations vary between different CPU architectures.) Well, this is not specific to long double anyway: there exist 3 possible endianess for the double format (x86, PowerPC, ARM). OK but David Monniaux mentions portability issues just in the case of long double, so the differences are probably more frequent in this case (maybe even within the x86 architecture). Yes, but note that this is not the only problem with compilers. See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578 Thanks for info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #113 from vincent at vinc17 dot org 2008-06-22 00:52 --- (In reply to comment #112) It's true that double *precision* is available on x87. But not the *IEEE-754 double precision type*. It is available when storing a result to memory. Beside the precision of mantissa, this includes also the range of exponent. On the x87, it is possible to set the precision of mantissa but not the range of exponent. The IEEE754-1985 allows this. Section 4.3: Normally, a result is rounded to the precision of its destination. However, some systems deliver results only to double or extended destinations. On such a system the user, which may be a high-level language compiler, shall be able to specify that a result be rounded instead to single precision, though it may be stored in the double or extended format with its wider exponent range. [...] That's why I believe it doesn't obey the IEEE. (I haven't ever seen the IEEE-754 standard but I base on the work of David Monniaux.) See above. Also beware of subtilities in the wording used by David Monniaux. FYI, the IEEE754-1985 standard (with minor corrections) is available from the following page: http://www.validlab.com/754R/ (look at the end). AFAIK, the IEEE754-1985 standard was designed from the x87 implementation, so it would have been very surprising that x87 didn't conform to IEEE754-1985. Do you mean that on Windows, long double has (by default) no more precision than double? I don't think so (it's confirmed by my experience). I don't remember my original reference, but here's a new one: http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx In fact, this depends on the architecture. I quote: x86. Intermediate expressions are computed at the default 53-bit precision with an extended range provided by a 16-bit exponent. When these 53:16 values are spilled to memory (as can happen during a function call), the extended exponent range will be narrowed to 11-bits. That is, spilled values are cast to the standard double precision format with only an 11-bit exponent. A user may switch to extended 64-bit precision for intermediate rounding by altering the floating-point control word using _controlfp and by enabling FPU environment access (see The fpenv_access Pragma). However, when extended precision register-values are spilled to memory, the intermediate results will still be rounded to double precision. This particular semantic is subject to change. Note that the behavior has changed in some version of Windows (it was using the extended precision, then it switched to double precision for x86). Now, this may also depend on the compiler. According to the paper of David Monniaux, only FreeBSD 4 sets double precision by default (but I know almost nothing about BSD). I've noted that amongst the BSD's, NetBSD does this too (I don't remember if I've tried or got it from some document, and this might also depend on the NetBSD version and/or the processor). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug middle-end/36509] [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c
--- Comment #2 from hp at gcc dot gnu dot org 2008-06-22 02:26 --- Noticed on cris-axis-elf too, worked: r136685, known failing from: r136695 -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36509
[Bug middle-end/36593] New: [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc
With r136685, these tests passed. They are known to fail since r136695. Both seem to be related to formatting of floating point numbers; possibly a miscompilation of newlib. None of the libraries or front-ends had related changes in the svn range. The gfortran test fails at execution at all the torture options, calling abort for one of the subtests. The libstdc++ test fails with (copypasted): assertion d == d1 failed: file /tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/2.cc, line 101, function: void test02()^M program stopped with signal 6.^M I'll add an investigation from diffed disassembled executables and simulator traces. Author of suspect patches in this range CCed. -- Summary: [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593
[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-22 03:02:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593
[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc
-- hp at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-06-22 05:50
---
This patch fixes the test case and requires adjustment to namelist_40.f90 and
namelist_47.f90. I am not completely satisfied with this because it leaves us
a less informative error message in those two test cases. I will explore a bit
more.
Index: libgfortran/io/list_read.c
===
--- libgfortran/io/list_read.c (revision 136998)
+++ libgfortran/io/list_read.c (working copy)
@@ -2649,7 +2649,10 @@ get_name:
if (!is_separator (c))
push_char (dtp, tolower(c));
c = next_char (dtp);
-} while (!( c=='=' || c==' ' || c=='\t' || c =='(' || c =='%' ));
+} while (!( c=='=' || c==' ' || c=='\t' || c =='(' ));
+
+ if (c == '%')
+push_char (dtp, c);
unget_char (dtp, c);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
[Bug fortran/36582] Namelist I/O error: Bogus Cannot match namelist object
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-06-22 05:52
---
Correction, the IF clause is not relevant.
Index: libgfortran/io/list_read.c
===
--- libgfortran/io/list_read.c (revision 136998)
+++ libgfortran/io/list_read.c (working copy)
@@ -2649,7 +2649,7 @@ get_name:
if (!is_separator (c))
push_char (dtp, tolower(c));
c = next_char (dtp);
-} while (!( c=='=' || c==' ' || c=='\t' || c =='(' || c =='%' ));
+} while (!( c=='=' || c==' ' || c=='\t' || c =='(' ));
unget_char (dtp, c);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36582
