On Sun, Mar 25, 2012 at 2:42 PM, Bin.Cheng wrote:
> Hi,
> In tree-complex.c's function expand_complex_comparison, gcc just
> expand comparison on complex
> operands into comparisons on inner type, like:
>
> D.5375_17 = REALPART_EXPR ;
> D.5376_18 = IMAGPART_EXPR ;
> g2.1_5 = COMPLEX_EXPR ;
> D
Thank you sir for your important feedback and suggestion. I'll modify
my proposal and inform you about it very soon.
On 26 March 2012 09:41, Iyer, Balaji V wrote:
>
>
> -Original Message-
> From: Subrata Biswas [mailto:subrata.i...@gmail.com]
> Sent: Sunday, March 25, 2012 12:22 PM
> To:
Hello,
I am porting my backend to GCC47 and during libgcc configuration I get:
configure:4511: checking whether to use setjmp/longjmp exceptions
configure:: /home/pm18/p4ws/pm18_binutils/bc/main/result/linux/
intermediate/FirmwareGcc47Package/./gcc/xgcc -B/home/pm18/p4ws/
pm18_binutils/bc/main/res
On 2012-03-22 16:29:00 +, Joseph S. Myers wrote:
> On Thu, 22 Mar 2012, Vincent Lefevre wrote:
> > For the same reason, if the user chose long double instead of
> > double, this may be because he wanted more precision than double.
>
> You mean range? IBM long double provides more precision, b
On 25/03/2012 11:55, Oleg Endo wrote:
Please reply in CC to the GCC mailing list, so others can follow the
discussion.
On Sun, 2012-03-25 at 09:21 +0530, Subrata Biswas wrote:
On 25 March 2012 03:59, Oleg Endo wrote:
I might be misunderstanding the idea...
Let's assume you've got a program t
Thank You David for your suggestion and feedback. I'll let you know my
final proposal (after the modification based on your feedback and my
latest study) as early as possible.
I would like to request everyone in this community to kindly enrich me
with more suggestions and guidance to prepare my fi
Hi,
On Mon, Mar 26, 2012 at 01:34:55AM +, Iyer, Balaji V wrote:
> Hello Everyone,
> I am currently trying to take certain functions (marked by certain
> attributes) and create vector version along with the scalar versions
> of the function. For example, let's say I have a function my_add
> tha
On 03/13/2012 12:41 AM, Andreas Schwab wrote:
> Andreas Schwab writes:
>
>> Ian Lance Taylor writes:
>>
>>> Andreas Schwab writes:
>>>
Ian Lance Taylor writes:
> But it also looks like the pattern should use a match_scratch.
It is also used as input in operand 2.
>>>
>>
On Sun, 2012-03-25 at 22:10 +0200, Basile Starynkevitch wrote:
> On Sun, 25 Mar 2012 20:30:31 +0200
> Basile Starynkevitch wrote:
> >
> > How can a plugin know that cc1 was compiled with C++ or just with
> > plain C? I don't really know (we do have GCCPLUGIN_VERSION, but should a
> > plugin use
Bernd Schmidt writes:
> Does 4.7 still have the failure at all?
Yes, see PR52573.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote:
> On 2012-03-22 16:29:00 +, Joseph S. Myers wrote:
> > On Thu, 22 Mar 2012, Vincent Lefevre wrote:
> > > For the same reason, if the user chose long double instead of
> > > double, this may be because he wanted more precision than double
On Mon, 26 Mar 2012, David Malcolm wrote:
> Presumably a fix would be for the plugin's configuration phase to have a
> test that tries to build a test plugin and run it, first building with a
> C compiler, then a C++ compiler, and decides what compiler the real
> plugin should be built with accord
On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt wrote:
> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>> And is there any reason (other than it doesn't seem to have been done
>> before) to believe PSImode is the wrong way to support a
>> general-purpose 20-bit integral type in gcc?
>
> If you're usin
> Does 4.7 still have the failure at all? I've checked with the 4.6
> branch, and regrename gets confused because there's a REG_DEAD note for
> the register, and another REG_UNUSED for the same reg. As far as I
> remember, it used to be the case that there should not be a REG_DEAD
> note for a regi
On 03/26/2012 07:37 PM, Eric Botcazou wrote:
>> Does 4.7 still have the failure at all? I've checked with the 4.6
>> branch, and regrename gets confused because there's a REG_DEAD note for
>> the register, and another REG_UNUSED for the same reg. As far as I
>> remember, it used to be the case that
> Here, I think the problem is that we have an in-out operand whose chain
> is closed prematurely due to a bogus REG_DEAD note which shouldn't be
> there for a register set in the instruction.
IIRC I didn't see a REG_DEAD note, but I might be misremembering.
--
Eric Botcazou
"Paulo J. Matos" writes:
> I am porting my backend to GCC47 and during libgcc configuration I get:
> configure:4511: checking whether to use setjmp/longjmp exceptions
> configure:: /home/pm18/p4ws/pm18_binutils/bc/main/result/linux/
> intermediate/FirmwareGcc47Package/./gcc/xgcc -B/home/pm18/p4ws
On Mon, 2012-03-26 at 17:07 +, Joseph S. Myers wrote:
> On Mon, 26 Mar 2012, David Malcolm wrote:
>
> > Presumably a fix would be for the plugin's configuration phase to have a
> > test that tries to build a test plugin and run it, first building with a
> > C compiler, then a C++ compiler, and
On Mon, 26 Mar 2012 13:13:22 -0400
David Malcolm wrote:
> On Mon, 2012-03-26 at 17:07 +, Joseph S. Myers wrote:
> > On Mon, 26 Mar 2012, David Malcolm wrote:
> >
>
> I suppose now is a bad time to mention that my python plugin *doesn't*
> use autoconf for its configure script - I didn't wan
On 03/25/2012 11:31 PM, Diego Novillo wrote:
I just stumbled into this video animation showing a graphical
representation of GCC's source tree over the years.
It is a bit long, but it's amusing to recognize big events in GCC
(addition of Java, Ada, tree-ssa, etc) over time.
http://www.youtube.
Hi,
Le 26 mars 2012 à 20:33, Basile Starynkevitch a écrit :
>
> And I still think that GCC 4.7.1 should be able to tell by itself if it was
> compiled by C
> or by C++.
>
Actually you can already find it for every GCC version you are interested in
(4.6.x and 4.7.x), with very little logic, a
Hello,
This patch is one way to address PR44982. I see no good reason to
cgraph_finalize_compilation_unit if there were parse errors. As Richi
already pointed out, GCC traditionally has proceeded after parse
errors to preserve warnings and errors we generate from the middle-end
and during semantic
On Wed, 2012-03-21 at 15:12 -0700, Ian Lance Taylor wrote:
> I can understand why you are doing this. However, you should be aware
> that the compiler internals changed significantly in version 4.0. Time
> spent working on detailed optimizations of gcc 3.4 is almost certainly
> time wasted. Walk
I have another question along the same lines. Is it possible to tell gcc to
never delete a certain function even if it is never called in the executable?
Any help is greatly appreciated!
Thanks,
Balaji V. Iyer.
-Original Message-
From: Martin Jambor [mailto:mjam...@suse.cz]
Sent: Mond
On Mon, 2012-03-26 at 22:51 +, Iyer, Balaji V wrote:
> I have another question along the same lines. Is it possible to tell
> gcc to never delete a certain function even if it is never called in
> the executable?
>
"__attribute__ ((used))" maybe?
Cheers,
Oleg
On Mon, 26 Mar 2012 22:34:22 +0200
Romain Geissler wrote:
> Hi,
> You'll find something like this :
>
> /* Define if building with C++. */
> #ifndef USED_FOR_TARGET
> #define ENABLE_BUILD_WITH_CXX 1
> #endif
>
> So that's it, you already got all you need for all version.
>
I did mention ENABL
On Mon, Mar 26, 2012 at 3:27 PM, Richard Guenther
wrote:
> On Sun, Mar 25, 2012 at 2:42 PM, Bin.Cheng wrote:
>> Hi,
>> In tree-complex.c's function expand_complex_comparison, gcc just
>> expand comparison on complex
>> operands into comparisons on inner type, like:
>>
>> D.5375_17 = REALPART_EXP
27 matches
Mail list logo
