On Thu, 21 Jun 2012, Ramana Radhakrishnan wrote:
> On 10 April 2012 10:11, Ramana Radhakrishnan
> wrote:
> >>> The patch with correct configure output is ok.
> >>
> >> Thanks - this is what I committed.
> >
> > Is this something that can be considered for backporting to release
> > branches ? Thi
On 10 April 2012 10:11, Ramana Radhakrishnan
wrote:
>>> The patch with correct configure output is ok.
>>
>> Thanks - this is what I committed.
>
> Is this something that can be considered for backporting to release
> branches ? This patch technically doesn't fix a regression but brings
> in line
>> The patch with correct configure output is ok.
>
> Thanks - this is what I committed.
Is this something that can be considered for backporting to release
branches ? This patch technically doesn't fix a regression but brings
in line behaviour of the normal bootstrap for %gnu_unique_object ?
htt
On 14 March 2012 15:52, Paolo Bonzini wrote:
> Il 14/03/2012 16:37, Ramana Radhakrishnan ha scritto:
>> Empirically I spotted this odd behaviour with
>> gcc_GAS_CHECK_FEATURE and comments - Attached are the 2 alternate
>> patches that I tried and the difference in the configure scripts
>> themsel
Paolo Bonzini writes:
> Yes, the # comment is actually part of the macro argument. If you want
> to write a "real" comment (i.e. at the m4 rather than shell level) use
> "dnl" instead of "#".
Actually both are part of the macro argument and act like comment
introducers at the m4 level, but they
Il 14/03/2012 16:37, Ramana Radhakrishnan ha scritto:
> Empirically I spotted this odd behaviour with
> gcc_GAS_CHECK_FEATURE and comments - Attached are the 2 alternate
> patches that I tried and the difference in the configure scripts
> themselves . I am no m4 expert but it does look like the m4
On 12 March 2012 18:10, DJ Delorie wrote:
>
> Looks OK to me.
I was about to commit this into my svn checkout and then realized the
patch p4 didn't have the changes to configure - So I regenerated it
again and then began a journey into the depths of m4 and autoconf for
a bit before I gave up. Emp
Looks OK to me.
On 10 March 2012 00:39, DJ Delorie wrote:
>
>> > Ping - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00549.html
>>
>> And now really add Paolo and DJ.
>
> + [.type foo, '$target_type_format_char'gnu_unique_object],,
>
> This un-quoting looks incorrect if you don't know what's going on
> under t
> > Ping - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00549.html
>
> And now really add Paolo and DJ.
+ [.type foo, '$target_type_format_char'gnu_unique_object],,
This un-quoting looks incorrect if you don't know what's going on
under the hood, but I don't see a clean way around it. A sui
> Ping - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00549.html
And now really add Paolo and DJ.
Ramana
>
> regards,
> Ramana
>
>
>>
>> regards,
>> Ramana
>>
>>
>> 2012-03-07 Ramana Radhakrishnan
>>
>> * config.gcc (target_type_format_char): New. Document it. Set it for
>> arm
>
> Ok ?
Adjusting subject line and adding build machinery maintainer to comment -
Ping - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00549.html
regards,
Ramana
>
> regards,
> Ramana
>
>
> 2012-03-07 Ramana Radhakrishnan
>
> * config.gcc (target_type_format_char): New. Document it.
Hi,
While investigating a report for odd behaviour with a C++ program, I
discovered that the automatic checking for gnu_unique_object is broken
during
bootstrap for arm-linux-gnueabi targets because on ARM '@' is a
comment character for the assembler.
I do realize this can be worked around with t
13 matches
Mail list logo