http://www.binaryaffiliates.com/?am=40 (it
takes less than a minute!) please drop me an email, and we can start
working on a fun, rewarding and PROFITABLE partnership! And I can
activate the $15 additional reward for you.
Thanks and best regards,
Roger
Binary Affiliates Recruitment Manager
rd Sandiford's and David Daney's patch works out, we can
correct the wrong-code issue, without the performance loss.
Once explained, I'd expect most maintainers would make precisely the
same call?
Roger
--
On Wed, 25 Oct 2006, Richard Sandiford wrote:
> Roger Sayle <[EMAIL PROTECTED]> writes:
> > Once explained, I'd expect most maintainers would make precisely the
> > same call?
>
> I suppose the counter-argument is that we shouldn't ship 4.2 in its
> curre
ly, there'll be no more surprises.
Roger
--
Hi Paolo,
On Mon, 30 Oct 2006, Paolo Bonzini wrote:
> Given that Roger started the ball rolling, by approving Steven's
> -fcse-skip-blocks patch, I'll ping the discussion...
>
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01066.html
I believe the appropriate next st
eed
to figure out how these edges are getting merged. If this is a
side-effect of recent CFG/RTL related changes jump bypassing might
need to be restructured/rewritten to avoid using the insn on edge
functionality.
Steven Bosscher might even have plans for reorganizing jump bypassing
already as part of his CSE/GCSE overhaul?
Roger
--
l, and probably be tweaked to avoid warning in
system headers. However, it's also odd that in this respect C has had
stricter/better diagnostics that C++ for some time.
Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined
when T is a 32-bit signed type, but well-defined if T is unsigned or
wider than 32-bits.
I hope this helps.
Roger
--
es
contain any changes to fold, and they're welcome to maintain those
changes locally until the prescribed time, but I thought I'd make
the offer anyway.
Roger
--
k, but it keeps with the philosophy for
this reorganization.
> Thoughts?
Likewise?
Roger
--
Hi Alex and Mark,
On 7 Mar 2005, mark at codesourcery dot com wrote:
> Yes, I understand. You still need to take it up with Roger, though.
My apologies to both of you for being curiously/annoyingly silent on
this is issue. I've been getting up to speed on the internals of the
C++ pa
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > For example, I believe that Alex's proposed solution to PR c++/19199
> > isn't an appropriate fix. It's perfectly reasonable for fold to convert
> > a C++ COND_EXPR into a MIN_EXPR or MAX_EXP
On Mon, 7 Mar 2005, Mark Mitchell wrote:
> Roger Sayle wrote:
> > I truly hope you're not trying to suggest that it was me that introduced
> > the concept of MIN_EXPR and MAX_EXPR as lvalues into the C++ front-end:
>
> I thought you were the person who introduced change
On Mon, 7 Mar 2005, Richard Henderson wrote:
> On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote:
> > For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need
> > to specify a reference to the first operand is returned for values
> > comparing equal.
>
&
s most targets are either able to place the
result of the addition/subtraction in the requested destination or
provide their own adddi3/addti3 expanders.
Thanks for finding/fixing this. This might be a candidate for backporting
to the GCC 4.0 branch if we can find a target/testcase that triggers a
problem.
Roger
--
ken to extremes, these policies can clearly
be dangerous (if none of these cc1 files contains K&R prototypes,
perhaps we could drop parser support for pre-ANSI C, etc...).
Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
was sufficient, life would be much
simpler. Instead, because automated testing of the possible interactions
can never be sufficient, our development practices rely on intelligent
individuals to give each change the consideration it deserves. The
fact that I've been slow in doing so (or that nobody else has reviewed
it) is an issue. But to claim that such diligence is unnecessary is
one of the things that distinguishes maintainers from contributors.
Perhaps I just think, and care, and worry too much.
[All comments and criticisms welcome. Just because some of my points
are well reasoned and argued, doesn't mean that I'm completely
out-of-my-mind insane on others].
Roger
--
s is the better long-term strategy.
I take it from your comments, that you are in the camp that believes
that "the sun has not yet set" on the need for RTL optimizers. :-)
The intent of my post was to defend what was seen as my pro-RTL
stance, it's interesting to see that the loudest feedback is that
I'm underestimating/down-playing the importance of the RTL optimizers.
Much appreciated,
Roger
--
On Mon, 18 Apr 2005, Paolo Bonzini wrote:
> Roger proposed lowering 64-bit arithmetic to 32-bit in tree-ssa! How
> would you do it? Take
>
> long long a, b, c;
> c = a + b;
>
> Would it be
>
> c = ((int)a + (int)b)
> + ((i
NO_MATH_INLINES should cure
this.
Thanks in advance,
Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833
0.x). Two of them were pretty simple to
> handle. Others were closed as "fixed in 3.4.x, won't fix in 3.3.6".
> Except this:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
> for which I would appreicate inputs from both the author and Roger.
My apologies for the d
assumption that fold_convert can be used is incorrect.
You mentioned on IRC that many of the optimizers aren't expecting
VIEW_CONVERT_EXPRs, in which case it really is best to leave these
indirect references through casts of ADDR_EXPRs in their original form.
Roger
--
n what/when type conversions are useless in tree-ssa.
Hence, if there are any missed optimizations, for my original suggestion
these would have to be caught at gimplification (or in fold_stmt), with
a mode test like the one above, when the context of the indirect_ref
expression is known.
I hope this clears up the STRIP_NOPS confusion.
Roger
--
sults using x87 hardware intrinsics,
and this alone classifies their use as "unsafe" in GCC terminology,
i.e. may potentially produce different results.
Roger
--
se whether this really was just a backend problem,
and whether we should just return the code to a form similar to the
one RTH originally contributed.
I hope this answers your question.
Roger
--
ecks
in VRP. Some of the cases discussed in the above threads might make
interesting tests for the VRP code. I'll admit some of this "lore" should
be documented, but the issue has never been satisfactorily resolved to
everyone's satisfaction, so we keep with the less than idea "status quo".
Roger
--
simplify_replace_set() function.
As the SET (and perhaps support for PARALLEL) should only ever
occur at the top-level, which can then call the recursive
simplify_replace_rtx.
I hope this helps.
Roger
--
this isn't
a simple cut'n'paste, as replace_rtx destructively overwrites it's
input expression, whilst simplify_replace_rtx returns a different
tree if anything changed.
Roger
--
m the "safe"
form, I wouldn't be opposed to removing the "unsafe" form completely,
if people think its an optimization "too far".
Thanks for investigating this.
Roger
--
> In fact, I remember a plan of merging NOP_EXPR and CONVERT_EXPR.
Doh! I follow gcc-patches more closely than the gcc list, so I saw
your post there first and replied without cross-posting. For those
interested in the topic, my thoughts are at:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00124.html
Roger
--
ead when the result is unused/cobbered. I've
no idea whether we've another target-independent mechanism to inform
dataflow that a structure or some fields of it are used undefined.
This should explain why the middle-end is doing what it's doing.
As for how best to "fix" this behaviour, I'll leave to someone else.
Roger
--
t there
are no reads from another MEM that aliases this one. */
if (loop_info->mems[i].optimize && written)
Roger
--
restructured based upon TREE_CODE_CLASS to avoid any
potential NULL pointer dereferences.
Anyone feel strongly for or against the above change? I'd prefer not
to have to bloat the trees we use with non-NULL operands, just to work
around the sanity checks we have. The types of error caught by this
assertion should be extremely rare.
Thoughts?
Roger
--
GCC lifecycle.
The clock is ticking for Kenny. I propose a reverse 48 hour rule
where we reinstate Zdenek's patch on Monday, either by fixing DF
by then or by reverting the DF changes. i.e. swap one of the clashing
patches for the other.
My apologies to everyone for any inconvenience
K for mainline,
please hold off on the reversion (or if necessary reapply with this
change).
Many thanks,
Roger
--
nal position is out of bounds.
This is OK for mainline. Though we'd also do well to fix some of
the underlying code that's causing this suspicious RTL.
Thanks,
Roger
--
intentional and serves
some useful purpose, or alternatively to change ix86_binary_operator_ok
so that we only allow valid instructions at this point.
Many thanks in advance,
Roger
--
Sorry for the breakage. I'll have a fix before the sun goes down,
that performs the shift in the correct mode, then appropriately
sign extends, zero extends or truncates if necessary.
Many thanks for analyzing this failure. Sorry again.
Roger
--
ava, fortran
and treelang, only define "convert" for use by the middle-end,
which means once the middle-end is cleaned up these functions
can be removed from their respective front-ends entirely.
I hope this makes sense. Sorry for not noticing your post
earlier. I tend to read the gcc list less frequently than
gcc-patches.
Roger
--
resumably everyone agrees that this evolution is a good thing.
The contention is whether everyone agrees that we're ready for
such a step. Is such a transition safe for stage 3 mainline,
and/or would front-ends prefer some time to double check that
this won't cause problems on conformance tests
On Sun, 2 Apr 2006, Eric Botcazou wrote:
> > 2006-04-01 Roger Sayle <[EMAIL PROTECTED]>
> >
> > * tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
> > [...]
> > (int_size_in_bytes): Likewise.
> > (host_integerp): Likewise.
>
uild1 (NEGATE_EXPR, type, t);
return TREE_CODE (temp) != NEGATE_EXPR;
and its logic precisely mirrors the equivalent code in negate_expr.
Perhaps some of the logic in fold_negate_const is more appropriate:
temp = fold_negate_const (arg0, type);
return !TREE_OVERFLOW (temp);
I hope this helps.
Roger
--
oes this sound reasonable?
Yes, this sounds reasonable. It was not the negate_expr_p call
that's causing your problems but the overly restrictive guard
on this transformation. Let me know the results of a bootstrap
and regression test in case that points out something I've missed.
Roger
--
towards zero. The fact that 0. is less than 1 means the result
is zero. Instead, you should probably use "rint" or "round" or "lround"
to return the nearest integer.
Roger
--
uot; at stabilizing the tree has reduced the need for the
earlier methods used to ensure/improve the quality of contributions.
There's also the new/recent complication that companies/groups now
maintain their own GCC branches, perhaps requiring write access even
for programmers who don't contribute to FSF GCC.
What do the other maintainers, or the SC, think?
Roger
--
Hi Mark,
On Tue, 2 May 2006, Mark Mitchell wrote:
> Roger, I know that you reviewed the SEE patches. Is there anything
> more than needs to be done to get them committed, in your view?
As far as I'm aware, we're still just waiting for the Haifa folks to
commit them to mainli
fsee from being turned on by
default at -O3.
I appreciate your efforts to actually correct the defficiencies in SEE,
which is indeed preferable, but for regression breakage in stage3, its
often better to simply band-aid the problem as quickly as possible, even
if you're close to a fix, as a courtesy to other developers.
Roger
--
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
> for MIPS on the GCC 4.1 branch?
>
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part becaus
rd indicated to me that he would locate or open one now.)
>
> Opened as 27681. (And Roger: sorry for all the hassle this patch has
> caused you. A good deed and all that...)
Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
backend's use of the GOFAST lib
__int128_t.
If libstdc++-3's configure checked for __int128_t and provided
a specialized STL instantiation, it would exhibit the same issue.
Roger
--
o 4.2
and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
functionality isn't on the branch. For the record, the final
mklibgcc.in changes that I tested are attached to this e-mail.
I hope this helps.
Roger
--
Index: mklibgcc.in
On Thu, 29 Jun 2006, Andreas Jaeger wrote:
> Current svn does not build, it fails for me with:
> build/genpreds: Internal error: RTL check: expected elt 0 type 'e' or 'u',
> have 's' (rtx match_code) in write_match_code_switch, at genpreds.c:546
>
&g
e.de/~rguenther/tramp3d/
Whilst your analysis demonstrates that splay_tree_splay is behaving
curiously, I'm also interested in resolving the reported performance
benefits of the different implementations.
Thanks in advance,
Roger
--
'd
prefer, but the cheapest (using shifts/adds etc...) and that
choose_multiplier is potentially intertwined with synth_mult, the
world starts spinning and I need to reach for the headache tablets.
Roger
--
y believe that this unintended behaviour is/was interfering with
your code
coverage scripts (I should study your posted results).
I hope this explains things. Please let me know if things really are not fixed
(or not).
Cheers,
Roger
--
> -Original Message-
> From: Martin Jambor
> Sen
en further still trees might be marked read-only (i.e. const)
outside of the middle-end (allowing static trees and more middle-end
controlled tree sharing). Bwa-ha-ha-ha-ha (evil laugh)!
Roger
--
g is that its this failure of the java folks to finish
implementing an expand_expr replacement for JVM bytecodes thats the
primary motivating factor for the new "gcjx" front-end :)
Roger
--
these extensions for other targets which I can use to add support
for x86? Can someone estimate how big of an effort it would be for someone who
has no knowledge of GCC's internals but may be able to use another target as a
template?
Regards,
Roger R. Cruz
offset: 0x117d6): name
<267c9> DW_AT_decl_file : 2
<267ca> DW_AT_decl_line : 216
<267cb> DW_AT_type : <0x1a509>
<267cf> DW_AT_location : 2 byte block: 91 74 (DW_OP_fbreg: -12)
How can the above information be u
Thanks Michael. So it sounds like DWARF won't help me in determining how a
called function should (or should not) clean up the stack and also if I want to
determine the calling convention, I would have to modify GCC itself to produce
those user extensions.
LDRD instructions?
248 static DWORD64 dwarf2_get_u8(const unsigned char* ptr)
249 {
250 return *(const UINT64*)ptr;
251 }
(gdb) x/5i $pc
=> 0x4325ffd4 : ldrd r2, [r3]
gdb) p ptr
$6 = (const unsigned char *) 0x435a2fa5 ""
(gdb) p $r3
$7 = 0x435a2fa5
Happy Holidays,
Roger R. Cruz
emcpy which I knew was the right way to do
it. I'll push the changes to the OSS community then.
Roger R. Cruz
On Dec 26, 2012, at 8:00 AM, Andrew Haley wrote:
> On 12/24/2012 07:53 PM, Roger Cruz wrote:
>>
>>
>> I am compiling this piece of code from an open so
This is an optimization pass which leads to dramatically better code on
at least one SPEC benchmark. Ian, Roger, Diego, would one of you care
to review this?
My concern is that as formulated, conditional store elimination is not
always a win.
Transforming
if (cond)
*p = x
triggering some sort of
undefined behaviour in the shift/not/and sequence in 'get_int'.
Is this a bug in GCC or in the code above?
Kind regards,
--
Roger Ferrer Ibáñez
Done, it is PR64358.
Kind regards,
2014-12-19 12:21 GMT+01:00 Richard Biener :
> On Fri, Dec 19, 2014 at 10:13 AM, Roger Ferrer Ibáñez
> wrote:
>> Hi,
>>
>> I'm observing a weird behaviour in PowerPC64 Little Endian that does
>> not seem to occur on other arc
so seems to intel, xlc++ and comeau online) so
I assume it is some issue in g++.
Is this a known bug or I should fill a PR?
(It seems that GCC's bugzilla has some issues at the moment of writing this
message)
Kind regards,
--
Roger Ferrer Ibáñez - roger.fer...@bsc.es
piler mean? Most are
not obvious.
Thanks.
Roger
Greetings,
can you tell me if support of SanitizerCoverage is planned for gcc in the
foreseeable future?
Regards
Excellent! Since which version is this available?
From: Martin Liška
Sent: Tuesday, January 19, 2021 10:23 AM
To: Roger Phillips ; gcc@gcc.gnu.org
Subject: Re: SanitizerCoverage support
On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:
> Greetings,
>
>
nough.
From: Martin Liška
Sent: Tuesday, January 19, 2021 10:40 AM
To: Roger Phillips ; gcc@gcc.gnu.org
Subject: Re: SanitizerCoverage support
On 1/19/21 11:33 AM, Roger Phillips wrote:
> Excellent! Since which version is this available?
Hello.
The option -fsanitize-coverage=trace-pc is a
for sancov.
Regards
From: Martin Liška
Sent: Tuesday, January 19, 2021 10:23 AM
To: Roger Phillips ; gcc@gcc.gnu.org
Subject: Re: SanitizerCoverage support
On 1/19/21 10:07 AM, Roger Phillips via Gcc wrote:
> Greetings,
>
> can you tell me if support of SanitizerCover
Would it be possible to replicate the sancov functionality on gcc just through
special trace functions?
From: Martin Liška
Sent: Wednesday, January 20, 2021 11:40 AM
To: Roger Phillips ; gcc@gcc.gnu.org
Cc: weixi@antfin.com
Subject: Re: SanitizerCoverage
71 matches
Mail list logo
