On 4/4/12 11:09 PM, Paolo Carlini wrote:
Hi,
The attached patches fix http://gcc.gnu.org/PR52822, and have been
tested with `make check-c++` on linux-x86_64. The trunk patch applies
and tests cleanly on gcc-4_7-branch. The gcc-4_6-branch patch is
significantly simpler, as Paolo suggested on the
在 2012年4月3日 上午2:51，Anatoly Sokolov 写道：
> Hi.
>
> Ping patch: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00261.html
>>
>> This patch removes obsolete PREFERRED_RELOAD_CLASS macro from the SCORE
>> back end in the GCC and introduces equivalent TARGET_PREFERRED_RELOAD_CLASS
>> target hook.
>>
>>
Hi,
The attached patches fix http://gcc.gnu.org/PR52822, and have been
tested with `make check-c++` on linux-x86_64. The trunk patch applies
and tests cleanly on gcc-4_7-branch. The gcc-4_6-branch patch is
significantly simpler, as Paolo suggested on the bug.
A few small issues.
For the 4.6 ver
Hello Jeff,
>> So the fundamental difference is your version of function_vector is
>> programmer directed.
Yes, programmer will need to assign function vector number manually
during declaration of the attribute.
>> I think you need to investigate further since functions marked with
>> the att
On Wed, Apr 4, 2012 at 5:39 PM, H.J. Lu wrote:
> On Wed, Apr 4, 2012 at 5:07 PM, Teresa Johnson wrote:
>> New patch to avoid LCP stalls based on feedback from earlier patch. I
>> modified
>> H.J.'s old patch to perform the peephole2 to split immediate moves to HImode
>> memory. This is now enabl
On 5 April 2012 15:56, wrote:
> Reviewers: Diego Novillo, jingyu, davidxl,
>
> Message:
> Please take a look at this patch and tell me if it's OK for
> branches/google/gcc-4_6.
>
> Description:
> Backported the following patch from trunk:
>
> 2011-10-07 Andrew Stubbs
>
> gcc/
> * config/
http://codereview.appspot.com/5975045/diff/6001/config/i386/i386.md
File config/i386/i386.md (right):
http://codereview.appspot.com/5975045/diff/6001/config/i386/i386.md#newcode16974
config/i386/i386.md:16974: ;; gets too big.
The comments may need to be updated.
http://codereview.appspot.com/5
On Apr 4, 2012, at 7:56 PM, William J. Schmidt wrote:
> There seems to be tacit agreement that the vector tests should use
> -fno-common on all targets to avoid the recent spate of failures (see
> discussion in 52571 and 52603).
> OK for trunk?
Ok. Any other solution I think will be real work an
Reviewers: Diego Novillo, jingyu, davidxl,
Message:
Please take a look at this patch and tell me if it's OK for
branches/google/gcc-4_6.
Description:
Backported the following patch from trunk:
2011-10-07 Andrew Stubbs
gcc/
* config/arm/predicates.md (shift_amount_operand): Remove co
There seems to be tacit agreement that the vector tests should use
-fno-common on all targets to avoid the recent spate of failures (see
discussion in 52571 and 52603). This patch (proposed by Dominique
D'Humieures) does just that. I agreed to shepherd the patch through.
I've verified that it rem
On Wed, Apr 04, 2012 at 02:39:58PM +1200, Michael Hope wrote:
> On 4 April 2012 10:56, Joseph S. Myers wrote:
> > On Tue, 3 Apr 2012, Michael Hope wrote:
> >
> >> +#define GLIBC_DYNAMIC_LINKER \
> >> + "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> >> + %{mfloat-abi=hard:" GLIBC_DYNA
On 5 April 2012 12:07, Joseph S. Myers wrote:
> On Thu, 5 Apr 2012, Michael Hope wrote:
>
>> > I don't think that's appropriate for ABI issues. If a different dynamic
>> > linker name is specified, GCC should use it unconditionally (and require
>> > new enough glibc or a glibc installation that w
On Wed, Apr 4, 2012 at 5:07 PM, Teresa Johnson wrote:
> New patch to avoid LCP stalls based on feedback from earlier patch. I modified
> H.J.'s old patch to perform the peephole2 to split immediate moves to HImode
> memory. This is now enabled for Core2, Corei7 and Generic.
>
> I verified that thi
On Thu, 5 Apr 2012, Michael Hope wrote:
> > I don't think that's appropriate for ABI issues. If a different dynamic
> > linker name is specified, GCC should use it unconditionally (and require
> > new enough glibc or a glibc installation that was appropriately
> > rearranged).
>
> OK. I want GC
New patch to avoid LCP stalls based on feedback from earlier patch. I modified
H.J.'s old patch to perform the peephole2 to split immediate moves to HImode
memory. This is now enabled for Core2, Corei7 and Generic.
I verified that this enables the splitting to occur in the case that originally
mot
On 4 April 2012 21:06, Joseph S. Myers wrote:
> On Wed, 4 Apr 2012, Michael Hope wrote:
>
>> The tricky one is new GCC with old GLIBC. GCC may have to do a
>> configure time test and fall back to /lib/ld-linux.so.3 if the hard
>> float loader is missing.
>
> I don't think that's appropriate for A
On 4 April 2012 18:54, Jakub Jelinek wrote:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
>> > I did two ports of Mandriva to armv7. One of my choice to use softfp,
>> > and another hardfp port to be compatible with other distros. But other
>> > than a previous armv5 port, there
Chao,
Let's take discussion of MIPS changes to gcc-patches@. Please follow up here.
--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics
On 5/04/2012, at 10:10 AM, Fu, Chao-Ying wrote:
> Maxim Kuvyrkov wrote:
>
>> I encourage you to submit the MIPS Android patches to
>> gcc-patches@. And, as
On Wed, 2012-04-04 at 13:35 +0200, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 10:25 PM, William J. Schmidt
> wrote:
> >
> > Hi Richard,
> >
> > I've revised my patch along these lines; see the new version below.
> > While testing it I realized I could do a better job of reducing the
> > numb
On Mar 26, 2012, at 4:57 PM, Mike Stump wrote:
> On Mar 26, 2012, at 1:03 PM, Richard Sandiford wrote:
>> I think:
>>
>> ...copies of the top bit. Note however that values are neither inherently
>> signed nor inherently unsigned; where necessary, signedness is determined
>> by the rtl operation i
I had a request to backport this patch to the 4.6 branch and since it
is an obvious fix and hasn't caused any problems on the main line I have
gone ahead and checked it in. I tested the patch on the 4.6 branch with
IA64 HP-UX and had no regressions.
FYI: Friday will be my last day at HP but I w
On Tue, 3 Apr 2012, Tom G. Christensen wrote:
> First round of results for 4.7.x
Quite some. On top of your patch, I applied the following to
fix two markup issues.
Thanks,
Gerald
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdoc
On Tue, 3 Apr 2012, Tom G. Christensen wrote:
> Latest results for 4.6.x
>
> -tgc
>
> Testresults for 4.6.3:
> i386-pc-solaris2.8 (2)
> i386-pc-solaris2.10
Thanks, online now.
Gerald
On Wed, 2012-04-04 at 15:08 +0200, Richard Guenther wrote:
> On Wed, Apr 4, 2012 at 2:35 PM, William J. Schmidt
> wrote:
> > On Wed, 2012-04-04 at 13:35 +0200, Richard Guenther wrote:
> >> On Tue, Apr 3, 2012 at 10:25 PM, William J. Schmidt
> >> wrote:
> >> >
> >> >
> >> > On Wed, 2012-03-28 at 1
On Wed, Apr 4, 2012 at 11:53 AM, Andrew Pinski wrote:
> On Wed, Apr 4, 2012 at 11:50 AM, Uros Bizjak wrote:
>> Looking at how other targets implement this check, I don't think that
>> this is a problem at all. This issue only shows on a non-bootstrapped
>> build. A full bootstrap will use correct
On Wed, Apr 4, 2012 at 11:50 AM, Uros Bizjak wrote:
> Looking at how other targets implement this check, I don't think that
> this is a problem at all. This issue only shows on a non-bootstrapped
> build. A full bootstrap will use correct address.
The other place where it shows up is cross compil
On Wed, Apr 4, 2012 at 8:47 PM, H.J. Lu wrote:
> On Wed, Apr 4, 2012 at 11:08 AM, Uros Bizjak wrote:
>> Hello!
>>
>>> This patch defines TRY_EMPTY_VM_SPACE for Linux/x32. Tested on Linux/x32.
>>> OK for trunk?
>>>
>>> 2012-04-03 H.J. Lu
>>>
>>> * config/host-linux.c (TRY_EMPTY_VM_SPACE)
This patch to libgo adds more constants to the syscall package,
continuing the process of making the gccgo version of syscall more like
the one in the master library. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline and 4.7 branch.
Ian
diff -r 34124478458a li
On Wed, Apr 4, 2012 at 11:08 AM, Uros Bizjak wrote:
> Hello!
>
>> This patch defines TRY_EMPTY_VM_SPACE for Linux/x32. Tested on Linux/x32.
>> OK for trunk?
>>
>> 2012-04-03 H.J. Lu
>>
>> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Defined to
>> 0x6000 for x32.
>
> I think we c
2012-04-04 Matt Turner
PR target/35294
* gcc.target/arm/mmx-2.c: New.
---
This patch and 1/2 are tie-ons to
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01269.html
Still waiting on copyright assignment, but please review in the meantime.
Is there anything else I need to do to
2012-04-04 Matt Turner
gcc/
* doc/install.texi: Correct typo "-mno-lsc" -> "-mno-llsc".
---
Still waiting on copyright assignment, but I think this doc patch
is trivial enough to be committed without it.
gcc/doc/install.texi |2 +-
1 files changed, 1 insertions(+), 1 delet
2012-04-04 Matt Turner
gcc/
* doc/extend.texi (__builtin_arm_tinsrb): Add missing second
parameter.
(__builtin_arm_tinsrh): Likewise.
(__builtin_arm_tinsrw): Likewise.
---
This patch and 2/2 are tie-ons to
http://gcc.gnu.org/ml/gcc-patches/2012-02/msg0126
Hello!
> This patch defines TRY_EMPTY_VM_SPACE for Linux/x32. Tested on Linux/x32.
> OK for trunk?
>
> 2012-04-03 H.J. Lu
>
> * config/host-linux.c (TRY_EMPTY_VM_SPACE): Defined to
> 0x6000 for x32.
I think we can simply check for __LP64__, without version check, as is
the cas
Hello!
The fix for PR52689 caused following testsuite failure on
alphaev68-pc-linux-gnu:
Running target unix
FAIL: libmudflap.c++/pass41-frag.cxx (-static) (test for excess errors)
WARNING: libmudflap.c++/pass41-frag.cxx (-static) compilation failed
to produce executable
>From the testsuite log:
On Tue, 3 Apr 2012, Tom G. Christensen wrote:
> Latest results for 4.5.x
>
> -tgc
>
> Testresults for 4.5.3:
> i386-pc-solaris2.8 (2)
Thanks, Tom, this is life.
Gerald
Hello!
> We need to use long long instead of long in gtm_jmpbuf for x86_64 since
> long in x32 is 32bits. OK for trunk and 4.7 branch?
>
> 2012-04-03 H.J. Lu
>
> PR libitm/52854
> * config/x86/target.h (gtm_jmpbuf): Replace long with long long
> for x86-64.
OK.
Thanks,
Uros
On 04/04/2012 10:33 AM, Richard Guenther wrote:
On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod wrote:
This is a WIP... that fntype fields is there for simplicity.. and no...
you can do a 1 byte atomic operation on a full word object if you want by
Oh, so you rather need a size or a mode speci
On 04/04/2012 04:07 PM, Ian Lance Taylor wrote:
> Tristan Gingold writes:
>
>> > Would something like that be acceptable ?
>> > I have just checked that I can still build gcc with that patch. If you
>> > like this approach I will properly submit a patch.
> Thanks.
>
> You should also test tha
On Apr 4, 2012, at 5:07 PM, Ian Lance Taylor wrote:
> Tristan Gingold writes:
>
>> Would something like that be acceptable ?
>> I have just checked that I can still build gcc with that patch. If you like
>> this approach I will properly submit a patch.
>
> Thanks.
>
> You should also test t
Tristan Gingold writes:
> Would something like that be acceptable ?
> I have just checked that I can still build gcc with that patch. If you like
> this approach I will properly submit a patch.
Thanks.
You should also test that gdb continues to build with this patch.
I guess the question her
On Apr 4, 2012, at 3:58 PM, Ian Lance Taylor wrote:
> Tristan Gingold writes:
>
>> include/
>> 2012-04-04 Tristan Gingold
>>
>> * splay-tree.h: Use LLP64 definitions of libi_shostptr_t and
>> libi_hostptr_t for VMS with 64bit pointers.
>
> I was strongly opposed to adding a _WIN6
On Wed, 4 Apr 2012, Martin Jambor wrote:
> Hi everyone, especially Richi and Eric,
>
> I'd like to know what is your attitude to changing SRA's
> build_ref_for_model to what it once looked like, so that it produces
> COMPONENT_REFs only for bit-fields. The non-bit field handling was
> added in o
My patch for return type deduction forgot to update the fntype local
variable in finish_function, leading to a bogus warning about a missing
return statement.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 12a282edca78579074f5f4180cd2dce1edebd2bf
Author: Jason Merrill
Date: Wed Apr 4
On Wed, Apr 4, 2012 at 4:32 PM, Richard Henderson wrote:
> On 04/04/2012 09:46 AM, Richard Guenther wrote:
>> If that is the only reason you can return two values by using a complex
>> or vector type (that would be only an IL implementation detail as far
>> as I can see).
>> We use that trick to g
On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod wrote:
> On 04/04/2012 04:45 AM, Richard Guenther wrote:
>>
>>
>> The fact that you need to touch every place that wants to look at memory
>> accesses shows that you are doing it wrong. Instead my plan was to
>> force _all_ memory accesses to GIMPLE_
On 04/04/2012 09:46 AM, Richard Guenther wrote:
> If that is the only reason you can return two values by using a complex
> or vector type (that would be only an IL implementation detail as far
> as I can see).
> We use that trick to get sincos () "sane" in our IL as well.
That would work if the t
On 04/04/2012 04:45 AM, Richard Guenther wrote:
The fact that you need to touch every place that wants to look at memory
accesses shows that you are doing it wrong. Instead my plan was to
force _all_ memory accesses to GIMPLE_ASSIGNs (yes, including those
we have now in calls). You're making a
Hi everyone, especially Richi and Eric,
I'd like to know what is your attitude to changing SRA's
build_ref_for_model to what it once looked like, so that it produces
COMPONENT_REFs only for bit-fields. The non-bit field handling was
added in order to work-around problems when expanding non-aligne
Im not sure what happened to my original reply, so I'll resend it..
On 04/04/2012 09:28 AM, Andrew MacLeod wrote:
On 04/04/2012 04:45 AM, Richard Guenther wrote:
The fact that you need to touch every place that wants to look at memory
accesses shows that you are doing it wrong. Instead my pla
Tristan Gingold writes:
> include/
> 2012-04-04 Tristan Gingold
>
> * splay-tree.h: Use LLP64 definitions of libi_shostptr_t and
> libi_hostptr_t for VMS with 64bit pointers.
I was strongly opposed to adding a _WIN64 define here and this is just
making it worse.
Ian
> --- a/inc
On 04/04/2012 09:28 AM, Andrew MacLeod wrote:
I wasn't excited about creating a new gimple statement, but it seemed
the best solution to my issues. In the end, I think this works very
cleanly. Im certainly open to better solutions. If there is a plan to
change gimple in some way that this d
Several passes needlessly cleanup EH after gsi_remove because they do
not know whether the stmt was removed from EH regions. The following
patch returns this information from gsi_remove and adjusts all users
I could find appropriately.
Bootstrapped and tested on x86_64-unknown-linux-gnu, testing
Hi Eric,
> On 04/04/12 12:24, Eric Botcazou wrote:
You probably need to adjust gcc.dg/stack-usage-1.c too.
s/flag_stack_usage/flag_stack_usage_info/
Thanks for the corrections. Revised patch attached.
OK for mainline/4.7 branch ?
Cheers
Nick
gcc/ChangeLog
2012-04-04 Nick Clifton
On Wed, Apr 4, 2012 at 3:26 PM, Richard Henderson wrote:
> On 04/04/2012 04:45 AM, Richard Guenther wrote:
>> I suppose you do not want to use builtins because for primitive types you
>> end up with multiple statements for something "atomic"?
>
> The primary motivation is that builtins cannot retu
Ok.
r~
On 04/04/2012 03:34 AM, Tristan Gingold wrote:
>
> I'd like to ping this patch as it fixed an ICE visible on both ia64 linux and
> ia64 openvms.
>
> Tristan.
>
> On Mar 6, 2012, at 11:07 PM, Eric Botcazou wrote:
>
>> We have a regression on one of the testcases of our internal tests
On 04/04/2012 04:45 AM, Richard Guenther wrote:
> I suppose you do not want to use builtins because for primitive types you
> end up with multiple statements for something "atomic"?
The primary motivation is that builtins cannot return two values.
Our current builtin returns one of the two values
Hi,
On Tue, Apr 03, 2012 at 11:02:11AM +0200, Eric Botcazou wrote:
> > Yeah, that sounds reasonable.
>
> There is a further subtlety in the second temp allocation when the expression
> doesn't use the alias set of its type. In that case, we cannot pass the type
> to set_mem_attributes. In fac
On Wed, Apr 4, 2012 at 2:35 PM, William J. Schmidt
wrote:
> On Wed, 2012-04-04 at 13:35 +0200, Richard Guenther wrote:
>> On Tue, Apr 3, 2012 at 10:25 PM, William J. Schmidt
>> wrote:
>> >
>> >
>> > On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
>> >> On Tue, Mar 6, 2012 at 9:49 PM, W
On Wed, 2012-04-04 at 13:35 +0200, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 10:25 PM, William J. Schmidt
> wrote:
> >
> >
> > On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
> >> On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
> >> wrote:
> >> > Hi,
> >> >
> >> > This is a r
On Wed, 4 Apr 2012 09:06:05 + (UTC)
"Joseph S. Myers" wrote:
> On Wed, 4 Apr 2012, Michael Hope wrote:
>
> > The tricky one is new GCC with old GLIBC. GCC may have to do a
> > configure time test and fall back to /lib/ld-linux.so.3 if the hard
> > float loader is missing.
>
> I don't think
On Tue, Apr 3, 2012 at 10:25 PM, William J. Schmidt
wrote:
>
>
> On Wed, 2012-03-28 at 15:57 +0200, Richard Guenther wrote:
>> On Tue, Mar 6, 2012 at 9:49 PM, William J. Schmidt
>> wrote:
>> > Hi,
>> >
>> > This is a re-post of the patch I posted for comments in January to
>> > address http://gcc
It turns out I've been over-eager removing Tru64 UNIX support from
libjava, breaking at least the HP-UX 11.00 build. The following patch
fixes this, tested by Dave Anglin on hppa2.0w-hp-hpux11.00 and
bootstrapped on i386-pc-solaris2.11.
Ok for mainline?
Thanks.
Rainer
2012-03-21 Raine
On 4 April 2012 13:05, Christian Bruel wrote:
>
>
> The testscase was part of the attached patch, along with the ChangeLog
> entries
You are right! Sorry, I may have been looking at the wrong place.
> It was bootstrapped and regtested for C and C++ on x86 (that was in bugzilla
> comment #22), so
On Tue, 3 Apr 2012, Tom G. Christensen wrote:
> Testresults for 4.4.7:
> powerpc-apple-darwin8.11.0
Thanks, Tom!
Gerald
> Please could I apply the patch below to the RL78 port ? It adds
> support for generating stack use info with the -fstack-usage option.
You probably need to adjust gcc.dg/stack-usage-1.c too.
> Index: gcc/config/rl78/rl78.c
> =
On Wed, Apr 4, 2012 at 12:11, Tobias Burnus
wrote:
> Janne Blomqvist wrote:
>> the attached patch implements a few fixes and cleanups for the MOD and
>> MODULO intrinsics.
>
>> The patch adds notes to the documentation about the usage of fmod, so
>> users interested in corner-case behavior can loo
On Wed, Apr 04, 2012 at 10:25:39AM +0100, Richard Sandiford wrote:
> With the loop thing, do you mean that you're seeing too many HIGHs
> being hoisted?
No, nothing as complicated as that. In a lot of cases, any hoisting
of the high part is bad, because the linker nops out the high part and
edits
On 04/04/2012 11:38 AM, Manuel López-Ibáñez wrote:
Hi Christian,
You have to add the testcases from both PR52283 and PR37985, and an
appropriate Changelog, and bootstrap+regression test everything and
double-check that the new testcases don't fail and no old testcases
fail with the patch (by co
This fixes LTO profiledbootstrap. tracer tail-duplicates loop
headers; that is not profitable and it makes loops have multiple
entries which inhibits further optimization. The following
patch cures that.
LTO profiledbootstrapped on x86_64-unknown-linux-gnu, regular
testing in progress.
Richard
Hi DJ,
Please could I apply the patch below to the RL78 port ? It adds
support for generating stack use info with the -fstack-usage option.
Also - may I apply this patch to the 4.7 branch as well please ?
Cheers
Nick
gcc/ChangeLog
2012-04-04 Nick Clifton
* config/rl78/rl78.
On Apr 4, 2012, at 11:26 AM, Pedro Alves wrote:
> On 04/04/2012 09:55 AM, Tristan Gingold wrote:
>
>> Hi,
>>
>> unfortunately VMS (when 64bit pointers are used - which is nice for gcc) is
>> also an LLP64 platform.
>> So I need to follow to Win64 way in splay-tree.h.
>
>
> Doesn't VMS gcc de
Hi Christian,
You have to add the testcases from both PR52283 and PR37985, and an
appropriate Changelog, and bootstrap+regression test everything and
double-check that the new testcases don't fail and no old testcases
fail with the patch (by comparing with the testcases that fail without
the patch
Dear Tobias,
This is OK for trunk - thanks for the patch.
Cheers
Paul
On Tue, Apr 3, 2012 at 11:18 PM, Tobias Burnus wrote:
> Dear all,
>
> the attached patch only sets TREE_PUBLIC for module variables and module
> procedures which have neither the PRIVATE attribute nor a C-binding label.
> Se
On 04/04/2012 09:55 AM, Tristan Gingold wrote:
> Hi,
>
> unfortunately VMS (when 64bit pointers are used - which is nice for gcc) is
> also an LLP64 platform.
> So I need to follow to Win64 way in splay-tree.h.
Doesn't VMS gcc define __LP64__/__LLP64__? Then we could for example:
#if !(defin
Alan Modra writes:
> On Tue, Apr 03, 2012 at 07:49:04PM +0100, Richard Sandiford wrote:
>> Alan Modra writes:
>> > Now that we are back in stage1, I'd like to apply
>> > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00304.html, a change to
>> > toc reference rtl in order to properly specify r2 dep
On Wed, 4 Apr 2012, Jakub Jelinek wrote:
> If the agreement is that arm 32-bit softfp really needs to be installable
> alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
> like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
> various MIPS variants) an
Janne Blomqvist wrote:
> the attached patch implements a few fixes and cleanups for the MOD and
> MODULO intrinsics.
> The patch adds notes to the documentation about the usage of fmod, so
> users interested in corner-case behavior can look up how that function
> is supposed to behave on their tar
On Wed, 4 Apr 2012, Michael Hope wrote:
> The tricky one is new GCC with old GLIBC. GCC may have to do a
> configure time test and fall back to /lib/ld-linux.so.3 if the hard
> float loader is missing.
I don't think that's appropriate for ABI issues. If a different dynamic
linker name is speci
On Wed, Apr 4, 2012 at 9:51 AM, Arnaud Charlet wrote:
>> Arno, do you have objections to me applying the attached patch to the 4.5
>> branch? It makes it possible to build (and bootstrap) the Ada compiler on
>> the
>> 4.5 branch (oldest supported branch) with the 4.6 compiler, which is now the
>
On 04/03/2012 11:53 AM, Richard Earnshaw wrote:
>> Now, I wonder why the dynamic linker cannot figure out the ABI itself
>> > by means of using ELF flags or so?
>> >
> There are no ELF flags for this in executables. The attributes only
> apply to object files and anyway they are too expensive to
Hi,
unfortunately VMS (when 64bit pointers are used - which is nice for gcc) is
also an LLP64 platform.
So I need to follow to Win64 way in splay-tree.h.
Tested manually by build (and using) gcc on ia64-hp-openvms.
Ok for trunk ?
Tristan.
include/
2012-04-04 Tristan Gingold
* spla
On Tue, Apr 3, 2012 at 9:40 PM, Andrew MacLeod wrote:
> Here is my first step in promoting the __atomic builtins into gimple
> statements. I originally planned this as tree codes, but when prototyped it
> became obvious that a gimple statement was a far superior solution since we
> also need to d
Hi,
I am committing this patch (as obvious) to adjust the style of the VMS specific
function to_ptr32.
Tested by building for ia64-hp-openvms.
Tristan.
libiberty/
2012-04-04 Tristan Gingold
* pex-unix.c (to_ptr32): Fix style.
Index: pex-unix.c
=
On Apr 4, 2012, at 10:18 AM, Richard Guenther wrote:
> On Wed, 4 Apr 2012, Tristan Gingold wrote:
>
>> Hi,
>>
>> this patch fixes a build time failure on VMS (while compiling Ada RTS file
>> i-cstrin.adb) due to the use of short pointers:
>>
>> i-cstrin.adb: In function 'Interfaces.C.Strings.
> It is a bad idiom, given that we already had >= 10 __GNUC_MINOR__ and it
> is possible we'll have 4.10 as well.
> E.g. __GNUC_PREREQ macro in glibc shifts left major by 16, but even
> multiplying by 100 instead of 10 is better.
OK, we'll change the idiom on mainline.
--
Eric Botcazou
Oleg Endo wrote:
> The attached patch restructures the move insn displacement calculations
> a bit more. The idea is to have the displacement addressing decision
> making logic in a few simple functions and then re-use those in other
> places, as opposed to having multiple special cases.
>
> Tes
On Wed, 4 Apr 2012, Tristan Gingold wrote:
> Hi,
>
> this patch fixes a build time failure on VMS (while compiling Ada RTS file
> i-cstrin.adb) due to the use of short pointers:
>
> i-cstrin.adb: In function 'Interfaces.C.Strings.To_Chars_Ptr':
> i-cstrin.adb:236:8: error: unrecognizable insn:
Hello,
Is it OK to push the cleaning of TREE_NO_WARNING to fix the constant
expressions errors discrepancies, as discussed in bugzilla #52283, now
that the trunk is open ?
Many thanks,
2012-03-29 Manuel López-Ibáñez
PR c/52283/37985
* stmt.c (warn_if_unused_value): Skip NOP_EXPR.
On Wed, Apr 04, 2012 at 10:08:50AM +0200, Eric Botcazou wrote:
> > Shouldn't this be * 100 and > 405 ? I mean, we already had GCC
> > 2.95, 2.96, 2.97 and 20 + 95 is > 45...
>
> This idiom is the one already used in tracebak.c for example. Would that
> really matter in practice?
It is a bad id
Hi,
this patch fixes a build time failure on VMS (while compiling Ada RTS file
i-cstrin.adb) due to the use of short pointers:
i-cstrin.adb: In function 'Interfaces.C.Strings.To_Chars_Ptr':
i-cstrin.adb:236:8: error: unrecognizable insn:
(insn 80 79 81 13 (set (reg:SI 384)
(const_int 429
> Well, we don't guarantee such compatibility in general,
> so I'd like to make it clear that people shouldn't expect this combination
> to work, and if more complex patches are submitted, we'll likely NOT
> integrate them.
That's mainly for GCC developers; without this, it will be a pain to keep
> Shouldn't this be * 100 and > 405 ? I mean, we already had GCC
> 2.95, 2.96, 2.97 and 20 + 95 is > 45...
This idiom is the one already used in tracebak.c for example. Would that
really matter in practice?
--
Eric Botcazou
On 03.04.2012 13:36, Jakub Jelinek wrote:
On Mon, Apr 02, 2012 at 06:56:25PM +0400, Andrey Belevantsev wrote:
After Richi's RTL generation related cleanups went it, the extra
cleanup_cfg call was added so we are no longer lucky to have the
proper fallthru edge in this case. The PR trail has the
On Apr 3, 2012, at 5:53 PM, Tobias Burnus wrote:
>
> On 04/03/2012 02:42 PM, Tristan Gingold wrote:
>> The simplest path is simply to reverse the include order in libgfortran.h.
>> I know that this is somewhat VMS specific, and I welcome better ideas.
>
> Well, changing the order is not that
> Arno, do you have objections to me applying the attached patch to the 4.5
> branch? It makes it possible to build (and bootstrap) the Ada compiler on the
> 4.5 branch (oldest supported branch) with the 4.6 compiler, which is now the
> system compiler in recent Linux distributions.
Well, we don'
On Wed, Apr 04, 2012 at 09:36:52AM +0200, Eric Botcazou wrote:
> --- init.c(revision 186078)
> +++ init.c(working copy)
> @@ -86,6 +86,9 @@
>
> /* Global values computed by the binder. */
> int __gl_main_priority = -1;
> +#if (__GNUC__ * 10 + __GNUC_MINOR__ > 45)
Sho
Arno, do you have objections to me applying the attached patch to the 4.5
branch? It makes it possible to build (and bootstrap) the Ada compiler on the
4.5 branch (oldest supported branch) with the 4.6 compiler, which is now the
system compiler in recent Linux distributions.
The patch backport
I'd like to ping this patch as it fixed an ICE visible on both ia64 linux and
ia64 openvms.
Tristan.
On Mar 6, 2012, at 11:07 PM, Eric Botcazou wrote:
> We have a regression on one of the testcases of our internal testsuite on
> IA-64
> with a 4.7-based compiler, which is of the form:
>
> t
Hi,
I'd like to ping this patch, as it hasn't been reviewed for 4 weeks.
Tristan.
On Mar 6, 2012, at 11:08 PM, Eric Botcazou wrote:
> This at last implements static stack checking for the IA-64, i.e. stack
> checking of the static part of the frame, and makes it possible to pass the
> entire
99 matches
Mail list logo
