On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich 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 it's proper SSA_NA
On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill 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 useful
Some tests in gcc/testsuite/gcc.target/avr/torture (builtins-2.c, for
e.g.) have -Tavr51-flash1.x specified in dg-options. The tests currently
fail with an unable to open linker script error for that file.
Is that linker script supposed to be checked into source control? Or am
I missing some confi
On Wed, Oct 3, 2012 at 12:07 AM, DJ Delorie 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 closes again..
On Tue, Oct 2, 2012 at 4:19 PM, Walter Lee 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.
>
> Consider
On Thu, Oct 04, 2012 at 10:42:59AM +0200, Richard Guenther wrote:
> On Wed, Oct 3, 2012 at 9:00 PM, Jason Merrill wrote:
> If the result is not needed, are we allowed to remove a call to this
> function?
No. Unless you know the same function has been already called.
> So - what's wrong with usi
Hello Vlad,
Is it intentional that DF_LR_IN and DF_LR_OUT are not updated after
"Updating elimination of equiv for reg..."? I have some checking in
place in process_bb_lives at the end of the function, and it triggers
on the test case. (Checking code and test case is at the end of this
e-mail.) It
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 wrote:
If the result is not needed, are we allowed to remove a call to this
function?
No. Unless you know the same function has been al
On Thu, Oct 04, 2012 at 08:56:03AM -0400, Jason Merrill wrote:
> >I think the plan was for these functions not to return any value,
>
> No, I'm talking about the wrapper function which returns a reference
> to the variable (as in my example).
Sure, but I thought you want to inline the wrapper fun
On Thu, Oct 4, 2012 at 2:56 PM, Jason Merrill 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 wrote:
>>> If the result is not needed, are we allowed to remove a call
Thanks to the help of segher and iant on IRC (thanks again!), I
narrowed my problem down to something I can fully understand and
explain (well I hope).
There is a bad interaction between the IRA handling of subregs and
reload's use of REG_EQUIV annotations. Each one seems to be in its
right to do
Senthil Kumar Selvaraj wrote:
> Some tests in gcc/testsuite/gcc.target/avr/torture (builtins-2.c, for
> e.g.) have -Tavr51-flash1.x specified in dg-options. The tests currently
> fail with an unable to open linker script error for that file.
>
> Is that linker script supposed to be checked into so
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' attribute opened ...).
I thought of a testcase like
int *p = get_me ();
On Thu, Oct 4, 2012 at 6:40 AM, Frederic Riss wrote:
> Thanks to the help of segher and iant on IRC (thanks again!), I
> narrowed my problem down to something I can fully understand and
> explain (well I hope).
>
> There is a bad interaction between the IRA handling of subregs and
> reload's use o
On Thu, Oct 4, 2012 at 5:22 PM, Jason Merrill 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' attribute
On Thu, Oct 4, 2012 at 7:08 PM, Richard Guenther
wrote:
> On Thu, Oct 4, 2012 at 5:22 PM, Jason Merrill 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
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. Is the following an example you would consider to fall
> under your
On 10/04/2012 01:15 PM, Richard Guenther wrote:
That is, I am confused about the distinction you seem to make between
the static variable 'initialized' and the global 'init_count'.
The distinction is that "initialized" is an implementation detail that
once set is never cleared; it is the mecha
On Thu, Oct 4, 2012 at 7:15 PM, Jakub Jelinek 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. Is the fo
On Tue, Oct 2, 2012 at 4:19 PM, Walter Lee 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 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)
__builtin_abort();
int *q = get_me();
if (init_count == x)
> Any suggestion about how I could avoid generating this zero_extension?
Redundant extensions have been a hot topic for some time. The combiner should
catch the local easy cases, we have ree.c for the nonlocal easy cases and Tom
recently posted:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00
> 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...
Is libbacktrace currently functional in gcc trunk and is it expected
to function on darwin? While I could understand it not working on installed
binaries of FSF gcc that were stripped, I would think it should work for
make check in the build tree since all of the debug code should be present
in
On Thu, Oct 4, 2012 at 1:32 PM, Jack Howarth wrote:
>Is libbacktrace currently functional in gcc trunk and is it expected
> to function on darwin? While I could understand it not working on installed
> binaries of FSF gcc that were stripped, I would think it should work for
> make check in the
On Thu, Oct 4, 2012 at 2:18 PM, Eric Botcazou wrote:
>> Any suggestion about how I could avoid generating this zero_extension?
>
> Redundant extensions have been a hot topic for some time. The combiner should
> catch the local easy cases, we have ree.c for the nonlocal easy cases and Tom
> recent
David and i have been talking about this for some time.
what is needed is a real global optimization algorithm. my leaning is
to make do it at the rtl level because that is where everything has been
exposed. but it would be a lot easier in ssa form.
The first step in my opinion is to ask t
Hi Everyone,
This question is mainly for some future submission. Am I allowed to use
"fatal_error (..)"? Mainly, I want to use it in cases where I want to say "if
this error has occurred, I see no reason to go forward with compilation."
Thanks,
Balaji V. Iyer.
On Thu, Oct 4, 2012 at 5:21 PM, Iyer, Balaji V wrote:
> This question is mainly for some future submission. Am I allowed to
> use "fatal_error (..)"? Mainly, I want to use it in cases where I want to say
> "if this error has occurred, I see no reason to go forward with compilation."
Yo
On 12-10-04 8:53 AM, Steven Bosscher wrote:
Hello Vlad,
Is it intentional that DF_LR_IN and DF_LR_OUT are not updated after
"Updating elimination of equiv for reg..."? I have some checking in
place in process_bb_lives at the end of the function, and it triggers
on the test case. (Checking code a
30 matches
Mail list logo
