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 is not much else of Mandriva arm,
> > so, it woul
> On 04/01/2012 12:38 PM, Diego Novillo wrote:
>> I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben,
>> any opinions on PR 52796 and what should we do for gcc-4_6-branch?
>
> Fixed. :)
I'm so relieved, seriously.
Thanks,
Paolo
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_DYNAMIC_LINKER_HARD_FLOAT "} \
>> + %{!mfloat-abi=hard:%{!mhard-float:" GLI
On 04/01/2012 12:38 PM, Diego Novillo wrote:
I'm not sure it makes sense to propose it for gcc-4_6-branch. Jason/Ben,
any opinions on PR 52796 and what should we do for gcc-4_6-branch?
Fixed. :)
Jason
2012/4/4 Paulo César Pereira de Andrade
:
> Em 3 de abril de 2012 20:48, Michael Hope escreveu:
>> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
>> None have been released yet. Here's my understanding:
>>
>> Fedora 17:
>> * ARM is a secondary architecture
>> * Alpha 1 rel
On Tue, Apr 03, 2012 at 01:05:08PM -0400, David Edelsohn wrote:
> On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque wrote:
> >
> > On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
> >> Thanks a lot for following up on this one. Coincidentally, I was just
> >> about to submit the alternate approach
Hi,
This patch defines TRY_EMPTY_VM_SPACE for Linux/x32. Tested on Linux/x32.
OK for trunk?
Thanks.
H.J.
---
2012-04-03 H.J. Lu
* config/host-linux.c (TRY_EMPTY_VM_SPACE): Defined to
0x6000 for x32.
diff --git a/gcc/config/host-linux.c b/gcc/config/host-linux.c
index 9
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 dependencies. More
> > comme
Hi,
As the testcase in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857
shows, for
(subreg:SI (plus:DI (reg/f:DI 16 argp)
(const_int -128 [0xff80])) 0)
we generates DW_OP_GNU_regval_type with INVALID_REGNUM. This patch
checks dbx_reg_number for INVALID_REGNUM before using
Em 3 de abril de 2012 20:48, Michael Hope escreveu:
> On 4 April 2012 11:11, Jakub Jelinek wrote:
>> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>>> >> The subdirectories could be called fred and jim and it would still work.
>>> >> The only thing required is that this part of t
OK for google-4_6
Dehao
On Wed, Apr 4, 2012 at 8:36 AM, Rong Xu wrote:
> Hi,
>
> Google branch only.
>
> Backout this change due to performance regression.
>
> Tested with bootstrap.
>
> Thanks,
>
> -Rong
>
> 2012-04-03 Rong Xu
>
> Google ref b/6284235.
> Manually remove upstre
OK for google-4_6 branch.
-Rong
On Tue, Apr 3, 2012 at 5:30 PM, Dehao Chen wrote:
>
> Revert r185948, which causes regression to major applications.
>
> Bootstrapped.
>
> OK for google-4_6?
>
> Thanks,
> Dehao
>
> Index: gcc/testsuite/gcc.dg/predict-3.c
>
Hi,
Google branch only.
Backout this change due to performance regression.
Tested with bootstrap.
Thanks,
-Rong
2012-04-03 Rong Xu
Google ref b/6284235.
Manually remove upstream patch for PR49642 and it's
test case due to performance regression.
Revert r185948, which causes regression to major applications.
Bootstrapped.
OK for google-4_6?
Thanks,
Dehao
Index: gcc/testsuite/gcc.dg/predict-3.c
===
--- gcc/testsuite/gcc.dg/predict-3.c(revision 186128)
+++ gcc/testsuite/g
On Wed, Apr 4, 2012 at 12:48 AM, Michael Hope wrote:
> On 4 April 2012 11:11, Jakub Jelinek wrote:
>> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>>> >> The subdirectories could be called fred and jim and it would still work.
>>> >> The only thing required is that this part of
On 4 April 2012 11:11, Jakub Jelinek wrote:
> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>> >> The subdirectories could be called fred and jim and it would still work.
>> >> The only thing required is that this part of the naming scheme be
>> >> agreed amongst the distros.
>> >
This patch to libgo fixes the support for GNU/Linux netlink code, used
to retrieve network interfaces, for big-endian systems. Bootstrapped
and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to
mainline and 4.7 branch.
Ian
diff -r a2de1f2e5bf8 libgo/Makefile.am
--- a/libgo/Makefile.am
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.
The test is still inadequate, but given th
On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
> >> The subdirectories could be called fred and jim and it would still work.
> >> The only thing required is that this part of the naming scheme be
> >> agreed amongst the distros.
> >>
> >> This looks to me like it's turning into a bi
On Tue, 3 Apr 2012, Michael Hope wrote:
> +#define GLIBC_DYNAMIC_LINKER \
> + "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +%{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
(a) -mhard-float is
A parenthesized initializer containing a pack expansion that expands to
0 elements is treated as value-initialization. We were handling that
properly for variable initializers, but not for mem-initializers in
constructors.
Tested x86_64-pc-linux-gnu, applying to trunk, 4.7 and 4.6.
commit 58c
I've just committed the patch in
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01970.html
on trunk.
Regards,
kaz
Hi,
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.
Tested against rev 185893 wi
On 4 April 2012 04:17, Andrew Haley wrote:
> On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
>> On 03/04/12 12:01, Jakub Jelinek wrote:
>>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
If, so then there's only one way to sort out this mess.
/lib/arm-linux-gnueab
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. Seemingly, only NAG f95 does this for module variables and none
of my compilers does this for module procedures.
The main effect of th
On Apr 3, 2012, at 12:57 PM, DJ Delorie wrote:
>> Did you ever dig up the Apple test cases from the APPLE LOCAL work I
>> pointed you at earlier?
>
> Sorry, I read that as "the internal tree at Apple" not "the apple
> branch at fsf". I'll look at it, thanks!
Oh, I just checked the llvm-gcc-4.2 t
> On 4/04/2012, at 2:56 AM, H.J. Lu wrote:
>
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
It's simpler that you think. The target headers ($tm_file in config.gcc
-- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h,
which serves as proxy to all t
> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
>>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>>
>
> The point is that one can build a toolchain for i686-linux-gnu that will
> support both 32-bit and 64-bit multilibs. The 32-bit multilib will be
> used by default, a
Richard Sandiford writes:
> Does anyone else have any thoughts before I make that change?
I think that one of you should try to write a test case where it makes a
difference, and add the test case to the testsuite.
Ian
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.gnu.org/bugzilla/show_bug.cgi?id=18589. The patch
> > modifies reass
> Did you ever dig up the Apple test cases from the APPLE LOCAL work I
> pointed you at earlier?
Sorry, I read that as "the internal tree at Apple" not "the apple
branch at fsf". I'll look at it, thanks!
> They will be more comprehensive that any testing you've done, and,
> if you get them to a
Hi,
i386 maintainers - Is this patch ok?
Thanks,
-Sri.
On Mon, Apr 2, 2012 at 5:48 PM, Sriraman Tallam wrote:
> On Mon, Apr 2, 2012 at 5:38 AM, Richard Guenther
> wrote:
>> On Sat, Mar 31, 2012 at 1:03 AM, Sriraman Tallam wrote:
>>> On Fri, Mar 30, 2012 at 5:47 AM, Michael Matz wrote:
Hi,
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?
Thanks.
H.J.
---
2012-04-03 H.J. Lu
PR libitm/52854
* config/x86/target.h (gtm_jmpbuf): Replace long with long long
for x86-64.
diff --git
This libgo patch changes mksysinfo.sh to add some more networking
constants. This is really just a snapshot, there are more to come,
based on differences between gccgo and the master Go library.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 888
On 4/04/2012, at 2:56 AM, H.J. Lu wrote:
> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
>>>
>>> It's simpler that you think. The target headers ($tm_file in config.gcc --
>>> gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, which
>>> serves as proxy to all those he
Kenneth Zadeck writes:
> Richard,
>
> thanks, for doing the changes.In particular, i did not really
> understand how the target stuff was supposed to work.
>
> I have one issue with the changes that you made.
>
> I had actually decided that the speed/size decision was not relevant to
> this
> If it's required for ABI compatibility why is this an attribute and not
> a target hook?
The ABI uses a #pragma; after this is in I'll do a target-specific
pragma handler to set the attribute. Plus, when I originally proposed
the idea, I was told it was generic so make it an attribute ;-)
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 dependencies. More
> commentary in that url. I'm reposting the patch here since the old
> one no longe
The libgo testsuite looks for functions that match a certain name. On
PPC functions are in the data segment, not the text segment. This patch
to the testsuite script makes the script look in the data segment for
functions on PPC. Bootstrapped and ran libgo testsuite on
x86_64-unknown-linux-gnu.
PING**2
On Wed, Mar 21, 2012 at 23:45, Janne Blomqvist
wrote:
> PING
>
> On Wed, Mar 14, 2012 at 01:03, Janne Blomqvist
> wrote:
>> Hi,
>>
>> the attached patch implements a few fixes and cleanups for the MOD and
>> MODULO intrinsics.
>>
>> - When the arguments are constant, use mpfr_fmod instea
On Tue, Mar 27, 2012 at 3:54 AM, Alan Modra wrote:
> 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 dependencies. More
> commentary in that url. I'm reposting the patch h
On Mon, Mar 26, 2012 at 7:40 AM, Joseph S. Myers
wrote:
> On Fri, 23 Mar 2012, David Edelsohn wrote:
>
>> The build process of libquadmath sometimes encounters problems on AIX
>> due to multilib and LD_LIBRARY_PATH interfering with GCC's own library
>> dependencies. Libquadmath is not used on AIX
On Tue, Apr 3, 2012 at 10:55 AM, Olivier Hainque wrote:
>
> On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
>> Thanks a lot for following up on this one. Coincidentally, I was just
>> about to submit the alternate approach we had discussed about, after
>> David's comment at http://gcc.gnu.org/ml
On 04/03/2012 09:40 AM, Sandeep Kumar Singh wrote:
First, do you have an assignment on file with the FSF
We do have a corporate assignment for KPIT.
Excellent. Thanks for verifying.
My recollection was -mint32 was supported on the original H8/300;
is there something in particular that make
Richard Sandiford writes:
> What do you think? The patch looks OK to me with these changes,
> but I'd like to leave it for 48 hours to see if Ian has any comments.
The patch looks fine to me.
Thanks.
Ian
> 2012-04-03 Kenneth Zadeck
> Richard Sandiford
>
> * Makefile.in (
On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
> On 03/04/12 12:01, Jakub Jelinek wrote:
>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>>> If, so then there's only one way to sort out this mess.
>>>
>>> /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader
>>>
First round of results for 4.7.x
-tgc
Testresults for 4.7.0:
alpha-dec-osf5.1b
hppa2.0w-hp-hpux11.11
i386-apple-darwin10.8.0
i386-pc-solaris2.8 (2)
i386-pc-solaris2.9
i386-pc-solaris2.10
i386-pc-solaris2.11
powerpc-apple-darwin8.11.0
sparc-sun-solaris2.8 (2)
sparc-sun-solaris2
On 03/04/12 12:01, Jakub Jelinek wrote:
> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>> If, so then there's only one way to sort out this mess.
>>
>> /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader
>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard
Latest results for 4.6.x
-tgc
Testresults for 4.6.3:
i386-pc-solaris2.8 (2)
i386-pc-solaris2.10
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/buildstat.html,v
retrieving revision 1.10
diff -u -r1.10 buildsta
Latest results for 4.5.x
-tgc
Testresults for 4.5.3:
i386-pc-solaris2.8 (2)
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/buildstat.html,v
retrieving revision 1.13
diff -u -r1.13 buildstat.html
--- buildstat.h
Latest results for 4.4.x
-tgc
Testresults for 4.4.7:
powerpc-apple-darwin8.11.0
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/buildstat.html,v
retrieving revision 1.25
diff -u -r1.25 buildstat.html
--- buildst
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 bad than one has to try hard to
find a better solution. (Unl
Hello Jeff,
Thank you for reviewing the patch.
>> First, do you have an assignment on file with the FSF
We do have a corporate assignment for KPIT.
It was signed by Bradley Kuhn from FSF side and Dhananjay Deshpande
from KPIT side, during April 2003. In a mail, Peter Brown from FSF has
mentio
Richard,
thanks, for doing the changes.In particular, i did not really
understand how the target stuff was supposed to work.
I have one issue with the changes that you made.
I had actually decided that the speed/size decision was not relevant to
this patch.The problem is that since t
On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich wrote:
>> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>>
The point is that one can build a toolchain for i686-linux-gnu that will
support both 32-bit and 64-bit multilibs. The 32-bit multilib will be
used by default, and compi
On Apr 3, 2012, at 16:34 , Olivier Hainque wrote:
> Thanks a lot for following up on this one. Coincidentally, I was just
> about to submit the alternate approach we had discussed about, after
> David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
> This is of course a much
On Thu, Mar 29, 2012 at 7:34 AM, H.J. Lu wrote:
> On Sat, Mar 3, 2012 at 9:54 AM, H.J. Lu wrote:
>> Hi,
>>
>> This patch backports x32 support to libtool:
>>
>> http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=88992fe6771ec3258bde1b03314ce579da0ac2d5
>>
>> OK to install?
>>
>> Thanks.
>>
>
Hello Alan,
Thanks a lot for following up on this one. Coincidentally, I was just
about to submit the alternate approach we had discussed about, after
David's comment at http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01842.html.
We have experienced with it for a while on our gcc-4.5 series of
compi
On Tue, Apr 03, 2012 at 03:29:06PM +1200, Michael Hope wrote:
> On 3 April 2012 09:06, dann frazier wrote:
> > On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> >> On 29/03/12 20:34, dann frazier wrote:
> >> > This is an updated version of a patch Debian and Ubuntu are using to
>
Kenneth Zadeck writes:
> +#define FORCE_LOWERING
Don't think you meant to keep this.
> -/* Return whether X is a simple object which we can take a word_mode
> - subreg of. */
> +static struct {
> +
> + /* This pass can transform 4 different operations: move, ashift,
> + lshiftrt, and zer
Hi,
ping?
--
Siddhesh
Begin forwarded message:
Date: Tue, 27 Mar 2012 10:51:37 +0530
From: Siddhesh Poyarekar
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow printing of escaped curly braces in assembler
directives with operands
Hi,
An assembler directive with an operand is filtered thro
On 4/2/12 6:25 PM, Jeffrey Yasskin wrote:
2012-04-02 Jeffrey Yasskin
* libstdc++-v3/include/bits/stl_algo.h (__stable_partition_adaptive):
Avoid move-assigning an object to itself by explicitly testing
for identity.
* libstdc++-v3/testsuite/25_algorithms/stab
Hi,
unfortunately VMS doesn't like to include complex.h after math.h, while the
reverse is allowed.
The reason is that math.h (unless ANSI_C_SOURCE is defined but that hides many
math functions) declares cabs/cabsf/cabsl for a structure representing a
complex number, which is not compatible wit
A rather obvious patch.
The module procedure had the FL_PROCEDURE due its use ("CALL sub" or
"func()") - but no interface and no type. Thus, there was no attempt to
search for the symbol in the parent namespace, which causes failures.
Build and tested on x86-84-linux.
OK for the trunk?
Tobia
On Tue, 3 Apr 2012, Eric Botcazou wrote:
> > For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder
> > why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
> > to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
>
> DECL_FIELD_OFFSET is added
The following patch fixes PR52808 - the issue is as in the
duplicate_block fixme comment - if we are destroying a loop
by means of adding another entry we have to do that. Thus
tracer needs to cleanup the cfg after it finished (a good idea
anyway). And jump threading needs to tell cfg manipulati
> For the case in question offset is (D.2640_7 + -1) * 20 + 16. I wonder
> why DECL_FIELD_OFFSET of the outermost COMPONENT_REF is not added
> to bitpos by get_inner_reference (that is what get_bit_range assumes ...).
DECL_FIELD_OFFSET is added to offset and DECL_FIELD_BIT_OFFSET to bitpos.
> So
On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
> If, so then there's only one way to sort out this mess.
>
> /lib/arm-linux-gnueabi/ld-linux.so.3 Location of soft-float loader
> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
The above scheme is a Debianis
On 03/04/12 11:51, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw wrote:
>> On 03/04/12 10:29, Andrew Haley wrote:
>>> On 04/02/2012 10:06 PM, dann frazier wrote:
On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> On 29/03/12 20:34, dann frazi
On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw wrote:
> On 03/04/12 10:29, Andrew Haley wrote:
>> On 04/02/2012 10:06 PM, dann frazier wrote:
>>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
On 29/03/12 20:34, dann frazier wrote:
> This is an updated version of a p
> On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:
>
>>>
>>> The point is that one can build a toolchain for i686-linux-gnu that will
>>> support both 32-bit and 64-bit multilibs. The 32-bit multilib will be used
>>> by default, and compilation for 64-bit user-space can be requested with
>>> -m64
2012-04-03 Bernhard Reutner-Fischer
PR bootstrap/52840
* src/Makefile.am (build-debug): Do not adjust vpath dir, remove
Makefile.tmp
* src/Makefile.in: Adjust as per above.
Signed-off-by: Bernhard Reutner-Fischer
---
libstdc++-v3/src/Makefile.am |3 ++-
li
On 03/04/12 10:29, Andrew Haley wrote:
> On 04/02/2012 10:06 PM, dann frazier wrote:
>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>>> On 29/03/12 20:34, dann frazier wrote:
This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker
On Apr 3, 2012, at 12:09 PM, Paolo Bonzini wrote:
> Il 03/04/2012 11:25, Tristan Gingold ha scritto:
>> Hi,
>>
>> the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the
>> same as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except
>> the case of the first thr
Il 03/04/2012 11:25, Tristan Gingold ha scritto:
> Hi,
>
> the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the
> same as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the
> case of the first three letters). This patch makes gcc/configure.ac uses
> con
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 patch to
> purge_dead_edges making it
On 04/02/2012 10:06 PM, dann frazier wrote:
> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>> On 29/03/12 20:34, dann frazier wrote:
>>> This is an updated version of a patch Debian and Ubuntu are using to
>>> use an alternate linker path for hardfloat binaries. The difference
Hi,
the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the same
as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the case
of the first three letters). This patch makes gcc/configure.ac uses
config/mmap.m4 instead of its own version.
Also, I modified con
> 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 fact, since assign_stack_temp_for_type already
calls the appropriate set_mem_* r
Hi,
this patch handles the 'byte' alignment that appears in standard VMS headers
when a C++ compiler is used.
It also force the support of parameterless variadic functions to be compatible
with standard VMS headers.
Committed on trunk after ia64-hp-openvms cross build.
Tristan.
2012-04-03 Tr
On Mon, Apr 2, 2012 at 9:41 PM, DJ Delorie wrote:
>
> Ping 6...
>
> It's now been over EIGHT MONTHS since I posted the patch, back in
> stage 1 for 4.7. Can someone please review and/or approve this before
> gcc 4.8's stage 1 is closed? This is needed as a first step for ABI
> compatibility for
This patch merges the rs6000 stack_tie and frame_tie rtl, so that we
now should use a tie insn that mentions all base regs involved in
register saves and restores. That should avoid any alias analysis
problems eg. http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01156.html.
I chose to put the regs of
On Mon, Apr 2, 2012 at 11:53 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase compute_data_dependences_for_loop
> fails, but build_rdg ignores its return value and happily goes
> on as if it didn't fail, optimizing away a call.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux a
On Tue, 3 Apr 2012, Eric Botcazou wrote:
> > Hmm, yeah. Or something like
> >
> > Index: expr.c
> > ===
> > --- expr.c (revision 186082)
> > +++ expr.c (working copy)
> > @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_W
> Hmm, yeah. Or something like
>
> Index: expr.c
> ===
> --- expr.c (revision 186082)
> +++ expr.c (working copy)
> @@ -4490,8 +4490,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b
>bitoffset += (tree_low_cst (DECL_FIELD_B
On Tue, 3 Apr 2012, Eric Botcazou wrote:
> > Yes, either way I suppose. The following also looks dangerous to me:
> >
> > /* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT,
> >record its alignment as BIGGEST_ALIGNMENT. */
> > if (MEM_P (op0) && bitpos ==
> Yes, either way I suppose. The following also looks dangerous to me:
>
> /* If OFFSET is making OP0 more aligned than BIGGEST_ALIGNMENT,
>record its alignment as BIGGEST_ALIGNMENT. */
> if (MEM_P (op0) && bitpos == 0 && offset != 0
> && is_aligning_offset
87 matches
Mail list logo
