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
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
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
" "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
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
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
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
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
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
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
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 {
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
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
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
>&
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
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
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
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.
>
>
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 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 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 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.
>
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
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
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
25 matches
Mail list logo
