On 05/30/2012 10:27 PM, Klaus Pedersen wrote:
Thanks for the pointer,
On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov wrote:
Here is an extract from my article from GCC Summit 2004 proceedings.
It is interesting to note that the pass also implicitly does code
selection. Regclass works in
Thanks for the pointer,
On Wed, May 30, 2012 at 2:40 AM, Vladimir Makarov wrote:
> Here is an extract from my article from GCC Summit 2004 proceedings.
>
> It is interesting to note that the pass also implicitly does code
> selection. Regclass works in two passes. On the first pass, it
> defin
On Wed, May 30, 2012 at 1:39 PM, Steve Ellcey wrote:
>
> My question is: When checking the value of TARGET_SYNCI is there anyway
> to tell if the flag was set explicitly by the user or implicitly by
> the compiler? The reason I want to know is that if I build GCC for MIPS
> today and configure w
I have a question about OPTION_DEFAULT_SPECS and default flag settings.
During a MIPS GCC build one can configure with --with-synci or
--without-synci (without is the default) and gcc.config sets with_synci
to either "synci" or "no-synci" as appropriate.
In mips.opt is:
msynci
Ta
On Wed, May 30, 2012 at 9:25 AM, Joseph S. Myers
wrote:
> On Wed, 30 May 2012, H.J. Lu wrote:
>
>> On Linux/i386:
>
>> long int
>
>> On Linux/x86-64:
>>
>> [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -
>
>> int
>
> That's a bug. Not a very serious one - it doesn't affect C++ name
> man
On Wed, 30 May 2012, H.J. Lu wrote:
> On Linux/i386:
> long int
> On Linux/x86-64:
>
> [hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -
> int
That's a bug. Not a very serious one - it doesn't affect C++ name
mangling because wchar_t is a built-in type in C++, with its own mangling
Hi,
On Linux/i386:
[hjl@gnu-29 ~]$ echo __WCHAR_TYPE__ | gcc -E -
# 1 ""
# 1 ""
# 1 ""
# 1 ""
long int
[hjl@gnu-29 ~]$
On Linux/x86-64:
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -
# 1 ""
# 1 ""
# 1 ""
# 1 ""
int
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -mx32 -E -
# 1 ""
# 1 "
On 29 May 2012 17:31, Richard Guenther wrote:
> On Tue, May 29, 2012 at 1:57 PM, Mohamed Shafi wrote:
>> Hi,
>>
>> I am porting a private target in GCC 4.6.3 version. For my target
>> pointer size is 24bits and word size is 32bits. Moreover a byte is
>> 32bit
>>
>> For the testcase gcc.c-torture/
On Fri, 11 May 2012, Greg McGary wrote:
> On 05/11/12 16:00, Greg McGary wrote:
>
> > My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so
> > that I can use insn attributes to identify operand signatures, or should I
> > use
> > another approach?
>
> After some exploration,
Status
==
The GCC 4.7 branch is in regression and documentation fixes only state.
A release candidate for GCC 4.7.1 is scheduled for the beginning of
next week. This is a good time to verify regression status for
your favorite target and to consider to flush your pending 4.7-branch
patches
Joern Rennecke wrote:
> Quoting Georg-Johann Lay:
>
>> The sed -e 's:\r::g' from above that tries to fix line endings has the
>> problem that not all sed implementations are the same, i.e. some just do
>> sed -e 's:r::g' and remove all r's.
>>
>> I searched some time how to accomplish this but did
Thanks Tristan. I have not applied this patch. I will give it a try.
Regards,
Kannan
-Original Message-
From: Tristan Gingold [mailto:ging...@adacore.com]
Sent: Wednesday, May 30, 2012 1:46 PM
To: Mailaripillai, Kannan Jeganathan
Cc: gcc@gcc.gnu.org
Subject: Re: regression due to r187199
Hi,
did you try with this patch:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00970.html
Tristan.
On May 29, 2012, at 12:23 PM, Mailaripillai, Kannan Jeganathan wrote:
> Hi,
>
> This modification (assertion) is causing failure in ia64-hp-hpux11.23:
>
> r187199 | rsandifo | 2012-05-05 10:41:4
13 matches
Mail list logo
