--- 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
--- 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
--- 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
--- 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
--- 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
{
--- 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
--- 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
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
--- 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
--- 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
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
--- 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]
--- 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]
--- 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)
--- 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
--- 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
--- 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 ***
--- 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
.
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
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
--- 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
--- 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
--- 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.
--- 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
--- 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
--- 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
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):
--- 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)
--- 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
--
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
--- 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
--- 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
--- 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,
--- 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
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
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
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
--- 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
--- 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)
+++
49 matches
Mail list logo
