On Tue, Aug 28, 2012 at 3:26 PM, Ian Lance Taylor i...@google.com wrote:
On Tue, Aug 28, 2012 at 6:21 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Sorry for such a stupid question, but assuming that the GCC trunk (e.g. svn
rev 190745)
did already switch (during my holidays, so I
On Wed, Aug 29, 2012 at 1:03 PM, Deepti Sharma
deepti.gccretar...@gmail.com wrote:
Hello Richard,
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
Richard Guenther
Sent: 31 May 2012 14:27
To: Mohamed Shafi
Cc: GCC; d...@redhat.com; Ahmed
On Fri, Aug 24, 2012 at 10:06 PM, Lawrence Crowl cr...@googlers.com wrote:
To take full advantage of the conversion to C++, we will need to use
I'm not sure what full advantage of single-inheritance vs. composition is.
single inheritance in some of our garbage collected structures. To
that
On Tue, Sep 4, 2012 at 4:12 PM, Iyer, Balaji V balaji.v.i...@intel.com wrote:
Hello Everyone,
I am getting the following error when I am trying to build the trunk
on x86_64 SuSE Linux. My SVN head is at revision 190930. Is anyone else
finding this?
On Thu, Sep 6, 2012 at 12:47 AM, Jan Hubicka hubi...@ucw.cz wrote:
What do you think of the following plan for turning cgraph into
a class hierarchy? We cannot finish it until we have gengtype
understanding single inheritance, but we can start changing APIs
in preparation.
Good you told me,
On Thu, 6 Sep 2012, Martin Jambor wrote:
Hi,
(I'm CCing the gcc mailing list too since I suppose it is an accident
that it wasn't in the message I'm replying to)
On Thu, Sep 06, 2012 at 09:22:27AM +0200, Jan Hubicka wrote:
On Thu, Sep 6, 2012 at 12:08 AM, Jan Hubicka hubi...@ucw.cz
On Fri, Sep 7, 2012 at 6:31 PM, David Malcolm dmalc...@redhat.com wrote:
After a hiatus, I've restarted work on an API for GCC plugins -
specifically, a C API (given that my plugin is written in C, I have more
interest in that than a C++ API).
BTW, how many other GCC plugins are written in C?
On Tue, Sep 11, 2012 at 3:10 AM, David Malcolm dmalc...@redhat.com wrote:
On Mon, 2012-09-10 at 17:20 +0200, Michael Matz wrote:
Hi David,
On Mon, 10 Sep 2012, David Malcolm wrote:
Is it possible for you to post your work-in-progress code somewhere?
Attached.
Many thanks for posting
Richard Guenther rguent...@suse.de
* builtin-types.def (BT_FN_CONST_STRING): Add.
* builtins.def (BUILT_IN_FILE_LOCATION, BUILT_IN_FUNCTION_LOCATION,
BUILT_IN_LINE_LOCATION): New builtins.
* gimplify.c (gimplify_call_expr): Expand them.
* doc/extend.texi
On Thu, 13 Sep 2012, Richard Guenther wrote:
On Wed, 12 Sep 2012, Gabriel Dos Reis wrote:
On Wed, Sep 12, 2012 at 11:50 AM, Diego Novillo dnovi...@google.com wrote:
Alternately, we could use Richi's approach I suppose (what happened to
that
patch, btw)?
I was under
On Thu, 13 Sep 2012, Diego Novillo wrote:
Thanks for the patch!
On 2012-09-13 08:46 , Richard Guenther wrote:
Index: gcc/testsuite/g++.dg/ext/builtin-location.C
===
*** /dev/null 1970-01-01 00:00:00.0
On Sat, Sep 22, 2012 at 9:40 AM, Andreast Tobler
andreast-l...@fgznet.ch wrote:
Hi all,
while testing some patches fro Michael M, I noticed that disable-checking
seems broken on trunk. I saw this on x86_64-freebsd and powerpc64-freebsd.
Is this issue already known?
If not, usual bug report
On Mon, Sep 24, 2012 at 1:01 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
Hello All,
When a plugin calls fatal_error, the compilation naturally fails,
but the last error message is misleading, it says
(while getting a bug in the MELT plugin for example)
cc1: fatal error: MELT
On Mon, Sep 24, 2012 at 2:04 PM, Dinar Temirbulatov
dtemirbula...@gmail.com wrote:
Hi,
I noticed some minor regression with singed integer operations in the
proprietary code since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45232. Of course, I could
use -fwrapv flag but my question is: why
On Mon, Sep 24, 2012 at 3:01 PM, srinivas dama srinivas@gmail.com wrote:
Hi,
I see there is predicate REG_EXPR for getting declaration node for a REG rtx.
It would be helpful If I get an equivalent predicate for a SUBREG rtx.
I couldn't find such thing.
My requirement is :
I need
On Tue, Oct 2, 2012 at 10:44 AM, Joern Rennecke
joern.renne...@embecosm.com wrote:
I'll have to prepare a few more patches to (supposedly) generic
code to support the ARCompact port, which we (Synopsys and Embecosm)
would like contribute in time for gcc 4.8.
How much time is left till we
On Tue, Oct 2, 2012 at 11:34 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, Oct 2, 2012 at 10:44 AM, Joern Rennecke
joern.renne...@embecosm.com wrote:
I'll have to prepare a few more patches to (supposedly) generic
code to support the ARCompact port, which we (Synopsys
On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
I fall into ssa verification failure when try to pass field's
DECL_SIZE as an operand for CALL_EXPR. The fail occurs if field's size
is not a constant. In such case DECL_SIZE holds a VAR_DECL and I need
to find
On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill ja...@redhat.com wrote:
In C++ there is a common idiom called initialize on first use. In its
simplest form it looks like
int lazy_i()
{
static int i = init;
return i;
}
If the initialization is expensive or order-sensitive, this is a
On Wed, Oct 3, 2012 at 12:07 AM, DJ Delorie d...@redhat.com wrote:
Here's my current patch for the bitfield reversal feature I've been
working on for a while, with an RX-specific pragma to apply it
globally. Could someone please review this? It would be nice
to get it in before stage1
On Tue, Oct 2, 2012 at 4:19 PM, Walter Lee w...@tilera.com wrote:
On TILE-Gx, I'm observing a degradation in inlined memcpy/memset in
gcc 4.6 and later versus gcc 4.4. Though I find the problem on
TILE-Gx, I think this is a problem for any architectures with
SLOW_UNALIGNED_ACCESS set to 1.
On Thu, Oct 4, 2012 at 2:56 PM, Jason Merrill ja...@redhat.com wrote:
On 10/04/2012 08:45 AM, Jakub Jelinek wrote:
On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill ja...@redhat.com wrote:
If the result is not needed, are we
On Thu, Oct 4, 2012 at 5:22 PM, Jason Merrill ja...@redhat.com wrote:
On 10/04/2012 09:07 AM, Richard Guenther wrote:
Ugh. Especially with the above (you can DCE those calls) makes this
severly mis-specified ... and any implementation error-prone (look what
mess our losely defined 'malloc
On Thu, Oct 4, 2012 at 7:08 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Oct 4, 2012 at 5:22 PM, Jason Merrill ja...@redhat.com wrote:
On 10/04/2012 09:07 AM, Richard Guenther wrote:
Ugh. Especially with the above (you can DCE those calls) makes this
severly mis-specified
On Thu, Oct 4, 2012 at 7:15 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 04, 2012 at 07:08:02PM +0200, Richard Guenther wrote:
But isn't it a fact that it _cannot_ modify init_count? If the second call
is CSEable then it cannot have side-effects that are observable at
the call site
4.7, however, I get inlined byte-by-byte copies: ...
On Thu, Oct 04, 2012 at 01:58:54PM +0200, Richard Guenther wrote:
There is no way to fix it. memcpy does not require aligned arguments
and the merely presence of a typed pointer contains zero information
of alignment for the middle-end
On Thu, Oct 4, 2012 at 8:02 PM, Jason Merrill ja...@redhat.com wrote:
On 10/04/2012 01:42 PM, Richard Guenther wrote:
So I suppose the testcase that would be valid but break with using
pure would be instead
int main()
{
int x = init_count;
int *p = get_me();
if (init_count == x
On Thu, Oct 4, 2012 at 8:38 PM, DJ Delorie d...@redhat.com wrote:
ChangeLog missing, new functions need a toplevel comment documenting
function, argument and return value as per coding conventions.
Any review of the patch itself? I know the overhead is not there...
Why do you need to change
On Fri, Oct 5, 2012 at 9:15 AM, Tristan Gingold ging...@adacore.com wrote:
On Oct 4, 2012, at 11:23 PM, Ian Lance Taylor wrote:
On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
Is libbacktrace currently functional in gcc trunk and is it expected
to function on
On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich enkovich@gmail.com wrote:
2012/10/4 Richard Guenther richard.guent...@gmail.com:
On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
I fall into ssa verification failure when try to pass field's
DECL_SIZE
On Fri, Oct 5, 2012 at 2:36 PM, Ilya Enkovich enkovich@gmail.com wrote:
2012/10/5 Richard Guenther richard.guent...@gmail.com:
On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich enkovich@gmail.com
wrote:
2012/10/4 Richard Guenther richard.guent...@gmail.com:
On Wed, Oct 3, 2012 at 7:05
On Fri, Oct 5, 2012 at 8:15 PM, DJ Delorie d...@redhat.com wrote:
Why do you need to change varasm.c at all? The hunks seem to be
completely separate of the attribute.
Because static constructors have fields in the original order, not the
reversed order. Otherwise code like this is
On Mon, Oct 8, 2012 at 11:26 AM, Ludovic Courtès l...@gnu.org wrote:
Hello,
Consider the attached plug-in, which adds a new dummy pass after the
“ssa” pass, with ‘TODO_rebuild_alias’ as its start flags:
When compiling with -O0 a non-trivial file with that plug-in, one ends
up with:
On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès l...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com skribis:
At -O0 no virtual operands are produced. TODO_rebuild_alias only computes
points-to sets which are in itself not useful.
What do you want to achieve
On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès l...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com skribis:
On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès l...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com skribis:
At -O0 no virtual operands are produced
On Mon, Oct 8, 2012 at 3:32 PM, Ludovic Courtès l...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com skribis:
On Mon, Oct 8, 2012 at 1:42 PM, Ludovic Courtès l...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com skribis:
On Mon, Oct 8, 2012 at 11:58 AM, Ludovic Courtès l
On Mon, Oct 8, 2012 at 6:04 PM, Ludovic Courtès
ludovic.cour...@inria.fr wrote:
Richard Guenther richard.guent...@gmail.com skribis:
On Mon, Oct 8, 2012 at 3:32 PM, Ludovic Courtès l...@gnu.org wrote:
Richard Guenther richard.guent...@gmail.com skribis:
On Mon, Oct 8, 2012 at 1:42 PM
On Mon, Oct 8, 2012 at 5:17 PM, David Malcolm dmalc...@redhat.com wrote:
I'm working on a static analysis extension to GCC via my
gcc-python-plugin [1]
The analysis is interprocedural (memory leak detection, as it happens).
I have it working on one translation unit at a time, and I'm
On Mon, Oct 8, 2012 at 11:29 PM, David Malcolm dmalc...@redhat.com wrote:
On Mon, 2012-10-08 at 18:21 +0200, Richard Guenther wrote:
On Mon, Oct 8, 2012 at 5:17 PM, David Malcolm dmalc...@redhat.com wrote:
I'm working on a static analysis extension to GCC via my
gcc-python-plugin [1
On 6/18/07, Uros Bizjak [EMAIL PROTECTED] wrote:
On 6/18/07, tbp [EMAIL PROTECTED] wrote:
Until now, the contract was: you have to deal with (and contain) NaN
and infinities. Fair enough, even if tricky that remained manageable.
But if i can't expect a mere division by 0, or sqrt of 0 (quite
On 6/18/07, Brooks Moses [EMAIL PROTECTED] wrote:
Giovanni Bajo wrote:
Both our goals are legitimate. But that's not the point. The point is
what -ffast-math semantically means (the simplistic list of suboptions
activated by it is of couse unsufficiente because it doesn't explain how
to
On 6/19/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
'wrong', not inaccurate ;)
I still support the introduction of a special switch for this kind of
transformation, -fwrong-math-optimizations. :-)
Probably as useful and
On 6/19/07, Dominique Dhumieres [EMAIL PROTECTED] wrote:
On powerpc-apple-darwin7 with 4.3.0 20070615, the compilation time
of the polyhedron test suite increased by 35% compared to the
previous snapshot and by 41% compared to the Apr 13 one:
I did not see this change. What flags are you
a patch that adds all missing trivial stuff
but not doing structural equivalence checks - I'm not sure we really
need these.
Comments?
Thanks,
Richard.
2007-06-20 Richard Guenther [EMAIL PROTECTED]
* tree-ssa.c (tree_ssa_useless_type_conversion_1): Document
future intent. Re
On 6/20/07, Dominique Dhumieres [EMAIL PROTECTED] wrote:
Exctracted from
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt:
date compile execute
070608 106.29 628.74
070615 117.43 629.73
070620 105.95 616.99
So these tests show a ~10% increase of the compilation
On 6/20/07, Dominique Dhumieres [EMAIL PROTECTED] wrote:
Maybe you can identify the single most increase for ppc?
The ranking is:
compile
06/15 06/08%
channel 4.289 2.519 70
induct 36.87823.671 56
protein 20.09713.162
On Wed, 20 Jun 2007, Michael Matz wrote:
Hi,
On Wed, 20 Jun 2007, Richard Guenther wrote:
/* If the outer type is (void *), then the conversion is not
necessary.
??? This makes tree_ssa_useless_type_conversion_1 not
transitive. */
Not this line
On Wed, 20 Jun 2007, Giovanni Bajo wrote:
Hi Richard,
what about moving all the type-system related functions to a new file, eg:
tree-ssa-type.c? I think that makes the intent even clearer.
While this is surely a good idea I'd like to do this separately to not
make diffs unnecessarily
. Nice optimization. ;)
Thanks.
(You really should thank richard guenther and steven bosscher, who
continually beat me up till i finished it :P)
Unfortunately, this improvement is a miscompare:
Value= 2190.9357900 Target= 2191.1145000 Tolerance=0.100E-02
FAIL
Value
On 7/3/07, Jeffrey Law [EMAIL PROTECTED] wrote:
On Tue, 2007-07-03 at 13:07 +0200, Richard Guenther wrote:
On 7/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 7/2/07, Uros Bizjak [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
I'm curious if it was the pre/fre changes. can you try -fno
On 7/4/07, Eric Botcazou [EMAIL PROTECTED] wrote:
Ada bootstrap has been broken by the SCC value numbering patch too (this is PR
tree-optimization/32589) but this might be due to a latent problem.
In the FRE dump:
RHS p__name_buffer[1]{lb: 1 sz: 1} + n_32 simplified to
On 7/4/07, Eric Botcazou [EMAIL PROTECTED] wrote:
This is invalid gimple.
Right, but nevertheless is_gimple_val.
Can you figure our why we don't gimplify this to
tmp_1 = MAX_EXPR D.738_31, 0;
tmp_2 = (unnamed-signed:32)tmp_1;
tmp_3 = tmp_2 + 1;
p_name_buffer[tmp3]
Because there is no
On 7/4/07, Eric Botcazou [EMAIL PROTECTED] wrote:
Ok. So either we want to disallow invariant addresses as gimple value
altogether or
do more elaborate checks, to rule out such bogus cases. At least the
transformation
PRE is doing doesn't make sense -- and I know other optimization passes
) | 9 lines
2005-11-19 Richard Guenther [EMAIL PROTECTED]
PR middle-end/23294
* fold-const.c (fold_plusminus_mult_expr): New function.
(fold_binary): Use to canonicalize PLUS_EXPR and MINUS_EXPR
cases, remove now unnecessary code.
* gcc.dg
On 7/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 7/4/07, Richard Kenner [EMAIL PROTECTED] wrote:
Also, we need to update the GIMPLE grammar so that ARRAY_REF and
ARRAY_RANGE_REF take the appropriate values:
A minor comment is that operand 2 of COMPONENT_REF needs the same handling.
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
The code to fold_binary was added by:
r107218 | rguenth | 2005-11-19 03:29:10 -0800 (Sat, 19 Nov 2005) | 9
lines
2005-11-19 Richard Guenther [EMAIL PROTECTED]
PR
On Thu, 5 Jul 2007, Paolo Carlini wrote:
Hi,
I'm having a look to libstdc++/30482, which basically is C++ issue: Jakub
basically raises the issue of whether we want to use by default the
C99-conforming division in C++ too. Personally, I would be in favor of
enabling it unconditionally,
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, I wrote:
Exactly and that's why I think this transformation is done far too early.
It doesn't make sense that these two examples produce different code:
int foo1(int x)
{
return (x * 4) + 4;
}
int foo2(int
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
If there is anything to fix, then all those variants should produce
the same code, not just foo3 and foo4. So for these cases we should
make sure that value-numbering sees them as computing
On Thu, 5 Jul 2007, Paolo Carlini wrote:
Mark Mitchell wrote:
To be clear, my preferences, from most preferable to least are:
* Method 2 is the default for all C variants, but can be overridden by
-ffast-math, or -fcomplex-method.
* Method 2 is the default for C99 and C++0x, but not
On Thu, 5 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
Well, that's always the nature of any canonicalization.
Well, I can't say that I agree with your canonicalization, but...
of course only tested on this particular testcase. It just shows
On Fri, 6 Jul 2007, Roman Zippel wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
For me both canonicalizations generate
movl8(%ecx,%edx,4), %eax
addl4(%ecx,%edx,4), %eax
Hmm, there seem to be other problems in this area as well.
Either add a p[i
On 7/8/07, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
No, that's something else entirely (a float old-style parameter
declaration corresponds to a double argument in a prototype). It's
convert_arguments that handles converting to prototype types and
On 7/8/07, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
On Sun, 8 Jul 2007, Richard Guenther wrote:
So type-generic is supposed to apply to scalar floating point types
only?
So far, yes.
I don't see anything that requires or prohibits changing that for the
initial implementation. If later a GCC
On 7/10/07, Ramana Radhakrishnan [EMAIL PROTECTED] wrote:
Hi,
While upgrading a port of mine to trunk for a testcase I noticed the
following . Its more of a question for a language lawyer I guess.
The test looks like this.
int spinlock[2];
void foo (void)
{
volatile int * spinlock0;
while
On 7/11/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 7/11/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Summary
---
The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.
As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all
changes. If you have outstanding
On 12 Jul 2007 04:37:20 -0500, Gabriel Dos Reis [EMAIL PROTECTED] wrote:
Mark Mitchell [EMAIL PROTECTED] writes:
| The GCC SC is still discussing a few of the finer points of the
| transition to GPLv3.
Thanks for the update!
[...]
| 3. After GCC 4.2.1 is released, we will renumber the
On 7/12/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Ian Lance Taylor wrote:
The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3.
And anyone using any past release.
Incorrect. It only matters for
On 7/14/07, H.J. Lu [EMAIL PROTECTED] wrote:
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00165.html
causes the regression:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748
The only relevant change is
Index: gcc/fortran/trans-decl.c
On 16 Jul 2007 14:39:39 -, Wolfram Gloger [EMAIL PROTECTED]
wrote:
Hi,
First, I assume we are talking about C realloc here, not just a
realloc-like function which may have other semantics and for which
__attribute_malloc__ may not be appropriate.
It looks like gcc assumes a functon
On 7/18/07, Richard Henderson [EMAIL PROTECTED] wrote:
On Tue, Jul 17, 2007 at 09:53:30AM -, Wolfram Gloger wrote:
Surely you agree that in my second example, *p = 0 _cannot_ be moved
after the call to destroy_something_and_allocate_anotherthing(p)?
It can't be moved after, but it could
On 7/19/07, tbp [EMAIL PROTECTED] wrote:
I have that usual heavy duty 3 fp components class that needs to be
reasonably efficient and takes this form for g++
struct vec_t {
float x,y,z;
const float operator()(const uint_t i) const { return *(x + i); }
float
On 7/19/07, tbp [EMAIL PROTECTED] wrote:
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Well, I always used the array variant, but you should be able to do
[snip]
if you need to (why does the array form not work for you?)
Because if you bench in some non trivial program, on x86/x86-64
On 7/21/07, tbp [EMAIL PROTECTED] wrote:
On 7/19/07, Richard Guenther [EMAIL PROTECTED] wrote:
Of course, if any then the array indexing variant is fixed. It would be nice
to see a complete testcase with a pessimization, maybe you can file
a bugreport about this?
There's many issues for all
On 7/25/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (4 members), aliasing will
make a difference possibly,
On 7/27/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
Another recent example: http://gcc.gnu.org/ml/gcc/2007-07/msg00456.html
(Not a single answer).
Summing up, I am not sure whether a separate list would help but in my
opinion there are a few things that will:
If we do not manage to
On 8/9/07, Ollie Wild [EMAIL PROTECTED] wrote:
On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I also haven't necessarily said what Ollie has proposed is a bad idea.
I have simply said the way he has come up with what he proposed is
not the way we should go about this. It may turn out
On 8/26/07, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
On Fri, 24 Aug 2007, Brian Sidebotham wrote:
This ICE is caused by the following patch:
2007-08-10 Kaveh R. Ghazi [EMAIL PROTECTED]
* system.h (CONST_CAST): New.
* c-decl.c (c_make_fname_decl): Use it.
*
On 8/28/07, Revital1 Eres [EMAIL PROTECTED] wrote:
Hello,
I get the following ICE with trunk r127857 running the testsuite on SPU:
built-in:0: internal compiler error: in add_builtin_function, at
langhooks.c:485^M
Please submit a full bug report,^M
with preprocessed source if
On 8/28/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 8/28/07, Revital1 Eres [EMAIL PROTECTED] wrote:
Hello,
I get the following ICE with trunk r127857 running the testsuite on SPU:
built-in:0: internal compiler error: in add_builtin_function, at
langhooks.c:485^M
Please submit
On 8/28/07, Dave Korn [EMAIL PROTECTED] wrote:
On 28 August 2007 15:10, Richard Guenther wrote:
Or maybe on ppc/spu enum bitfields are signed and the following
DECL_FUNCTION_CODE (decl) = -1;
gcc_assert (DECL_FUNCTION_CODE (decl) = function_code);
doesnt work?
I saw what
On 8/28/07, Dave Korn [EMAIL PROTECTED] wrote:
On 28 August 2007 15:57, Revital1 Eres wrote:
Wow, you mean SPU has more builtins than x86_64? Up the bitfield
width of tree.h tree_function_decl.function_code until it no longer ICEs.
I checked in a fix.
Richard.
On Fri, 31 Aug 2007, Richard Guenther wrote:
On Fri, 31 Aug 2007, Diego Novillo wrote:
Richard, this comment does not match the code. The code allows type
conversions between two integral types and between arbitrary types that
happen to *not* be integral. Which semantics did you
On Fri, 31 Aug 2007, Diego Novillo wrote:
Richard, this comment does not match the code. The code allows type
conversions between two integral types and between arbitrary types that
happen to *not* be integral. Which semantics did you mean here?
/* Allow conversions between
On 9/1/07, Mark Mitchell [EMAIL PROTECTED] wrote:
This bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33272
is about a situation in which -fargument-noalias works better than
putting restrict on all pointer arguments to a function, even though
that should be logically equivalent. Using
On 9/1/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
I have a prototype hack which changes checks of flag_argument_noalias !=
0 to also check for the presence of restrict on all pointer arguments.
This fixes the test case, modulo a C front-end bug which Joseph has
On 9/1/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
I fully concede that my trick isn't a general solution to making full
use of restrict. But, given that I think it'll take about 20-50 lines
of code, and that it will get a lot of the common cases, I think it's
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to alias
each other during *loads*.. IE you can guarantee any restricted
pointer that is stored into can't
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the c99
standard, is that it is perfectly valid for restrict pointers to alias
each other during *loads*.. IE you can
We set has_volatile_ops on all(?) memory references during early
optimization because we don't have alias information. But we
do it inconsistently for loads. For example I see
D.2574_23 = *D.2573_22;
(no volatile) and
D.2565_28 ={v} tab[D.2560_27].__delta;
(volatile). Because for
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/3/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 9/3/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/2/07, Paul Brook [EMAIL PROTECTED] wrote:
That said, second, my understanding of restrict, from reading the
c99
On 9/2/07, Segher Boessenkool [EMAIL PROTECTED] wrote:
Bootstrap of current trunk on powerpc64-linux fails in libstdc++
building system_error.lo. The code that fails was added a few days
ago,
but the failure seems to be the same as the one reported in PR 31490.
I
verified that the
On 9/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote:
We still have the nasty aliasing problems:
PR32182 [4.2 Regression] -fstrict-aliasing optimizations cause co...
It's not clear from the PR that this is either an aliasing bug, and not
On 9/5/07, mandeep singh bhambra [EMAIL PROTECTED] wrote:
Hi,
In response to the march options, I tried to use both
-march=athlon-xp -g -O2 and -march=i686 -g -O2 but it does not
like it. It still gives the error message about the 386 commands.
When i use the ./configure command the march
On 9/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/5/07, Richard Guenther [EMAIL PROTECTED] wrote:
On 9/5/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/4/07, Mark Mitchell [EMAIL PROTECTED] wrote:
We still have the nasty aliasing problems:
PR32182 [4.2 Regression
On 9/5/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Summary
===
We are closing in on Stage 3, previously announced for September 10th.
At this point, I'm not aware of any reason to delay that date. Are
there any Stage 2 patches that people don't think will be submitted by
that point?
On 9/6/07, mandeep singh bhambra [EMAIL PROTECTED] wrote:
I have installed the latest binutils (2.9.1) available from the GNU ftp site
so I cannot understand why this is occuring. Are there some sort of parameter
options I need to enter or do I need to reinstall the binutils with parameter
On 9/6/07, Paolo Bonzini [EMAIL PROTECTED] wrote:
There is
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html
for example, which is not suitable for stage3.
As much as I like the idea, wasn't get_non_trapping considered unsafe?
Only if you tried to preserve this information
$subject? During early optimization the !ZERO_SSA_OPERANDS check doesn't
say the truth (well it does, but only in some sense) while the
references_memory flag seems to be updated ok.
There is one case, for calls, where we set references_memory
unconditionally even if we later might not add any
On 9/7/07, Tim Prince [EMAIL PROTECTED] wrote:
Dominique Dhumieres wrote:
In comment #7 of PR0, Richard Guenther asked the following question
I cannot answer:
Btw, is it mandated by the fortran standard to pass a scalar as array
reference?
Does anyone knows the answer? or should
1 - 100 of 5652 matches
Mail list logo
