Hi,
On Tue, 3 Feb 2015, Tom de Vries wrote:
Ironically, that fix breaks the va_list_gpr/fpr_size optimization, so
I've disabled that by default for now.
I've done a non-bootstrap and bootstrap build using all languages.
The non-bootstrap test shows (at least) two classes of real
Hi,
On Tue, 3 Feb 2015, Jakub Jelinek wrote:
It can be lowered during gimplification to some internal call.
That's what my patch does :)
What arguments and return values will it have can be decided based on
what will be most suitable for the lowering.
And that as well, just the concrete
Hi,
On Mon, 2 Feb 2015, Tom de Vries wrote:
I've minimized the vaarg-4a.c failure, and added it as testcase to the patch
series as gcc.target/x86_64/abi/callabi/vaarg-4.c.
The problem is in this code:
...
e = va_arg (argp, char *);
e = va_arg (argp, char *);
...
which is
Hi,
On Fri, 30 Jan 2015, Tom de Vries wrote:
Maybe you want to pick up the work?
In principle yes, depending on the amount of work (at this point I have no
idea what remains to be done and how long that would take me).
Michael, are your patches posted somewhere?
I don't think I ever
Hi,
On Wed, 28 Jan 2015, Tobias Burnus wrote:
I first want to point to POSIX, which has:
floor, floorf, floorl - floor function [...]
An application wishing to check for error situations should set errno to
zero and call feclearexcept(FE_ALL_EXCEPT) before calling these functions.
On
Hi,
On Tue, 20 Jan 2015, H.J. Lu wrote:
ia32 is confusing because ia64 (a well known term) sounds related but
can't be farther away from it, and it's also vendor specific. Our
traditional i386 seems better to me (although it has its own problems,
but I'm not aware of any better
Hi,
On Mon, 19 Jan 2015, Sandra Loosemore wrote:
I'd be happy to work on a patch to bring the manual to using a common
naming convention, but what should it be? Wikipedia seems to use
x86 (lowercase) to refer to the entire family of architectures
(including the original 16-bit
Hi,
On Wed, 19 Nov 2014, H.J. Lu wrote:
The first one (to 600ff8) is the normal GOT slot, the second one the GOT
slot for the PLT entry. Both are actually used:
004005f0 foo@plt:
4005f0: ff 25 32 0a 20 00 jmpq *0x200a32(%rip)#
601028
Hi,
On Thu, 20 Nov 2014, Patrick Palka wrote:
-wrapper is specifically also for invoking cc1 with gdb from the
driver (that's the usecase documented with -wrapper), so it better
should work as intended. I don't know what problems Patrick had with
that, though. For me gcc -wrapper
Hi,
On Thu, 20 Nov 2014, Richard Biener wrote:
I don't think this API will make the non-C++-fans happier; I think the
objection to the work I just merged is that it's adding more C++ than
those people are comfortable with.
How so? It's already super-ugly in those views. We decided to
Hi,
On Mon, 17 Nov 2014, H.J. Lu wrote:
It has nothing to do with large model.
Yes, I didn't say so. I've used it only to force GCC to emit @GOT relocs
(otherwise it would have used @GOTPCREL) to disprove your claim.
The same thing happens to small model. We may be to able optimize it,
Hi,
On Mon, 17 Nov 2014, Richard Biener wrote:
This means I can no longer interrupt a compile that is running too long?
No, that's not what it means, cc1 will also get the SIGINT.
You should instead debug the actual compiler, not the driver.
-wrapper is specifically also for invoking cc1
Hi,
On Thu, 13 Nov 2014, H.J. Lu wrote:
@GOTPLT will create a PLT entry, but it doesn't mean PLT entry will be
used.
Correct. The compiler was supposed to somehow make a good decision (e.g.
if there were calls and address-takings in the same unit).
Only @PLTOFF will use PLT entry.
Hi,
On Thu, 13 Nov 2014, H.J. Lu wrote:
Linker does:
... code that looks like it might create just one GOT slot ...
So if a symbol is accessed by both @GOT and @PLTOFF, its
needs_plt will be true and its got.plt entry will be used for
both @GOT and @GOTPLT. @GOTPLT has no advantage
Hi,
On Thu, 13 Nov 2014, H.J. Lu wrote:
x86-64 psABI has
name@GOT: specifies the offset to the GOT entry for the symbol name
from the base of the GOT.
name@GOTPLT: specifies the offset to the GOT entry for the symbol name
from the base of the GOT, implying that there is a corresponding
Hi,
On Tue, 4 Nov 2014, Jeff Law wrote:
They still need to agree on the layout of the structure. And assuming
it'll always be memcpy perhaps isn't wise. Consider the possibility
that one day (perhaps soon) the host and GPU may share address space
memory.
Not only soon, there is
Hi,
On Mon, 27 Oct 2014, Aldy Hernandez wrote:
Here I use a new tree bit (BLOCK_DIE) to store the DIE-block
relationship. This will have to be adapted and streamed for LTO.
You might consider using an on-the-side tree-hash map. Saves memory when
not generating debug info (there can be many
Hi,
On Tue, 14 Oct 2014, Jamie Iles wrote:
int foo(void)
{
if (getreturn() != 0)
return -1;
return 0;
}
So if getreturn() returns zero it can simply reuse that return value ...
but at -O1 I get
10: fb ff ff
Hi,
On Fri, 19 Sep 2014, Aldy Hernandez wrote:
Michael, I really don't understand the need for this change in your original
patch. I don't know if this was a temporary testing change or what.
I'm pretty sure it was temporary testing, when I still was finding my way
through dwarf2out
Hi,
On Mon, 14 Jul 2014, Franzi Edo. wrote:
It is like if gcc do not take in account of my BUILD_CFLAGS=-g -O2
-fbracket-depth=1024“
GCC meanwhile is compiled with c++. Instead of CFLAGS use CXXFLAGS. I.e.
BUILD_CXXFLAGS, and so on. No guarantees, but at least foobar_CFLAGS only
should
Hi,
On Thu, 10 Jul 2014, Jeff Law wrote:
The insight to note is, that undefined SSA names should really be
coalesced with something (otherwise you lost an optimization opportunity),
but it doesn't matter with _what_ each use of the undefined name is
coalesced, you can even identify
Hi,
our kernel guys saw this problem when they used an asm goto to implement a
conditional where the then-block was empty. RTL ifcvt happily goes on and
removes the whole block and the jump instruction, even though it has
side-effects (as marked with the volatility). Patch below fixes it by
Hi,
On Thu, 10 Jul 2014, Richard Biener wrote:
Apart from the out-of-SSA patch you proposed elsewhere a possibility
is to simply never mark undefined SSA names as
SSA_NAME_OCCURS_IN_ABNORMAL_PHI ... (or not mark those
as must-coalesce).
The insight to note is, that undefined SSA names
Hi,
On Mon, 16 Jun 2014, Richard Biener wrote:
For
(match_and_simplify
(MINUS_EXPR @2 (PLUS_EXPR@2 @0 @1))
@1)
Btw, this just triggered my eye. So with lumping the predicate to the
capture without special separator syntax, it means that there's a
difference between minus_expr @2
Hi,
On Mon, 2 Jun 2014, Ilya Enkovich wrote:
There is exactly one place (except for the self-recursive ones) where
you call the new store_expr with a non-null argument for bounds
target, and it seems to be only necessary for when some sub-expression
of the RHS is a call. Can you
Hi,
On Mon, 2 Jun 2014, Ilya Enkovich wrote:
This patch adds support for input bounds, call bounds args and returned
bounds in expand pass.
* expr.h (store_expr): Add param for bounds target.
There is exactly one place (except for the self-recursive ones) where you
call the new
Hi,
On Tue, 20 May 2014, Richard Biener wrote:
Syntaxwise I had this idea for adding generic predicates to expressions:
(plus (minus @0 @1):predicate
@2)
(...)
So you'd write
(plus @0 :integer_zerop)
instead of
(plus @0 integer_zerop)
?
plus is binary, where is
Hi,
On Thu, 15 May 2014, Richard Biener wrote:
To me predicate (and capture without expression or predicate)
differs from expression in that predicate is clearly a leaf of the
expression tree while we have to recurse into expression operands.
Now, if we want to support applying predicates
Hi,
On Mon, 12 May 2014, David Malcolm wrote:
The gfoo type names are pleasantly terse, though I'm a little unhappy
about how they no longer match the prefix of the accessor functions e.g.
gimple_switch_num_labels (const gswitch *gs)
vs
gimple_switch_num_labels (const gimple_switch *gs)
Hi,
On Sat, 10 May 2014, Mike Stump wrote:
The rtx u2 field currently uses a desc/tag pair for GTY. This seems
unnecessary though,
OK to install?
Ick. I don’t favor skip. The change feels like a premature
optimization that doesn’t net any code gen benefit. I’ll defer to a gty
Hi,
On Sat, 10 May 2014, Richard Sandiford wrote:
@@ -362,6 +362,9 @@ struct GTY((chain_next (RTX_NEXT (%h)
/* The INSN_UID of an RTX_INSN-class code. */
int insn_uid;
+/* The SYMBOL_REF_FLAGS of a SYMBOL_REF. */
+unsigned int symbol_ref_flags;
+
In [3/7] you used
Hi,
On Mon, 12 May 2014, Richard Sandiford wrote:
Also I'm idly wondering if the explicit sizing of
the fields via a bit-field as originally would be better here or just
confusing. I guess unsigned and enums are 32bit for all hosts we care
about, but if we ever have one where it's
Hi,
On Fri, 25 Apr 2014, Richard Biener wrote:
Btw, I agree we should stick to one style throughout the code-base.
The advantage of the cast variant is that it can be made work with
NULL pointers (in the dyn_cast case).
NULL pointers shouldn't even be casted at all, there should be sensible
Hi,
On Thu, 24 Apr 2014, Andrew MacLeod wrote:
Well, we ought to settle on one... either use the is_a, as_a, and
dyn_cast paradigm as they exist today, or we use the cast_as_method
approach everywhere. I'm not fond of each potential project having a
different approach... I'd like to see
Hi,
On Thu, 24 Apr 2014, David Malcolm wrote:
Implicit naming
===
Several people have suggested that the gimple_ prefix is redundant.
Not generally though (for instance I find it redundant in the
cast-method names, but _not_ in the global types).
Andrew MacLeod suggested in:
Hi,
On Mon, 21 Apr 2014, David Malcolm wrote:
This is a greatly-expanded version of:
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01262.html
As of r205034 (de6bd75e3c9bc1efe8a6387d48eedaa4dafe622d) and
r205428 (a90353203da18288cdac1b0b78fe7b22c69fe63f) the various gimple
statements form
Hi,
On Fri, 18 Apr 2014, Steven Bosscher wrote:
IMHO TER should be improved to *do* disturb the order of the incoming
instructions, to reduce register pressure.
The latter is the goal, yes. But TER isn't really the right place for
that (it's constrained by too many invariants, running after
Hi,
On Thu, 17 Apr 2014, Richard Sandiford wrote:
The constraints on a ‘movm’ must permit moving any hard register to
any other hard register provided...
by providing a define_expand that assigns from a general_operand to a
nonimmediate_operand and ...
*ldsi instruction that can
Hi,
On Thu, 17 Apr 2014, Richard Biener wrote:
The patch below increases the number of coalescs we attempt
to also cover unary and binary operations.
This is not usually a good idea if not mitigated by things like register
pressure measurement and using target properties to determine if it's
Hi,
On Tue, 8 Apr 2014, Hans-Peter Nilsson wrote:
Also, do we really want to document the trick in
m ((@{ struct @{ char x[10]; @} *p = (void *) ptr ; *p; @}))
(note: reformatted GNU-style and confusing @{ @} dropped)
We already document this since quite some time, and yes, it's indeed
Hi,
On Mon, 24 Mar 2014, Richard Henderson wrote:
See
http://en.wikipedia.org/wiki/X86_calling_conventions#pascal
Since we don't actually support this anymore, we can certainly tidy this
up.
Yeah, I thought about that, but I couldn't see how that could have used
PUSH_ARGS_REVERSED.
Hi,
On Mon, 24 Mar 2014, Richard Biener wrote:
Maybe somebody remembers why we have both paths. I'd rather make
gimplification independent of this as well, choosing either variant.
I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's
the way that initially was there,
Hi,
On Thu, 27 Feb 2014, Richard Sandiford wrote:
[... many cases where 'volatile' in asm doesn't inhibit optimizations
...]
We do nothing this draconian for a normal function call, which could
easily use a volatile asm internally. IMO anything that isn't flushed
for a call shouldn't be
Hi,
On Wed, 26 Feb 2014, Richard Biener wrote:
\tstr wzr, [%2, #4]!\n
\tsub %1, %1, #1\n
\tcbnz %1, 0b\n
: =m(*p), +r(len) : r(p));
I presume this is wrong because *p only refers to p[0]. Is it
possible to tell GCC that the asm writes to the
Hi,
On Fri, 21 Feb 2014, Paul E. McKenney wrote:
And with conservative I mean everything is a source of a dependency, and
hence can't be removed, reordered or otherwise fiddled with, and that
includes code sequences where no atomic objects are anywhere in sight [1].
In the light of
Hi,
On Mon, 24 Feb 2014, Linus Torvalds wrote:
To me that reads like
int i;
int *q = i;
int **p = q;
atomic_XXX (p, CONSUME);
orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they
want to say that it orders against aliased storage - but then go
Hi,
On Thu, 20 Feb 2014, Linus Torvalds wrote:
But I'm pretty sure that any compiler guy must *hate* that current odd
dependency-generation part, and if I was a gcc person, seeing that
bugzilla entry Torvald pointed at, I would personally want to
dismember somebody with a rusty spoon..
Yes.
Hi,
On Tue, 28 Jan 2014, Jan Hubicka wrote:
It is also problem of inliner quality decisions and memory use/compile
time. The in-memory representation of unnecesary EH is quite big.
I am quite ignorant in this area, but for -O0 can't we simply disable
all clobbers?
That sounds
Hi,
On Wed, 29 Jan 2014, Jakub Jelinek wrote:
It is also problem of inliner quality decisions and memory
use/compile time. The in-memory representation of unnecesary EH is
quite big.
I am quite ignorant in this area, but for -O0 can't we simply
disable all clobbers?
Hi,
On Tue, 28 Jan 2014, Richard Biener wrote:
The EH optimizations involving cleanups with only clobbers in them
are that if at the end of the cleanup after only CLOBBER stmts you
would rethrow the exception externally, then the clobber isn't needed
and the whole cleanup can be
Hi,
On Tue, 28 Jan 2014, Jakub Jelinek wrote:
There are two kinds of clobbers, the direct ones, which surely can be
safely removed by ehcleanup1 if they are the only reason why there is a
landing pad which will be rethrown outside of the current function,
You can only safely (as in, not
Hi,
On Thu, 5 Dec 2013, Maxim Kuvyrkov wrote:
Output dependency is the right type (write after write). Anti
dependency is write after read, and true dependency is read after write.
Dependency type plays a role for estimating costs and latencies between
instructions (which affects
Hi,
On Wed, 20 Nov 2013, Jeff Law wrote:
There are three places the patch doesn't touch:
(A) cfgbuild.c (make_edges) has this comment:
/* By nature of the way these get numbered, ENTRY_BLOCK_PTR-next_bb
block
is always the entry. */
where the meaning wasn't immediately
Hi,
On Fri, 22 Nov 2013, Xinliang David Li wrote:
Apart from the issue that LTO drops all BLOCKs this makes the middle-end
feature too much tied to the C family frontends and their definition
of restrict. It also requires BLOCK lookup / matching at the time
of the alias query (which
Hi,
On Mon, 25 Nov 2013, David Malcolm wrote:
I'm not a fan of these _layout names, but I'm not sure what better to
call them. Perhaps:
GSS_OMP_PARALLEL_LAYOUT - GSS_OMP_WITH_CLAUSES_CHILD_FN_DATA_ARG
GSS_OMP_SINGLE_LAYOUT - GSS_OMP_WITH_CLAUSES
Hello,
after much pondering about the issue we came up with this design to
handle restrict more generally. Without a completely different way of
representing conflicts (or non-conflicts) of memory references we're bound
to somehow encode the necessary information into the points-to set (or in
Hi,
On Tue, 19 Nov 2013, Richard Biener wrote:
$subject - the following turns
loop_iterator li;
FOR_EACH_LOOP (li, loop, LI_ONLY_INNERMOST)
{
...
if ()
FOR_EACH_LOOP_BREAK;
}
into
FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST)
{
...
if ()
Hi,
On Thu, 14 Nov 2013, Jeff Law wrote:
Thanks. It's pretty much what I expected. Obviously for other codes
there may be a lot more changes that you have to slog through, but I
think this example shows the main concepts.
Presumably in this new world order, the various gimple statement
Hi,
On Wed, 13 Nov 2013, Andrew MacLeod wrote:
There needs to be a place which has gimple componentry that is not
related to or require a statement. gimple.h is becoming the home for
just 0gimple statements. There are 3 (for the moment) major classes of
things that are in statements and
Hi,
On Thu, 14 Nov 2013, Richard Biener wrote:
Why not give bitmap_head a constructor/destructor and allow auto use of
that. Isn't that exactly what should get 'auto' handling automagically?
auto != c++98 :-/
Ciao,
Michael.
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
That's why I think talking about a gimple expression as if they were
somehow some stand-alone concept is fairly confusing, and introducing it
now as if it would somewhen exist would lead to going down some inferior
design paths.
Well, for
Hi,
On Thu, 14 Nov 2013, Andrew MacLeod wrote:
I think if following through with the whole plan there would (and
should) be nothing remaining that could be called a gimple expression.
very possibly, i just haven't gotten to those parts yet. I can change
the name back to
Hi,
On Wed, 13 Nov 2013, Joseph S. Myers wrote:
+In GNU C, but not GNU C++, you may also declare the type of a variable
+as @code{__auto_type}. In that case, the declaration must declare
+only one variable,
What's the reason for this restriction? I can't see what would become
ambiguous
Hi,
On Thu, 7 Nov 2013, Alec Teal wrote:
subclass, by adding empty subclasses derived from the GSS_-based
subclasses as appropriate (I don't bother for gimple codes that already
have their own subclass due to having their own GSS layout). I also
copied the comments from gimple.def
Hi,
On Wed, 6 Nov 2013, David Malcolm wrote:
I don't like that. The empty classes are just useless, they imply a
structure that isn't really there, some of the separate gimple codes
are basically selectors of specific subtypes of a generic concept,
without additional data or methods;
Hi,
On Tue, 5 Nov 2013, David Malcolm wrote:
Here's a followup patch which ensures that every gimple code has its own
subclass, by adding empty subclasses derived from the GSS_-based
subclasses as appropriate (I don't bother for gimple codes that already
have their own subclass due to having
Hi,
On Wed, 6 Nov 2013, Ilya Enkovich wrote:
Well, but clearly you can see that bounds for p == NULL are
useless and thus there is no problem with the transform.
This example just demonstrates the issue. I may use some var's address
in comparison with the similar result. And value does
Hi,
I just hit this problem where gengtype thought an existing gt-*.h header
was the same as what it wanted to write because its prefix was indeed
equal to the buffer, but contained some additional things afterwards.
gengtype simply forgot to check that the file end is reached at buffer
end.
Hi,
On Tue, 15 Oct 2013, Richard Biener wrote:
On Sun, Oct 6, 2013 at 2:22 PM, Bernd Edlinger
bernd.edlin...@hotmail.de wrote:
How I should proceed with this patch, is it OK?
The latest version was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00234.html
I have now
Hi,
On Mon, 30 Sep 2013, Jeff Law wrote:
- the compiler better do an awesome job of sharing stack space for
user variables in a function... I wouldn't want to blow up the stack
with a bazillion unrelatd temps each wit their own location.
If the objects have the same type and disjoint
Hi,
On Sat, 28 Sep 2013, Andrew MacLeod wrote:
My example in this form would look something like:
int unsignedsrcp = ptrvar.type().type().type_unsigned();
...
GimpleType t1 = ptrvar.type ();
GimpleType t2 = t1.type ();
Stop that CamelCase dyslexia already, will you? ;-)
Ciao,
Michael.
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Yea. I actually reviewed the libstdc++ guidelines to
Hi,
On Fri, 20 Sep 2013, Trevor Saunders wrote:
very ugly FWIW. I only added the underscores because that's what
the conventions said.
But we're never going to get consensus on this kind of thing. E.g.
I know some people really hate the GNU formatting style (although I
Hi,
On Fri, 20 Sep 2013, David Malcolm wrote:
Treat GTY structs that have a desc as being the root of an inheritance
hierarchy. Generate a switch on desc within the marking function with
cases for each subclass, visiting all fields of the type (including
inherited ones).
Yay! Thanks for
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
I know, and I don't like it there either.
Well, as Ian pointed out, it is in our recommended style guidelines and
you'll find uses in the vec class as well.
As I said, yes; I also said those were pre-existing from the C times
already, so they
Hi,
On Wed, 18 Sep 2013, Zhenqiang Chen wrote:
The patch is updated according to your comments. It is a basic support,
which does not touch ifcombine and jump related optimizations yet.
Current method is:
1) In fold-const, if HAVE_conditional_compare, set
LOGICAL_OP_NON_SHORT_CIRCUIT
Hello,
On Tue, 17 Sep 2013, Jeff Law wrote:
I put the attached patch through a bootstrap and regression test cycle on
x86_64-unknown-linux-gnu. As expected no regressions. Installed onto the
trunk.
Thanks Trevor!
You missed one comment style nit, and some ChangeLog entry nits.
I'm
Hi,
On Wed, 18 Sep 2013, Jeff Law wrote:
On 09/18/2013 10:24 AM, Michael Matz wrote:
I'm irritated by the member name uglification (e.g. equiv_stack_ with
trailing underscore). I know that's a certain style to mark private
members, but I think it's a bad style (like prefixing variable
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
Where? I don't see config/alpha.c listed anywhere.
Must be in one of the fragments in config/ or config/alpha. For
i386 it's config/i386/t-i386
Well, we have a problem here. The dependencies from t-* files are
ignored
Why do you think so?
Hi,
On Mon, 16 Sep 2013, Uros Bizjak wrote:
Why do you think so? The t-* frags are includes via
...
tmake_file=...$(srcdir)/config/i386/t-i386
...
ifneq ($(tmake_file),)
include $(tmake_file)
endif
...
It's just that there's no t-alpha frag yet.
No, there is no problem
Hi,
On Thu, 5 Sep 2013, Andrew MacLeod wrote:
1 - I think we ought to split out the data structures from gimple.h into
gimple-core.h, like we did with tree.h
Why?
gimple.h. That won't really affect my work. I think it probably ought to be
done for clarity eventually.gimple.h would
Hi,
On Thu, 5 Sep 2013, Richard Biener wrote:
(1) whether it's OK for wide_ints to be writable.
The interface already exposed the idea of an array of blocks,
via get_val() and get_len(). The question here is whether it is OK
to also have the corresponding write functions
Hi,
On Tue, 3 Sep 2013, David Malcolm wrote:
I can't really say I find this shorter, easier to read, more
expressive or even safer than what was there before. And the
repetition for adding the helpers for const and non-const types
all the time doesn't make it better.
Hi,
On Fri, 30 Aug 2013, David Malcolm wrote:
Here's the result of a pair of builds of r202029 without and with the
patches, configured with --enable-checking=release, running make, then
stripping debuginfo [1]
So the overall sizes of such binaries are essentially unchanged.
Yep, cool.
Hi,
On Thu, 29 Aug 2013, David Malcolm wrote:
Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
testcases show the same results as an unpatched build (relative to
r202029).
I'd like to see some statistics for cc1{,plus} codesize and for compile
time of something
Hi,
On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek ja...@redhat.com wrote:
I thought the principle that was acquired was that gengtype shouldn't
be improved to support more than what it does now….
If it means that we'll need to write and
Hi,
On Thu, 29 Aug 2013, Richard Biener wrote:
Fork-fire-forget is really a much simpler choice here IMO; no worries
about shared resources, less debug hassle.
It might be not as cheap as it is on Linux hosts on other hosts of
course.
Sure. Don't use it there then. Not a reason for
Hi,
On Wed, 21 Aug 2013, Richard Biener wrote:
I also fail to see why threads should not work here. Maybe simply
annotate gcc with openmp?
Threads simply don't work here, because the whole streamer infrastructure
(or anything else in GCC for that matter) isn't thread safe (you'd have to
Hi,
On Fri, 12 Jul 2013, Ian Lance Taylor wrote:
It was probably a mistake to have a linker -O option at all.
Doesn't the linker produce something that is faster to link and/or smaller,
with this flag?
For gold I think it has two effects. If you use compressed debug
sections, it
Hi,
GCC happily transforms (float)-z into -(float)z, even when z is of
unsigned type (when it's larger than float). That's wrong (the result
should always be positive, because -z is). It seems to me that this bug
exists in all reasonably recent GCC versions. The checking in
convert_to_real
Hi,
On Fri, 12 Jul 2013, Michael Matz wrote:
Hi,
GCC happily transforms (float)-z into -(float)z, even when z is of
unsigned type (when it's larger than float). That's wrong (the result
should always be positive, because -z is). It seems to me that this bug
exists in all reasonably
Hi,
On Fri, 12 Jul 2013, Marc Glisse wrote:
If you want to handle integers, shouldn't you test TYPE_OVERFLOW_UNDEFINED
(for LONG_MIN)?
Right, ...
FLOAT_TYPE_P does seem safer indeed.
... hence this is it now.
I'd replace TREE_TYPE (expr) with itype on the next line, it is confusing to
Hi,
On Wed, 10 Jul 2013, David Given wrote:
Michael Matz wrote:
[...]
As you didn't adjust any cost I would guess the high value comes from the
default implementation of address_cost, which simply uses arithmetic cost,
and the MULT in there is quite expensive by default.
See
Hi,
On Thu, 11 Jul 2013, Gabriel Dos Reis wrote:
Arg, no. -Werror is very useful for development and I'm sure that
code quality increases because of it, but it should never be enabled
by default for releases. I think about 80% of the bugs we've had
filed so far for packages failing
Hi,
On Sun, 7 Jul 2013, Thierry Lavoie wrote:
int main(int argc, char** argv)
{
A* ptr = 0;
if(argc == 1)
ptr = new B();
else
ptr = new A();
ptr-blah();
B().blah();
C().blah();
}
The puzzling part
Hi,
On Tue, 9 Jul 2013, David Given wrote:
Trying 8, 9 - 10:
Successfully matched this instruction:
(set (reg:SI 47 [ *_5 ])
(mem:SI (plus:SI (mult:SI (reg/v:SI 43 [ b ])
(const_int 4 [0x4]))
(reg:SI 0 r0 [ a ])) [2 *_5+0 S4 A32]))
rejecting combination of
On Wed, 19 Jun 2013, Joern Rennecke wrote:
I.e. the arguments after your patch are exactly swapped. This is usually
harmless, but not always, so that should be corrected before check in.
The change in cselib.c:cselib_invalidate_mem has the same problem.
Well, I have already committed
On Sun, 16 Jun 2013, Joern Rennecke wrote:
Quoting Eric Botcazou ebotca...@adacore.com:
Could you also check that your patch also fixes PR opt/57569 and, if so, add
the reference to the ChangeLog as well as the testcase?
Attached is what I'm currently testing. bootstrap on
Hi,
On Tue, 14 May 2013, Uros Bizjak wrote:
I'd propose to introduce:
a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS
b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS
This would break -m32.
c) #undef and #define DEFAULT_TLS_SEG_REG in rdos.h to SEG_GS
Then use
Hi,
On Thu, 14 Mar 2013, Richard Biener wrote:
That said - can we please pass in the type of the operation (and thus
the newly created result temporary) _explicitely_ please? Thus
I'm mostly with you (not adding gimple_builder_ssa, but improving the
existing interface), except for this
601 - 700 of 1272 matches
Mail list logo
