--- Comment #3 from mikael at gcc dot gnu dot org 2010-09-03 19:45 ---
(In reply to comment #2)
Created an attachment (id=21687)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21687action=view) [edit]
Proposed patch
Patch to fix this. I wonder why it did not show up for me
--- Comment #4 from domob at gcc dot gnu dot org 2010-09-03 19:51 ---
Subject: Bug 45525
Author: domob
Date: Fri Sep 3 19:50:44 2010
New Revision: 163840
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163840
Log:
2010-09-03 Daniel Kraft d...@domob.eu
PR fortran/45525
--- Comment #10 from ubizjak at gmail dot com 2010-09-03 19:58 ---
Fixed for all targets that support __float128.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-03 20:04 ---
A related testcase where we fail to fold fundamentals[0]
typedef union tree_node *tree;
enum tree_code
{
OFFSET_TYPE, ENUMERAL_TYPE, BOOLEAN_TYPE, POINTER_TYPE, FIXED_POINT_TYPE,
};
struct tree_base
{
unsigned
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-09-03
20:06 ---
Looking at a build previous to r163815/r163816, I find that config.log has...
enable_decimal_float='no'
in the libgcc build subdirectories, but config.log shows...
enable_decimal_float='dpd'
everywhere
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-09-03 20:09 ---
And here we fail to fold messages[1] created by PRE
enum
{
ERROR_OK, ERROR_UNKNOWN,
ERROR_NUM
};
enum
{ __LC_CTYPE = 0, __LC_NUMERIC = 1, __LC_TIME = 2, __LC_COLLATE =
3, __LC_MONETARY = 4, __LC_MESSAGES =
When a variable length array is defined in a loop, a call of alloca() is
placed in the loop, and causes stack overflow.
I believe this shouldn't happen since The space for a variable-length
array is deallocated as soon as the array name's scope ends. (quote
from the doc)
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-03 20:12 ---
In testcase from comment #4 the problem is that value in DECL_INITIAL is not in
the form acceptable for gimple_min_invariant. Have patch.
In testcase from comment #5 we never try to fold it.
--
--- Comment #5 from domob at gcc dot gnu dot org 2010-09-03 20:20 ---
I guess we can close this now.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from k_satoda at f2 dot dion dot ne dot jp 2010-09-03 20:22
---
Sorry, I made a wrong test case. Will try another one.
--
k_satoda at f2 dot dion dot ne dot jp changed:
What|Removed |Added
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-09-03 20:28 ---
In #5 the expression is created by PRE via create_expression_by_pieces that
uses normal fold that is not able of constant variable folding. The statement
does not get folded later and survives. I guess one can fold
--- Comment #15 from vmakarov at redhat dot com 2010-09-03 20:45 ---
(In reply to comment #14)
Ulrih, I've just wanted to post the following when I found that you already
posted analogous conclusion. I should have been on CC to see your comment
right away. The problem is really
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-03 20:53 ---
I don't see anything confusing about it. If you have:
union { int a, b, c; } u;
u.a overlaps u.b and u.c as well, and the same applies to bitfields. union
isn't struct, see ISO C99 6.7.2.1/5. The standard is clear
--- Comment #12 from runipg at broadcom dot com 2010-09-03 21:12 ---
Subject: Re: Bug with anonymous unions and bit-fields
Okay, I guess I was confused by struct or union semantics. Thanks!
jakub at gcc dot gnu dot org wrote:
--- Comment #11 from jakub at gcc dot gnu dot org
When a variable length array is defined in a loop, and its size is
specified with a const variable, gcc -O3 (and -Os) produces a call of
alloca() without specifying the size argument (eax in my case). This
causes stack overflow.
$ cat test.c
int const n = 4096;
void g(int* p);
void f() { for(;;)
--- Comment #2 from k_satoda at f2 dot dion dot ne dot jp 2010-09-03 21:38
---
This was a wrong analysis of my stack overflow. Repeated alloca() is
not the problem since esp is restored with ebx as shown in the
assembly output I put.
I reported another Bug 45528 as the real problem.
--- Comment #3 from k_satoda at f2 dot dion dot ne dot jp 2010-09-03 21:40
---
I reported another Bug 45528 as the real problem.
It's Bug 45529. Sorry again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45528
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2010-09-03
21:58 ---
Okay the problem is that pre-r163815/r163816, we had in gcc/configure.ac...
# x86's use BID format instead of DPD
case x$enable_decimal_float in
xyes)
case $target in
i?86*-*-linux* |
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-09-03
22:12 ---
Of course this bug impacts all non-linux targets so it should be a P1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524
--- Comment #5 from paolo at gcc dot gnu dot org 2010-09-03 23:19 ---
Subject: Bug 45347
Author: paolo
Date: Fri Sep 3 23:19:18 2010
New Revision: 163848
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163848
Log:
2010-09-03 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #6 from paolo dot carlini at oracle dot com 2010-09-03 23:21
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #33 from howarth at nitro dot med dot uc dot edu 2010-09-03
23:36 ---
Fixed at r163811.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-09-03
23:37 ---
Fixed at r163823.
--
howarth at nitro dot med dot uc dot edu changed:
What|Removed |Added
The example program is:
program test
implicit none
type c_struct
type (g_struct), pointer :: g
end type
type g_struct
type (p_struct), pointer :: p
end type
type p_struct
type (region_struct), pointer :: r
end type
type region_struct
type (p_struct) plot
end type
type (c_struct)
Compiler output:
$ gcc -fvar-tracking-uninit -fcompare-debug testcase.c
testcase.c:1:0: warning: variable tracking requested, but useless unless
producing debug info [enabled by default]
gcc: error: testcase.c: -fcompare-debug failure (length)
The failure appears with -g as well, but the warning
--- Comment #1 from zsojka at seznam dot cz 2010-09-03 23:51 ---
Created an attachment (id=21690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21690action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45531
=no
Thread model: posix
gcc version 4.6.0 20100903 (experimental) [trunk revision 163847p4] (GCC)
[macbook] gcc/build_w% grep -r enable_decimal_float */config.log
gcc/config.log:enable_decimal_float='dpd'
libdecnumber/config.log:enable_decimal_float='dpd'
prev-gcc/config.log:enable_decimal_float='dpd'
prev
--- Comment #7 from zsojka at seznam dot cz 2010-09-04 00:12 ---
Created an attachment (id=21691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21691action=view)
different crash
$ gcc -O -march=amdfam10 -ftree-slp-vectorize -fnon-call-exceptions pr45470-2.C
pr45470-2.C: In
The test program is:
program test
implicit none
type line_struct
integer :: width = 10
end type
type symbol_struct
integer :: typee = 10
end type
type curve_struct
type (line_struct) line
type (symbol_struct) symbol
end type
type (curve_struct) curve(10)
namelist / params / curve
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-09-04
01:26 ---
Reverting and regenerating libgcc/configure.ac is insufficient to eliminate the
failures. I will try reverting both libgcc/configure.ac and
libdecnumber/configure.ac next. I suspect the changes in
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2010-09-04
02:09 ---
To make clearer the subtleties being lost in a single dfp.m4 file, here are the
diffs of the lines replaced out of configure.ac from each location (gcc, libgcc
and libdecnumber).
--- gcc 2010-09-03
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-09-04 02:13
---
(In reply to comment #9)
--- gcc 2010-09-03 22:04:53.0 -0400
+++ libgcc 2010-09-03 22:01:16.0 -0400
@@ -11,34 +11,26 @@
esac
],
[
- case $target in
+ case $host in
This is
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-09-04
02:27 ---
I am not worried about $host vs $target but rather the nuances in the xno case
for x$enable_decimal_float in the original code. For gcc/configure.ac, this
sets...
enable_decimal_float=dpd
but that case
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-09-04
02:28 ---
(In reply to comment #11)
but that case is not handled in gcc/configure.ac. Likewise comparing
but that case is not handled in libgcc/configure.ac. Likewise comparing
--
--- Comment #15 from hp at gcc dot gnu dot org 2010-09-04 03:08 ---
(In reply to comment #4)
Good job picking up on that.
There must be a better way of telling the compiler to generate lwr and lwl
MIPS
instructions without breaking strict aliasing rules...?
When requiring a
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2010-09-04
03:39 ---
Reverting both libgcc/configure.ac and libdecnumber/configure.ac and
regenerating these files is insufficient as well to eliminate the regressions
on darwin. Looking at the remaining changes in
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2010-09-04
05:21 ---
The original patch introduce this minor variations in the code copied for
dfp.m4 in the gcc/configure.ac, libgcc/configure.ac and libdecnumber.ac is
found here...
101 - 137 of 137 matches
Mail list logo
