Hi Chung-Lin,
I think tune_marvell attribute better be kept for future Marvell cores
extension.
Thanks!
B.R.
Yi-Hsiu, Hsu
-Original Message-
From: Chung-Lin Tang [mailto:clt...@codesourcery.com]
Sent: Tuesday, June 26, 2012 12:12 PM
To: Yi-Hsiu Hsu
Cc: Ramana Radhakrishnan; gcc-patche
On Jun 25, 2012, Lawrence Crowl wrote:
> +These conventions will change over time,
> +but changing them requires that a convincing rationale.
s/that//
> +Complex heirarchies are to be avoided.
s/heir/hier/
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the chan
On 2012/6/26 09:37 AM, Yi-Hsiu Hsu wrote:
> Updated changelog.
>
> * config/arm/marvell-pj4.md: New marvell-pj4 pipeline description.
> * config/arm/arm.c (arm_issue_rate): Add marvell_pj4.
> * config/arm/arm.md (tune_marvell): Add marvell_pj4.
> * config/arm/arm-cores.def: Add core marvell-pj4.
>
Here, the problem was that when we substitute into a parameter pack
PARM_DECL to get a dummy decl for use in a decltype context, we were
continuing to tsubst into its DECL_CHAIN as well, which causes problems
if a following parameter uses the previous parameter, as in this testcase.
In tsubst_
OK.
Jason
On Jun 25, 2012, at 6:42 PM, Janis Johnson wrote:
> Lots of places in GCC's testsuite infrastructure get the test name with
> current torture options, set up by DejaGnu's dg-test, by using upvar.
> These accesses usually have a comment that this is ugly but there's
> nothing else to do.
> OK for t
On Jun 25, 2012, at 3:15 PM, Sterling Augustine wrote:
> On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres
> wrote:
>>> As I don't have access to a Darwin machine to test a fix, would you
>>> mind updating the test?
>>
>> The failures are gone with the obvious patch:
> I will commit this if
Lots of places in GCC's testsuite infrastructure get the test name with
current torture options, set up by DejaGnu's dg-test, by using upvar.
These accesses usually have a comment that this is ugly but there's
nothing else to do. I recently modified that test name for use by the
scan directives to
Updated changelog.
* config/arm/marvell-pj4.md: New marvell-pj4 pipeline description.
* config/arm/arm.c (arm_issue_rate): Add marvell_pj4.
* config/arm/arm.md (tune_marvell): Add marvell_pj4.
* config/arm/arm-cores.def: Add core marvell-pj4.
* config/arm/arm-tune.md: Regenerated.
* config/arm/arm
On Fri, Jun 22, 2012 at 9:46 PM, Jason Merrill wrote:
> On 06/22/2012 02:15 PM, Cary Coutant wrote:
>>
>> But if the consensus turns out to be that enumerators should be in
>> pubnames, wouldn't it also be fairly easy to change prune_unused_types
>> so that it doesn't mark enumerators, and change
On 19 June 2012 17:08, Steven Bosscher wrote:
> Hello,
>
> I had a very quick look through the gdc_frontend patch. Below are a
> couple of comments on it:
>
>> http://www.gdcproject.org/files/gdc_frontend.patch.gz
>>
>> [PATCH 1/4]:
>> The D compiler frontend
>> - gcc/d
>
> How did you test this
On 6/25/12, Benjamin Kosnik wrote:
> The only remaining issue for me is the fuzzyness/handwaving
> around inlining. I think the only way to really enforce "what
> can be inlined" is not to have people use their best judgement,
> or what they think is a small function, or what they intend
> for th
Ulrich Weigand writes:
> Richard Guenther wrote:
>
> > In this testcase the alignment of arr[i] should be irrelevant - it is
> > not part of
> > the stmts that are going to be vectorized. But of course this may be
> > simply an odering issue in how we analyze data-references / statements
>
Hey Lawrence, thanks for this work and for keeping the public
up-to-date with this gcc-patches posting.
This looks pretty good to me.
The only remaining issue for me is the
fuzzyness/handwaving around inlining. I think the only way to really
enforce "what can be inlined" is not to have people u
Here's a new version of the main strength reduction patch, addressing
previous comments. A couple of quick notes:
* I opened PR53773 and PR53774 for the cases where commutative
operations were encountered with a constant in rhs1. This version of
the patch still has the gcc_asserts in place to ca
On Jun 25, 2012, at 1:15 PM, rbmj wrote:
> On 06/25/2012 04:02 PM, Mike Stump wrote:
>> On Jun 25, 2012, at 12:09 PM, rbmj wrote:
>>> I also do not know how to run the test suite for the target system
>>> (powerpc-wrs-vxworks). I would think some sort of powerpc simulator, but I
>>> don't have a
Here's a deceptively small patchlet that allows make doc-pdf-doxygen
build the api PDF file when the prerequisites are met. (And the
texmf.cnf file is edited to increase the underlying TeX
subsystem's memory.) I'm currently using doxygen 1.8.1.1 and a variety
of latex subsystems, depending on the
On 6/25/12, Lawrence Crowl wrote:
> On 6/25/12, Joseph S. Myers wrote:
>> On Mon, 25 Jun 2012, Diego Novillo wrote:
>> > [ Added doc maintainers in CC ]
>> >
>> > While I'm not particularly interested in the details of the
>> > coding conventions, I am interested in getting them in getting
>> > t
On 6/25/12, Joseph S. Myers wrote:
> On Mon, 25 Jun 2012, Diego Novillo wrote:
> > [ Added doc maintainers in CC ]
> >
> > While I'm not particularly interested in the details of the
> > coding conventions, I am interested in getting them in getting
> > them installed before we merge cxx-conversio
On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres wrote:
>> As I don't have access to a Darwin machine to test a fix, would you
>> mind updating the test?
>
> The failures are gone with the obvious patch:
>
> diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c
> gcc/testsuite/gcc.dg/pubtypes-
On 25.06.2012 18:21, Matthias Klose wrote:
> On 25.06.2012 15:22, Richard Earnshaw wrote:
>> On 25/06/12 13:08, Matthias Klose wrote:
>>> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
>>> arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in
>>> various
>>> o
> But we can certainly remove stuff that doesn't do anything; in particular,
> these 3 lines
>
> /*#define DONT_USE_BUILTIN_SETJMP 1*/
> #undef DONT_USE_BUILTIN_SETJMP
> #define JMP_BUF_SIZE (8*3+8)
>
> can be proved to be equivalent to the empty set.
If you say so, go for it ;-)
On Mon, 2012-06-25 at 20:00 +0100, Richard Sandiford wrote:
> Or to put it another way, MIPS_ISA_LEVEL_SPEC and MIPS_ARCH_FLOAT_SPEC
> make the multilib options explicit on the command line. You can then
> use that information to add whatever options you want to be the default
> for a given multi
Andrew Pinski writes:
> On Sun, Jun 24, 2012 at 3:36 AM, Richard Sandiford
> wrote:
>> One of the more unfortunate things MIPS has inherited is an LP64 ABI
>> that uses 32-bit rather than 64-bit ELF. I've no idea how many people
>> use it these days (if anyone), but it happens to the ABI of the
Prepares for exposing builtin_mul_widen_even/odd hooks
for more efficient reduction. Adds QImode multiplication.
Shares code between mulv4si3 and the widening multiplies.
---
gcc/ChangeLog | 25 +
gcc/config/i386/i386-protos.h |4 +-
gcc/config/i386/i386.c| 211
---
gcc/ChangeLog | 19 ++
gcc/config/i386/i386-builtin-types.def |5 +-
gcc/config/i386/i386.c | 103 +++-
gcc/config/i386/sse.md | 14 +
4 files changed, 137 insertions(+), 4 deletions(-)
diff
Now that we support mult_even/odd hooks, the vectorizer can
generate the exact same code for plain sse dot_prod by itself,
as well as other reductions other than plus.
---
gcc/ChangeLog |6 +
gcc/config/i386/sse.md | 62 +++-
2 files c
---
gcc/ChangeLog |4
gcc/config/i386/sse.md |6 ++
2 files changed, 10 insertions(+)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 12b8de8..b95eab5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
2012-06-25 Richard Henderson
+ * config/i386
The end result is a bunch more macro-ized patterns in the md file,
and some missing patterns filled in. The widen_mult_even/odd hooks
elide the need for specific sdot_prod patterns while allowing the
same improved code sequence for other reductions.
I expect to be able to use the widen_mult_even/
> RL78 is confusing and it took a while to get it to work right. Please
> don't change it ;-)
But we can certainly remove stuff that doesn't do anything; in particular,
these 3 lines
/*#define DONT_USE_BUILTIN_SETJMP 1*/
#undef DONT_USE_BUILTIN_SETJMP
#define JMP_BUF_SIZE (8*3+8)
can be proved
On 06/25/2012 04:02 PM, Mike Stump wrote:
On Jun 25, 2012, at 12:09 PM, rbmj wrote:
I also do not know how to run the test suite for the target system
(powerpc-wrs-vxworks). I would think some sort of powerpc simulator, but I
don't have a firmware image for VxWorks - just headers and embedded
On 22 June 2012 18:58, Ramana Radhakrishnan
wrote:
> On 20 June 2012 14:37, Christophe Lyon wrote:
>> On 06.06.2012 11:00, Ramana Radhakrishnan wrote:
>>>
>>> Ok with those changes. Ramana .
>>
>>
>> Hi Ramana,
>>
>> How about this version?
>>
>> Christophe.
>>
>
> OK -
>
> This should also go i
On Jun 25, 2012, at 12:09 PM, rbmj wrote:
> I also do not know how to run the test suite for the target system
> (powerpc-wrs-vxworks). I would think some sort of powerpc simulator, but I
> don't have a firmware image for VxWorks - just headers and embedded hardware.
To test well, you need to b
2012/6/25 Richard Guenther :
> On Mon, 25 Jun 2012, Tristan Gingold wrote:
>
>>
>> On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote:
>>
>> > On 06/21/2012 12:48 AM, Tristan Gingold wrote:
>> >> 2012-06-18 Tristan Gingold
>> >>
>> >> * config/i386/winnt.c (i386_pe_seh_end_prologue): Move c
On 20 June 2012 03:53, Yi-Hsiu Hsu wrote:
> marvell-pj4 is added to BE8_LINK_SPEC.
>
> Modified patch is attached.
Missing a modified changelog entry.
Ramana
>
> Thanks!
>
> B.R.
> Yi-Hsiu, Hsu
>
> -Original Message-
> From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org]
On 06/21/2012 02:27 AM, Mike Stump wrote:
On Jun 20, 2012, at 12:36 PM, rbmj wrote:
My issue is that I'm uncomfortable with this, as it seems *too* easy.
I'd just be comfortable with a stake in the ground and press forward. I do
think this covers most all the cases.
With that in mind, then,
On Mon, 25 Jun 2012, Diego Novillo wrote:
> [ Added doc maintainers in CC ]
>
> While I'm not particularly interested in the details of the coding
> conventions, I am interested in getting them in getting them installed
> before we merge cxx-conversion to trunk.
>
> Joseph, Gerald, do we have a
Steve Ellcey writes:
> On Fri, 2012-06-22 at 10:24 +0100, Richard Sandiford wrote:
>
>> If you use a different target name, the specs for that target can
>> enforce whatever triplet-specific defaults you want. See the
>> DRIVER_SELF_SPECS in vr.h for a particularly involved example.
>> (Yours sho
On 2012-06-23 23:56, Olivier Hainque wrote:
> Hello,
>
> ping # 3 for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00298.html
>
> This is related to convert-move possibly emitting a sequence
> with multiple accesses to one input, triggering multiple memory
> accesses when that input happens to be
On 12-06-23 14:42 , Sandeep Soni wrote:
2012-06-25 Sandeep Soni
* parser.c (gimple_symtab_get): New.
(gl_symtab_get_token): New. Gets the tree for the token.
(gp_parse_expect_lhs): Tidy. Returns the tree node for lhs.
(gp_parse_expect_rhs_op): Tidy. Returns t
We were assuming that any expression of nullptr_t was equivalent to
nullptr, but that isn't valid if the expression has side-effects...
Tested x86_64-pc-linux-gnu, applying to 4.6, 4.7, trunk.
commit c716e8680864db1312338691de7d2618efec1c3f
Author: Jason Merrill
Date: Mon Jun 25 13:06:15 2012
Let me try again then...
RL78 is confusing and it took a while to get it to work right. Please
don't change it ;-)
On Fri, 2012-06-22 at 10:24 +0100, Richard Sandiford wrote:
> If you use a different target name, the specs for that target can
> enforce whatever triplet-specific defaults you want. See the
> DRIVER_SELF_SPECS in vr.h for a particularly involved example.
> (Yours shouldn't need to be as bad!)
I
On Mon, Apr 9, 2012 at 12:18 PM, Jan Hubicka wrote:
> Hi,
> this patch fixes several different ICEs related to handling aliases in WHOPR
> partitioning. It took me over week debug this, but when variable alias
> is added to a boundary and its destination is not added, we get queue of
> unforutnat
[ Added doc maintainers in CC ]
While I'm not particularly interested in the details of the coding
conventions, I am interested in getting them in getting them installed
before we merge cxx-conversion to trunk.
Joseph, Gerald, do we have a process for accepting changes to coding
conventions?
It
Andreas Schwab writes:
> Ian Lance Taylor writes:
>
>> @@ -326,13 +336,18 @@
>> }
>>
>> {
>> +text="T"
>> +case "$GOARCH" in
>> +ppc*) text="D" ;;
>
> This is wrong for ppc.
>
> Andreas.
>
> diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
> index da1162e..208cbaf 100
Are there any more concerns about this patch? If not, I'd like to check it in.
thanks,
David
On Fri, Jun 22, 2012 at 8:51 AM, Xinliang David Li wrote:
> On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
> wrote:
>> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote:
>>> On 06/22/2012 01:30
On 25.06.2012 15:22, Richard Earnshaw wrote:
> On 25/06/12 13:08, Matthias Klose wrote:
>> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
>> arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in
>> various
>> other places as well. arm-linux-gnueabihf is used a
On 25.06.2012 15:56, Joseph S. Myers wrote:
> On Mon, 25 Jun 2012, Matthias Klose wrote:
>
>> Please find attached the patch updated for trunk 20120625, x86 only, tested
>> on
>> x86-linux-gnu, KFreeBSD and the Hurd.
>
> This patch appears to include changes to con
On 25/06/12 15:39, Matthew Gretton-Dann wrote:
> Further testing has found a couple of failures to build with a C++ compiler,
> and trunk has moved on a bit so the patch doesn't apply cleanly.
>
> An updated patch is attached.
>
> OK for trunk?
>
> Same ChangeLog as before.
>
OK.
R.
On 06/24/2012 07:19 AM, Jonathan Wakely wrote:
This looks good too, again please CC gcc-patches with a changelog
entry and confirmation it was tested and it can go in. Thanks.
Built and tested on x86_64-linux-gnu.
2012-06-25 Edward Smith-Rowland <3dw...@verizon.net>
* include/tr2/b
On 06/24/2012 07:18 AM, Jonathan Wakely wrote:
On 24 June 2012 12:18, Jonathan Wakely wrote:
On 24 June 2012 05:00, Ed Smith-Rowland wrote:
Subject says it.
This looks good, please CC gcc-patches with a changelog entry and
confirmation it was tested and it can go in. Thanks.
And don't forget
Richard Guenther wrote:
> In this testcase the alignment of arr[i] should be irrelevant - it is
> not part of
> the stmts that are going to be vectorized. But of course this may be
> simply an odering issue in how we analyze data-references / statements
> in basic-block vectorization (thus we pos
The code that collects base initializers in a constructor declared
constexpr was checking potential_constant_expression and then discarding
an initializer for an empty base if true. But
potential_constant_expression only looks at whether a function is
declared constexpr, not whether the call a
On Mon, 25 Jun 2012, Christophe Lyon wrote:
> Ping?
I advise CCing appropriate maintainers (in this case, build system
maintainers) on pings.
--
Joseph S. Myers
jos...@codesourcery.com
Ping?
This patch was tested successfully on cross GCC x86 -> arm-none-eabi, to make sure that
target libs are built with "-O2 -g" as stated in a comment in configure.
It fixes what looks like a cut & paste error.
Without this patch, overriding CFLAGS not including -O2 leads to
CFLAGS_FOR_TARG
On Mon, Jun 25, 2012 at 11:04:42AM -0400, Jason Merrill wrote:
> Right, I just wasn't sure what the point of the test was. Is it
> that if we're declaring the iteration variable in the
> for-init-statement, we don't need to worry about making it OMP
> private?
It should be made private always. E
On 06/25/2012 06:39 AM, Jakub Jelinek wrote:
On Thu, Jun 21, 2012 at 12:34:32AM -0700, Jason Merrill wrote:
All the tests in the libgomp and gcc testsuites pass with this
patch, but I'm not very confident about it because I don't fully
understand what the code is doing. In particular, I'm not s
All,
This commit adds support for the vmfa* and vfms* Neon intrinsics.
This updates neon.ml, and the various generation tools which use it,
arm_neon.h, the testsuite and documentation.
The documentation has not been regenerated for a while and so the
changes are larger than expected.
OK?
gcc/
All,
This patch adds vectoriser support for VFMA to the ARM Neon backend.
Note that the VFP VFNMA and VFNMS instructions do not have Neon
equivalents.
OK?
gcc/ChangeLog:
2012-06-25 Matthew Gretton-Dann
* config/arm/neon.md (fma4): New pattern.
(*fmsub4): Likewise.
2012-06
All,
This patch adds support to the ARM backend for generating floating-point
fused multiply-accumulate.
OK?
gcc/ChangeLog:
2012-06-25 Matthew Gretton-Dann
* config/arm/iterators.md (SDF): New mode iterator.
(V_if_elem): Add support for SF and DF modes.
(V_reg): Lik
All,
This sequence of three patches adds support to the ARM Backend for fused
multiply-accumulate patterns on cores that support it.
Patch 1 adds floating-point support.
Patch 2 adds Advanced SIMD support in the auto-vectorizer.
Patch 3 adds intrinsic support in arm_neon.h.
These patches have
On 06/25/2012 08:17 AM, Florian Weimer wrote:
The message should point to the typedef, but instead, it references the
line with operator new (which doesn't even contain the variable n).
Yep, this is another example of how we don't track/use expression
locations well enough.
For the non-VLA
On 2012-06-25 07:42, Jakub Jelinek wrote:
> PR target/53759
> * config/i386/sse.md (sse_loadlps): Use x m x constraints instead
> of x x x in the vmovlps load alternative.
>
> * gcc.target/i386/pr53759.c: New test.
Ok,.
r~
Hi!
On vectors, even when they satisfy
integer_zerop/integer_onep/integer_all_onesp, the routine doesn't
handle vector types and it is questionable if it would be a good
optimization for them anyway. We don't handle complex there either,
so this patch limits it to integral/pointer types.
Bootstr
Hi!
When the sse_loadlps and avx_loadlps patterns were merged together using
enabled attribute, apparently vmovlps alternative got a typo,
x <- x, x alternative is there already earlier, vmovlps should be
x <- m, 0 for noavx (that is right) and x <- m, x for avx.
Bootstrapped/regtested on x86_64-
Further testing has found a couple of failures to build with a C++ compiler,
and trunk has moved on a bit so the patch doesn't apply cleanly.
An updated patch is attached.
OK for trunk?
Same ChangeLog as before.
Thanks,
Matt
On 20/06/12 11:18, Matthew Gretton-Dann wrote:
PING.
On Mon, May
On 06/24/12 15:54, rbmj wrote:
+ c_fix_arg = "%0\n"
+ "#ifdef IN_GCC\n"
+ "#define mkdir(dir, mode) ((mode), (mkdir)(dir))\n"
+ "#endif\n";
+ c_fix_arg = "extern[\t ]+STATUS[\t ]+mkdir[\t ]*"
+ "\\([\t
Jakub Jelinek writes:
> Unfortunately this seems to break bootstrap on i686-linux.
> Delta-reduced testcase is:
> typedef _Complex float __attribute__ ((mode (TC))) __complex128;
> extern __complex128 clogq (__complex128) __attribute__ ((__nothrow__));
> __complex128
> cacoshq (__complex128 x)
> {
On Mon, Jun 25, 2012 at 3:48 PM, Dehao Chen wrote:
> Hi, Richard,
>
> Thanks for the prompt response.
>
> On Mon, Jun 25, 2012 at 8:02 PM, Richard Guenther
> wrote:
>> On Mon, Jun 25, 2012 at 1:43 PM, Dehao Chen wrote:
>>> During function inlining, a lexical block is added for each cloned
>>> ca
On Sun, Jun 24, 2012 at 11:50:12AM +0100, Richard Sandiford wrote:
> --- gcc/df-problems.c 2012-06-23 13:28:55.576128246 +0100
> +++ gcc/df-problems.c 2012-06-24 11:25:36.851531368 +0100
> @@ -3209,7 +3210,8 @@ dead_debug_insert_temp (struct dead_debu
> the widest referenced mode. */
>wh
On Mon, 25 Jun 2012, Matthias Klose wrote:
> Please find attached the patch updated for trunk 20120625, x86 only, tested on
> x86-linux-gnu, KFreeBSD and the Hurd.
This patch appears to include changes to config.gcc for other targets, not
mentioned in your ChangeLog entries. Please re
Hi, Richard,
Thanks for the prompt response.
On Mon, Jun 25, 2012 at 8:02 PM, Richard Guenther
wrote:
> On Mon, Jun 25, 2012 at 1:43 PM, Dehao Chen wrote:
>> During function inlining, a lexical block is added for each cloned
>> callee, and source info is attached to this block for addr2line to
On 25/06/12 13:08, Matthias Klose wrote:
> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
> arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in
> various
> other places as well. arm-linux-gnueabihf is used as a triplet by some
> distributions.
>
> Ok for th
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.7.1.sv.po', has just
Please find attached the patch updated for trunk 20120625, x86 only, tested on
x86-linux-gnu, KFreeBSD and the Hurd.
I left in the comment about the multiarch names, but I'm fine to change/discard
it. It was first required by Joseph Myers, then not found necessary by Paolo
Bonzini.
Ok fo
On 06/25/2012 05:25 AM, Jason Merrill wrote:
On 06/11/2012 12:11 PM, Florian Weimer wrote:
+ tree inner_nelts_cst = maybe_constant_value (inner_nelts);
+ if (!TREE_CONSTANT (inner_nelts_cst))
+ {
+ if (complain & tf_error)
+ error_at (EXPR_LOC_OR_HERE (inner_nelts),
+ "array size in operator new
gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in various
other places as well. arm-linux-gnueabihf is used as a triplet by some
distributions.
Ok for the trunk?
Matthias
gcc/testsuite/
2012-06-25 Matthia
On Mon, Jun 25, 2012 at 1:43 PM, Dehao Chen wrote:
> During function inlining, a lexical block is added for each cloned
> callee, and source info is attached to this block for addr2line to
> derive the inline stack.
Well - the bug is then clearly
/* Set input_location here so we get the right
During function inlining, a lexical block is added for each cloned
callee, and source info is attached to this block for addr2line to
derive the inline stack. However, some callsites do not have source
information attached to it. Adding a lexical block would be misleading
in this case. E.g. If a fu
2012/6/25 Tristan Gingold :
>
> On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:
>
>> Hello Tristan,
>>
>> patch works for me, too. Just one nit about the patch.
>>
>> 2012/6/18 Tristan Gingold :
>>> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
>>> if (TARGET_32BIT_MS_ABI && cfun->calls
On Mon, Jun 25, 2012 at 07:32:04AM -0300, Alexandre Oliva wrote:
> Unless there are objections in the next 24 hours, I'm going to install
> this in the 4.7 branch too. Regstrapped on x86_64-linux-gnu and
> i686-linux-gnu.
Just install it right away. Thanks.
> > for gcc/ChangeLog
> > from Alex
On Thu, Jun 21, 2012 at 12:34:32AM -0700, Jason Merrill wrote:
> All the tests in the libgomp and gcc testsuites pass with this
> patch, but I'm not very confident about it because I don't fully
> understand what the code is doing. In particular, I'm not sure what
> the condition controlling the c
On Jun 20, 2012, Alexandre Oliva wrote:
> When promote_debug_loc was first introduced, it would never be called
> with a NULL loc list. However, because of the strategy of temporarily
> resetting loc lists before recursion introduced a few months ago in
> alias.c, the earlier assumption no longe
ping^2
thanks
Carrot
On Mon, Jun 18, 2012 at 6:17 PM, Carrot Wei wrote:
> Hi
>
> Could ARM maintainers review following patches?
>
> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00497.html
> 64bit add/sub constants.
>
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01834.html
> 64bit and with con
The GCC 4.5 branch is now frozen for the final release off that branch
and will then be officially closed.
Thanks for your cooperation,
Richard.
On Jun 25, 2012, at 12:52 AM, Iain Sandoe wrote:
> OK for trunk?
Ok.
> * config/darwin.h (SUBTARGET_C_COMMON_OVERRIDE_OPTIONS): Move NeXT
> runtime
> exceptions model setting from here ...
> * config/darwin.c (darwin_override_options): ... to here.
Kinda nasty how delicate thi
> Right, I didn't look at the details of the uses of
> DONT_USE_BUILTIN_SETJMP and JMP_BUF_SIZE but it looks like the ones in
> picochip and stormy16 are redundant too:
>
> For picochip, this port defines DONT_USE_BUILTIN_SETJMP but in the .c
> file (and after all #includes), so it is never exporte
On Jun 25, 2012, at 12:53 AM, Iain Sandoe wrote:
> As described in the PR thread, Darwin was already using the
> TARGET_FOLD_BUILTIN hook to process CFstrings.
>
> The patch fixes the breakage by calling a SUBTARGET_FOLD_BUILTIN where
> defined (following similar patterns for other items that re
On Jun 25, 2012, at 10:26 AM, Steven Bosscher wrote:
> On Mon, Jun 25, 2012 at 9:13 AM, Eric Botcazou
> wrote:
>>> The PA and SPARC back ends do not define DONT_USE_BUILTIN_SETJMP, so
>>> they also do not have to define JMP_BUF_SIZE. So:
>>>
>>> * config/sparc/sparc.h (JMP_BUF_SIZE):
On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote:
> Hello Tristan,
>
> patch works for me, too. Just one nit about the patch.
>
> 2012/6/18 Tristan Gingold :
>> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void)
>> if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp)
>> return true;
>>
>> +
On Mon, 25 Jun 2012, Tristan Gingold wrote:
>
> On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote:
>
> > On 06/21/2012 12:48 AM, Tristan Gingold wrote:
> >> 2012-06-18 Tristan Gingold
> >>
> >>* config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ...
> >>(seh_cfa_adjust_c
On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote:
> On 06/21/2012 12:48 AM, Tristan Gingold wrote:
>> 2012-06-18 Tristan Gingold
>>
>> * config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ...
>> (seh_cfa_adjust_cfa): ... that function.
>> (seh_emit_stackalloc): Do
On Mon, Jun 25, 2012 at 9:13 AM, Eric Botcazou wrote:
>> The PA and SPARC back ends do not define DONT_USE_BUILTIN_SETJMP, so
>> they also do not have to define JMP_BUF_SIZE. So:
>>
>> * config/sparc/sparc.h (JMP_BUF_SIZE): Do not define.
>> * config/pa/pa.h (JMP_BUF_SIZE): Likewi
On Sun, Jun 24, 2012 at 11:56 PM, Steven Bosscher wrote:
> Hello,
>
> Documentation for this target macro is missing.
> This patch adds it. OK for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
>
> * doc/tm.texi.in: Document JMP_BUF_SIZE.
> * doc/tm.texi: Regenerate.
>
>
>
> Index:
On Sun, Jun 24, 2012 at 10:06 PM, Steven Bosscher wrote:
> Hello,
>
> Noticed while going through sourcebuild.texi to see what needs
> updating for the move of the C front end to its own subdirectory of
> gcc/.
>
> Ok for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
>
> * doc/sourcebuild
On Mon, Jun 25, 2012 at 12:31 AM, DJ Delorie wrote:
>
>> The rl78 apparently doesn't know what it wants to do:
>>
>> /* NOTE: defined but zero means dwarf2 debugging, but sjlj EH. */
>> #define DWARF2_UNWIND_INFO 0
>> /*#define DONT_USE_BUILTIN_SETJMP 1*/
>> #undef DONT_USE_BUILTIN_SETJMP
>> #def
On 06/25/2012 09:59 AM, Richard Guenther wrote:
On Fri, 22 Jun 2012, Richard Guenther wrote:
This bumps the requirement to enable Graphite to using cloog 0.17.0
which is the last release from upstream. The patch removes the
support for the legacy cloog versions, too.
I am bootstrapping and t
On Fri, 22 Jun 2012, Richard Guenther wrote:
>
> This bumps the requirement to enable Graphite to using cloog 0.17.0
> which is the last release from upstream. The patch removes the
> support for the legacy cloog versions, too.
>
> I am bootstrapping and testing this now with cloog 0.17.0 built
As described in the PR thread, Darwin was already using the TARGET_FOLD_BUILTIN
hook to process CFstrings.
The patch fixes the breakage by calling a SUBTARGET_FOLD_BUILTIN where defined
(following similar patterns for other items that require sub-target handling).
OK for trunk?
Iain
gcc:
1 - 100 of 103 matches
Mail list logo
