Hi,
I'm trying to simplify somewhat code in the library hashing floating
point numbers, and I would find very useful a simple recipe giving the
total number of bits actually used by a long double: the basic issue is
that for formats like the 80-bit Intel, I can't just rely on sizeof,
because the
Paolo Carlini paolo.carl...@oracle.com writes:
At the moment I'm trying to cook up something fixing that count with
LDBL_MANT_DIG, but maybe there is something simpler, maybe using
preprocessor builtins?!?
What's wrong with LDBL_MANT_DIG?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
On 02/26/2010 01:03 PM, Andreas Schwab wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
At the moment I'm trying to cook up something fixing that count with
LDBL_MANT_DIG, but maybe there is something simpler, maybe using
preprocessor builtins?!?
What's wrong with LDBL_MANT_DIG?
Paolo Carlini wrote:
On 02/26/2010 01:03 PM, Andreas Schwab wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
At the moment I'm trying to cook up something fixing that count with
LDBL_MANT_DIG, but maybe there is something simpler, maybe using
preprocessor builtins?!?
Ed Smith-Rowland wrote:
Paolo Carlini wrote:
On 02/26/2010 01:03 PM, Andreas Schwab wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
At the moment I'm trying to cook up something fixing that count with
LDBL_MANT_DIG, but maybe there is something simpler, maybe using
preprocessor
Hi,
Huh. I would have *sworn* that sizeof(long double) was 10 not 16
even though we know it was 80 bits.
normally, it's either 12, for 32-bit machines, or 16, for 64-bit
machines. In any case, there are padding bytes, which we don't want to hash.
How about (in the language of
On 2/26/2010 5:44 AM, Ed Smith-Rowland wrote:
Huh. I would have *sworn* that sizeof(long double) was 10 not 16 even
though we know it was 80 bits.
As you indicated before, sizeof gives the amount of memory displaced by
the object, including padding. In my experience with gcc, sizeof(long
On 02/26/2010 03:47 PM, Tim Prince wrote:
It seems the topic would have been more appropriate for gcc-help, if
related to gcc, or maybe comp.lang.c, if a question about
implementation in accordance with standard C.
It's neither. I was asking for the advice of the compiler people while
Paolo Carlini paolo.carl...@oracle.com writes:
Thanks. Currently I'm thinking of doing something very simple, like:
const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val);
seems conservative and I think it covers all the cases we really
support.
What is __size supposed to
On 02/26/2010 03:56 PM, Andreas Schwab wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
Thanks. Currently I'm thinking of doing something very simple, like:
const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val);
seems conservative and I think it covers all the
On 02/26/2010 03:57 PM, Paolo Carlini wrote:
On 02/26/2010 03:56 PM, Andreas Schwab wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
Thanks. Currently I'm thinking of doing something very simple, like:
const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val);
Paolo Carlini paolo.carl...@oracle.com writes:
On 02/26/2010 03:56 PM, Andreas Schwab wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
Thanks. Currently I'm thinking of doing something very simple, like:
const size_t __size = __LDBL_MANT_DIG__ == 64 ? 10 : sizeof(__val);
Paolo Carlini paolo.carl...@oracle.com writes:
Andreas, more seriously, if you mean that __CHAR_BIT__ can be != 8, I
Don't be silly.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely
On 02/26/2010 04:41 PM, Andreas Schwab wrote:
Of what? What is the 10 magic number supposed to represent?
A size_t. Thus the number of consecutive chars occupied by the long double.
By the way, in the meanwhile I grepped config for BITS_PER_UNIT and
*finally* there are no 16 or 32 anymore.
Paolo Carlini paolo.carl...@oracle.com writes:
On 02/26/2010 04:41 PM, Andreas Schwab wrote:
Of what? What is the 10 magic number supposed to represent?
A size_t. Thus the number of consecutive chars occupied by the long double.
How does that handle padding?
Andreas.
--
Andreas
On 02/26/2010 04:51 PM, Andreas Schwab wrote:
How does that handle padding?
Andreas, I can spend the whole afternoon discussing with you one word at
a time in a kind of Socratic question and answer exchange.
You mean the padding can be *in the middle*? I didn't consider that,
seems quite
Paolo Carlini paolo.carl...@oracle.com writes:
You mean the padding can be *in the middle*? I didn't consider that,
seems quite crazy to me.
How is that crazy in any way?
If you are sure, please say it, let's skip
those 2 or 6 bytes, and be done with it. I have the patch otherwise ready.
Ok, patch canceled.
Paolo.
On 02/26/2010 05:03 PM, Andreas Schwab wrote:
If you don't care about internal padding why do you care about padding
By the way, this doesn't make any sense to me: I don't see what the CPU
gains from having padding between mantissa and exponent, or different
bytes of the mantissa. If you really
On 26/02/2010 15:45, Paolo Carlini wrote:
On 02/26/2010 04:41 PM, Andreas Schwab wrote:
Of what? What is the 10 magic number supposed to represent?
A size_t. Thus the number of consecutive chars occupied by the long double.
By the way, in the meanwhile I grepped config for BITS_PER_UNIT
Paolo Carlini paolo.carl...@oracle.com writes:
By the way, this doesn't make any sense to me: I don't see what the CPU
gains from having padding between mantissa and exponent, or different
bytes of the mantissa.
It's a fact of life. I didn't design the motorola floating point format.
If
On 02/26/2010 05:36 PM, Andreas Schwab wrote:
See libiberty/floatformat.c.
Ok, thanks. Actually, it looks like there is *no* padding in the middle
for the Intel x87 format I truly care about:
const struct floatformat floatformat_i387_ext =
{
floatformat_little, 80, 0, 1, 15, 0x3fff,
Hi,
I am trying to write a simple gcc plugin and am getting the following errors.
In file included from /home/aj/gcc/trunk/gcc/rtl.h:49,
from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:22:
On Fri, Feb 26, 2010 at 9:26 AM, ashish jain ashish_d...@yahoo.co.in wrote:
Hi,
I am trying to write a simple gcc plugin and am getting the following errors.
In file included from /home/aj/gcc/trunk/gcc/rtl.h:49,
from /home/aj/gcc/testcode/plugin/ctla_gcc_plugin.c:22:
Dear Sirs/Madams,
I am doing a project on Cell Broadband Engine
to parallelize the tokenization process of a given C program.
As we are done with the tokenization part we want it to replace the
tokenization part of
an open source compiler.
I mean the compiler that can run in Cell BE
Paolo Carlini paolo.carl...@oracle.com writes:
But really we don't want to deal with all those special cases for other
formats, for now at least. Too bad.
But LDBL_MANT_DIG == 64 is ambigous for identifying the floating point
format.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Fri, Feb 26, 2010 at 06:09:37PM +0100, Paolo Carlini wrote:
On 02/26/2010 05:36 PM, Andreas Schwab wrote:
See libiberty/floatformat.c.
Ok, thanks. Actually, it looks like there is *no* padding in the middle
for the Intel x87 format I truly care about:
const struct floatformat
On 02/26/2010 07:05 PM, Andreas Schwab wrote:
But really we don't want to deal with all those special cases for other
formats, for now at least. Too bad.
But LDBL_MANT_DIG == 64 is ambigous for identifying the floating point
format.
Sure, sure. I meant, there are too many formats and
On 02/26/2010 07:07 PM, Daniel Jacobowitz wrote:
Despite all that exchange, I don't think you ever answered Andreas's
question - at least not in a way that I could understand. A size of
what? The size of the *type* on x86 is 16; the size of the *data
bits* is 10. But what cares about the
Paolo Carlini paolo.carl...@oracle.com writes:
I'm tired. Anyway, I meant of course the size of the *data bits*, using
your terminology. For *some* formats, like x87, where there are no
holes, no padding bits in the middle of the representation, that is all
I would need. In the meanwhile,
Victor == Victor Norman vnor...@calvin.edu writes:
Victor I would like to tweak cpp to dump some usage stats from its symbol
Victor table -- like dumping which #defines were not used at all, etc.
In addition to what Ian said, for this particular case, search for
warn_unused_macros in libcpp.
Vivek == vivhari vivh...@gmail.com writes:
Vivek If any of you would be able to help me locate the tokenization
Vivek part of GCC and the input / output format for tokenizer part of
Vivek GCC, it would be very useful to us.
Tokenization is handled by the preprocessor, see the libcpp directory.
Paolo Carlini paolo.carl...@oracle.com writes:
I'm trying to simplify somewhat code in the library hashing floating
point numbers, and I would find very useful a simple recipe giving the
total number of bits actually used by a long double: the basic issue is
that for formats like the 80-bit
Feb 26, 2010 01:43:15 PM, sch...@linux-m68k.org wrote:
Paolo Carlini writes:
I'm tired. Anyway, I meant of course the size of the *data bits*, using
your terminology. For *some* formats, like x87, where there are no
holes, no padding bits in the middle of the representation, that is all
cat gcc_private_inheritance.cpp :
class A {};
class B : public A {};
class C : private B {
public:
operator A () {return *this;}
};
void doSomething (const A) {}
int main (int argc, char** argv){
C instC;
// Attempt 1. Causes compiler error, not expected
doSomething
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-02-26 09:47
---
The reason I occasionally use a thin pointer is because they can be stored
atomically. This is sometimes useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-26 10:06 ---
Confirmed. It's the vectorizer adjusting alignment of p.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-26 10:06 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-02-26 10:19
---
It looks like only c87b39a still fails as of this writing, but the 3 mentioned
tests (c37105a, c46051a, c87b39a) use a common pattern, namely discriminated
record types with fixed size and associated subtypes:
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-26 10:26 ---
gfortran already bails out with:
Error: Allocate-object at (1) is not a nonprocedure pointer
or an allocatable variable
If you are already patching, can you also improve the wording for this old
error
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-26 11:01 ---
Subject: Bug 43161
Author: jakub
Date: Fri Feb 26 11:01:28 2010
New Revision: 157083
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157083
Log:
PR debug/43161
* regcprop.c (struct
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 11:03 ---
Subject: Bug 43160
Author: jakub
Date: Fri Feb 26 11:02:39 2010
New Revision: 157084
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157084
Log:
PR debug/43160
* var-tracking.c (dv_onepart_p):
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-26 11:03 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 11:05 ---
This issue is fixed, there are other issues in vla-1.c unfortunately, but
IMNSHO it is better to track each issue separately.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.5 |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28868
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-26 11:05 ---
This has been transformed into PR43177 now.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
// { dg-options -gdwarf-2 -dA }
// { dg-final { scan-assembler
DW_TAG_structure_type\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\S\[^\\r\\n\]*DW_AT_name
} }
// { dg-final { scan-assembler
DW_TAG_typedef\[^\\r\\n\]*\[\\r\\n\]+\[^\\r\\n\]*\T\[^\\r\\n\]*DW_AT_name }
}
typedef struct S { int i; } *T;
#define
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-26 11:25 ---
Created an attachment (id=19967)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19967action=view)
gcc45-pr43190.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-26 12:10 ---
So, the problem seems to be in the equivalencing of VALUEs. val_resolve does:
1659/* Map incoming equivalences. ??? Wouldn't it be nice if
1660 we just started sharing the location lists? Maybe a
1661
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-26 12:40 ---
Small correction, VALUE 13:13 has initial location %edi, before it is
equivalenced to VALUE 2:2. So, at that point it is fine to have 13:13 as
cur_loc for VALUE 2:2, it is the same as having %edi there directly as
--- Comment #5 from dodji at gcc dot gnu dot org 2010-02-26 12:58 ---
Created an attachment (id=19968)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19968action=view)
Candidate patch
Here is what I think is happening, at least on gcc 4.5.
A/ The deleting dtor's DIE *is* being
--- Comment #17 from hjl at gcc dot gnu dot org 2010-02-26 13:18 ---
Subject: Bug 43175
Author: hjl
Date: Fri Feb 26 13:18:17 2010
New Revision: 157087
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157087
Log:
Correct expand_vec_perm_blend in i386.c for V8HImode merge.
gcc/
--- Comment #4 from manu at gcc dot gnu dot org 2010-02-26 13:20 ---
So this is not invalid...
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-26 13:20 ---
*** Bug 43184 has been marked as a duplicate of this bug. ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-26 13:20 ---
,,. but a duplicate
*** This bug has been marked as a duplicate of 32824 ***
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-26 13:29 ---
For some reason we inline 8 recursive calls of foo resulting in a load of
loops that we all completely unroll. And in fact this is profitable but
very slow because we estimate induction variable computations to be
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-26 13:34 ---
Subject: Bug 43188
Author: rguenth
Date: Fri Feb 26 13:34:38 2010
New Revision: 157088
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157088
Log:
2010-02-26 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-26 13:35 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from kaushik dot phatak at kpitcummins dot com 2010-02-26
13:55 ---
Created an attachment (id=19969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19969action=view)
Patch to generate bit instructions for H8 target and other minor enhancements
Patch to generate bit
--- Comment #3 from hjl dot tools at gmail dot com 2010-02-26 14:05 ---
gcc.dg/torture/stackalign/builtin-apply-4.c will
fail on x86-64 since -march=x86_64 will be added
by default since:
http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00664.html
--
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-26 14:07 ---
The initial question is whether to implement these for easily reversible insns
in vt_initialize, or when a VALUE becomes dead because nothing uses it.
Implementing it in vt_initialize (add_stores and count_uses) would
--- Comment #4 from ubizjak at gmail dot com 2010-02-26 14:24 ---
(In reply to comment #3)
MMX arguments are passed via %mm registers when __builtin_apply_args is used.
Touching %mm in any way will switch FP regstack to MMX mode, and since no emms
is emitted, reading %st will always
--- Comment #3 from dominiq at lps dot ens dot fr 2010-02-26 14:30 ---
With the patch in comment #2, I see a dozen runtime failure on my tests. I'll
need some time to analyse them (I have to separate invalid codes that pass by
chance from valid code that are miscompiled).
So keep
--- Comment #4 from dominiq at lps dot ens dot fr 2010-02-26 14:38 ---
The first obvious wrong code is for gcc/testsuite/gfortran.dg/streamio_6.f90:
The original dump without the patch shows
static integer(kind=4) a[100] = {13, 9, 34, 41, 25, 98, 6, 12, 11, 44, 79,
3, 64, 61, 77,
--- Comment #1 from rearnsha at gcc dot gnu dot org 2010-02-26 14:39
---
I don't think this test case is valid.
Unfortunately, the division function is not completely pure. If a division by
zero occurs, then a handler function may be invoked, which might cause the
contents pointed to
--- Comment #5 from hjl at gcc dot gnu dot org 2010-02-26 14:49 ---
Subject: Bug 37074
Author: hjl
Date: Fri Feb 26 14:49:02 2010
New Revision: 157089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157089
Log:
Add -mno-mmx to x86 in gcc.dg/torture/stackalign/stackalign.exp.
--- Comment #6 from hjl dot tools at gmail dot com 2010-02-26 14:49 ---
Fixed in 4.5.0.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r157079-install --program-prefix=r157079-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100226 (experimental) (GCC
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-26 15:46 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 15:56 ---
The reason for the two different VALUEs for the same thing here (where we have
just one normal bb) is that vt_add_function_parameters does
cselib_lookup/cselib_preserve_value calls after processing the last bb, so of
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-26 15:59 ---
Subject: Bug 43190
Author: jakub
Date: Fri Feb 26 15:58:57 2010
New Revision: 157092
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157092
Log:
PR debug/43190
* function.c (used_types_insert):
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-26 16:02 ---
Subject: Bug 43186
Author: rguenth
Date: Fri Feb 26 16:01:52 2010
New Revision: 157093
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157093
Log:
2010-02-26 Richard Guenther rguent...@suse.de
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-26 16:02 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from wirawan0 at gmail dot com 2010-02-26 16:06 ---
Here's a brief run with valgrind 3.5.0: I had to recompile glibc (2.10.1) with
splitdebug feature in Gentoo OS for it to work.
~/toys/gfortran/ch10 $ valgrind
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.4.3/f951
--- Comment #4 from pault at gcc dot gnu dot org 2010-02-26 16:06 ---
(In reply to comment #3)
by chance local changes which fix this issue?
I will go back and confirm that the tree on my machine at work is clean.
No, it wasn't, so my comment was incorrect.
Cheers
Paul
--
--- Comment #10 from wirawan0 at gmail dot com 2010-02-26 16:08 ---
Created an attachment (id=19970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19970action=view)
valgrind --leak-check=full output
I attach this as a more verbose report. Not sure if it is of any use.
--
--- Comment #5 from dominiq at lps dot ens dot fr 2010-02-26 16:29 ---
Another failing test is gcc/testsuite/gfortran.dg/data_char_2.f90:
without patch
static character(kind=1) intstr[1:10] = 0123456789;
with patch
static character(kind=1) intstr[1:10];
Note that in order to
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-26 16:37 ---
(In reply to comment #4)
The first obvious wrong code is for gcc/testsuite/gfortran.dg/streamio_6.f90:
but without the patch a[100] is not intialized
static integer(kind=4) a[100];
In trans-decl.c:
if
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-26 16:52 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-26 16:56 ---
Subject: Bug 24577
Author: manu
Date: Fri Feb 26 16:56:09 2010
New Revision: 157095
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157095
Log:
2010-02-26 Manuel López-Ibáñez m...@gcc.gnu.org
PR
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-26 17:03 ---
(In reply to comment #4)
My employer does not permit employees to contribute to open source projects
due
to IP concerns. What's your second choice?
You could lobby your employer to change their policy. I am sure
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-26 17:03 ---
(In reply to comment #4)
My employer does not permit employees to contribute to open source projects
due
to IP concerns. What's your second choice?
You could lobby your employer to change their policy. I am sure
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-26 17:04 ---
Thanks for the report in any case. This will be FIXED in GCC 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
--- Comment #7 from manu at gcc dot gnu dot org 2010-02-26 17:10 ---
Subject: Bug 20631
Author: manu
Date: Fri Feb 26 17:09:29 2010
New Revision: 157096
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157096
Log:
2010-02-26 Manuel López-Ibáñez m...@gcc.gnu.org
PR
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-26 17:11 ---
Thanks for the report. FIXED in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:15
---
I'll fix the bug, but are you sure about the commit? It looks unrelated to the
problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
--- Comment #5 from baldrick at gcc dot gnu dot org 2010-02-26 17:24
---
I was also surprised, because I couldn't see the relevance. To double check I
rebuilt one commit before (no crash) and at that commit (crash). That seems
pretty conclusive, especially as the testcase seems to
--- Comment #11 from kargl at gcc dot gnu dot org 2010-02-26 17:36 ---
(In reply to comment #10)
Created an attachment (id=19970)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19970action=view) [edit]
valgrind --leak-check=full output
I attach this as a more verbose report.
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:46
---
We might be able to save the day with the help of TYPE_CANONICAL in this case
since the size is fixed.
TYPE_CANONICAL is too strong, it will cause useless_type_conversion_p to return
true for conversions
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-26 18:04
---
I see that you are around... ;)
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from danglin at gcc dot gnu dot org 2010-02-26 18:15 ---
This bug was introduced in revision 147980:
2009-05-29 Martin Jambor mjam...@suse.cz
* tree-sra.c: New implementation of SRA.
--
danglin at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from wirawan0 at gmail dot com 2010-02-26 18:50 ---
I'm positive that the libraries used for compilation and running are the same.
The package was built on my own computer. I'm posting this bug at gentoo
bugzilla (http://bugs.gentoo.org/show_bug.cgi?id=306833) . Still
--- Comment #4 from changpeng dot fang at amd dot com 2010-02-26 18:53
---
Here is another similar case but more general. We know that a(j) and a(i)
never access the same memory location. intel ifort can vectorize this
triangular
loop:
do 10 j = 1,n
do 20 i = j+1, n
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-26 18:55 ---
(In reply to comment #4)
Here is another similar case but more general.
Actually it is a totally different case. Please file a new bug with that case;
though there might already be a bug about that one.
--
--- Comment #4 from sje at cup dot hp dot com 2010-02-26 19:05 ---
Was the patch from comment #3 ever sent to gcc-patches? I couldn't find it. I
did see earlier discussions about some other patches but the patch in comment
#3 seems to have been put here after those discussions.
I
--- Comment #6 from changpeng dot fang at amd dot com 2010-02-26 19:06
---
Actually it is a totally different case. Please file a new bug with that
case;
though there might already be a bug about that one.
I could not see the difference even though j is not a compile-time
--- Comment #7 from dominiq at lps dot ens dot fr 2010-02-26 19:27 ---
Change attr.is_main_program to sym-ns-proc_name-attr.is_main_program
This change fixes most of the failures I have seen. Is
if (TREE_STATIC (decl) !sym-attr.use_assoc
(sym-attr.save ||
--- Comment #8 from dominiq at lps dot ens dot fr 2010-02-26 19:37 ---
First failures
FAIL: gfortran.dg/auto_dealloc_1.f90 -O scan-tree-dump-times original
__builtin_free 5 - should be 4
FAIL: gfortran.dg/common_resize_1.f -O0 execution test
FAIL: gfortran.dg/common_resize_1.f
--- Comment #7 from rguenther at suse dot de 2010-02-26 19:56 ---
Subject: Re: [4.5 regression] miscompilation of ACATS c37105a
at -O2
On Fri, 26 Feb 2010, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-26 17:46
1 - 100 of 119 matches
Mail list logo
