Sorry, it was indeed in my spam box. Thanks to you both.
On Tue, Nov 1, 2016 at 3:05 PM, Ian Lance Taylor wrote:
> On Tue, Nov 1, 2016 at 2:01 PM, Josh Conner wrote:
>> My apologies in advance for the spam if this isn't the right forum. I
>> had svn access in a former lif
My apologies in advance for the spam if this isn't the right forum. I
had svn access in a former life (jcon...@apple.com), and I'm trying to
restore my access for my new employer. I sent an email to overseers
last week, but haven't heard back.
So... can anyone here tell me if there is some way to
Paul Brook wrote:
> On Friday 15 December 2006 01:37, Josh Conner wrote:
>> All -
>>
>> When I configure with --disable-bootstrap and build with:
>>
>> CFLAGS="-g -O0"
>>
>> The resultant compiler is built with the specified options. How
All -
When I configure with --disable-bootstrap and build with:
CFLAGS="-g -O0"
The resultant compiler is built with the specified options. However, if
I --enable-bootstrap, when I build with the same CFLAGS, these options
are not used to build the final compiler. I can get past this by usin
Sorry for my own slow response -- I've been doing more digging through
code, and didn't want to respond without a reasonable understanding...
Richard Kenner wrote:
>> However, in the case where we're passing the address of a temp slot to a
>> function, it doesn't make sense to me that this is the
Eric Botcazou wrote:
>> Is there anyone out there who might have a SPARC environment with Ada
>> support who could run the attached Ada testcase on a version of gcc
>> patched with the attached patch? I'd like to verify whether the test
>> behaves correctly when compiled at -O0, -O1, and -O2. The
Is there anyone out there who might have a SPARC environment with Ada
support who could run the attached Ada testcase on a version of gcc
patched with the attached patch? I'd like to verify whether the test
behaves correctly when compiled at -O0, -O1, and -O2. The expected
(correct) behavior is t
Richard Kenner wrote:
> I disagree. Testing is not, and should never be, a substitute for analysis.
>
> A patch is proposed because we have a reason to believe it's correct. Then
> we test to increase our confidence that it is, indeed, correct. But both
> parts are essential for any patch.
>
Richard Kenner wrote:
> I found the test case. As I suspected, it was on Sparc (the test case failed
> for a different reason on Mips) and was indeed a case where there were two
> function calls in the same parameter list of an outer call (though not the
> same function). It was an Ada test case
Richard Guenther wrote:
>> OK, thanks. If you have any suggestions on other approaches to
>> verifying this, I'd certainly appreciate it.
> Other than testing on more targets, no. Does it fix PR25505? In
> this case it would be a fix for a regression and maybe rth can have a
> look at the pat
Richard Kenner wrote:
>> I did investigate the case you described, where two function parameters
>> are calls to the same function returning a structure. The front-end
>> generates temporaries to handle this, and so the middle-end-generated
>> temporaries are still restricted to a lifetime of a s
Richard Kenner wrote:
>> So, my question is: is it really necessary to mark this location as
>> having its address taken? Yes, the address of the slot is passed to a
>> function, however I can't imagine any instances where the function
>> retaining that address after the call would be valid.
>
>
All -
I've been investigating the cause of pr25505, where the amount of stack
space being used for a particular C++ function went from <1K to ~20K
between gcc 3.3 and 4.0. One of the issues I ran into was that the
stack slot allocated to hold the result of a function returning a
structure was nev
Mark Mitchell wrote:
> Josh Conner wrote:
>
>
>>I think this is consistent with my proposal -- the first example was
>>non-conforming, but accepted without -pedantic (as we do with other
>>zero-sized arrays). The second example was conforming and the only way
>&
Mark Mitchell wrote:
> I understand what you're after: tolerate uses of the extension where
> it's sufficiently harmless.
>
> I don't think your proposed solution is correct, though, because we want
> to maintain the invariant that all conforming programs compile and
> behave as required by the s
I've been investigating PR 19989, where we are rejecting code when a
template instantiation generates a zero-sized array, such as:
template struct A
{
static const int i = 0;
}
template struct B
{
int x[A::i];
};
B<0> b;
This is rejected on the grounds that not failing cou
I've been looking at PR23708, where a non-inline explicitly
specialized template function is inheriting the inline semantics of
the inline member function it specializes, when using pre-compiled
headers (whew). This can be seen in the following example:
template class simple_class {
On Aug 24, 2005, at 12:33 PM, Richard Henderson wrote:
On Wed, Aug 24, 2005 at 11:10:38AM -0700, Josh Conner wrote:
Can someone provide a bit of insight here - what is the difference
between TREE_READONLY and TREE_CONSTANT (and why is TREE_READONLY the
one that ipa-reference should be
In looking at PR23237, I ran into a bit of confusion over the
difference between TREE_READONLY and TREE_CONSTANT. Andrew Pinski
indicated in PR logs that I am misunderstanding their uses, so rather
than bogging down the PR logs trying to clear up my confusion (which
isn't really fair to An
Am I misinterpreting the logic? Am I missing something
fundamental? I appreciate any feedback / pointers / clues / etc...
Nothing like hitting the send button to make the lightbulb go on.
I think I understand what was being attempted now. IIUC, the logic
should have been (again, for the
I'm seeing invalid code produced for a simple test case targeting arm-
none-elf (attached), which I believe is caused by an invalid
transformation in simplify_comparison. It's transforming code of the
form:
(compare (subreg:QI (plus (reg:SI) (-1)))
(-3))
into:
(compare (plu
On Jul 12, 2005, at 1:07 PM, Steven Bosscher wrote:
You don't say what compiler you used for these measurements. I
suppose
you used mainline?
Yes, I am working with the mainline.
I think you should look at a lot more code than this.
OK - I stopped because I was seeing fairly consistent
r I
also see a significant benefit to all targets in fixing the default
implementation first.
Thoughts? Advice?
Thanks -
Josh
Josh Conner
tree-estimate.patch
Description: Binary data
inl-costs.patch
Description: Binary data
" "8,12,20,8,8")
(set_attr "type" "*,*,*,load2,store2")
(set_attr "pool_range" "*,*,*,1020,*")
(set_attr "neg_pool_range" "*,*,*,1008,*")]
Thanks -
Josh
Josh Conner
Can anyone tell me if there are plans to incorporate the ARM EABI
exception handling (a la CSL) into the mainline gcc ARM port?
Thanks -
Josh
Josh Conner
Apple Computer
25 matches
Mail list logo