+A combination that works in most places is a newline to break the
+line, plus a tab character to move to the instruction field (written
+as "\n\t").
Will everyone know what an instruction field is? I'm not sure it's
that common of a term.
Hmm. I brought that text across unchanged from the o
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Monday, May 05, 2014 3:21 PM
> To: Richard Earnshaw
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH ARM] Improve ARM memset inlining
>
> Hi Richard, Th
ok. Also needed in google/gcc-4_9 branch.
David
On Mon, May 5, 2014 at 8:40 PM, Dehao Chen wrote:
> This patch handles TYPE_PACK_EXPANSION in lipo_cmp_type.
>
> testing on going. OK for google-4_8?
>
> Thanks,
> Dehao
>
> Index: gcc/l-ipo.c
>
> ===
This patch handles TYPE_PACK_EXPANSION in lipo_cmp_type.
testing on going. OK for google-4_8?
Thanks,
Dehao
Index: gcc/l-ipo.c
===
--- gcc/l-ipo.c (revision 209226)
+++ gcc/l-ipo.c (working copy)
@@ -676,6 +676,7 @@ lipo_cmp_typ
This patch by Chris Manghane changes the Go frontend to use the backend
interface for the length of an array. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r f4135c695c00 go/types.cc
--- a/go/types.cc Mon May 05 20:10:20 2014 -0400
+++ b/go/type
On Sat, May 03, 2014 at 10:24:31PM +0200, Oleg Endo wrote:
> Hi,
>
> I've committed the attached patch as r210040, which reinstates the RTL
> pass.
>
> Trevor, could you please double check that you haven't missed any other
> cases in your pass refactoring patches?
I have no clue how this happen
This patch by Chris Manghane changes the Go frontend to use the backend
interface for slice construction. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2014-05-05 Chris Manghane
* go-gcc.cc (Gcc_backend::implicit_variable): Rename from
This patch by Chris Manghane change the Go frontend to move the handling
of indirecting through recursive pointer types to the backend.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
2014-05-05 Chris Manghane
* go-gcc.cc (Gcc_backend::indire
Hi,
This patch (changelog entry needs to be written up) moves the minimal
set of attributes to accommodate the needs of builtins out of each
respective front-end and into a common area shared between each.
Defines lhd_common_attribute_table and lhd_format_attribute_table to
provide as defaults fo
This patch by Chris Manghane changes the Go frontend to use the backend
interface for type info expressions. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 1a6ec84147d3 go/expressions.cc
--- a/go/expressions.cc Mon May 05 15:05:17 2014 -0400
++
Hi,
On 05/05/2014 10:48 PM, Jason Merrill wrote:
On 05/05/2014 12:25 PM, Paolo Carlini wrote:
Good, but is it Ok to use uses_template_parms for that? A few days ago I
struggled to find something simpler ready to use, to no avail (well,
this is probably well known to you, but there are surprisin
Richard Biener writes:
> On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
> wrote:
>> I'd hoped the
On Mon, 2014-05-05 at 13:33 -0500, Peter Bergner wrote:
> Currently, the IBM long double routines in libgcc use a union to construct
> a long double from two double values. This causes horrific code generation
> that copies the two double from the FP registers over to GPRs and back
> again, giving
On 05/05/2014 12:25 PM, Paolo Carlini wrote:
Good, but is it Ok to use uses_template_parms for that? A few days ago I
struggled to find something simpler ready to use, to no avail (well,
this is probably well known to you, but there are surprisingly few
places in pt.c where we explain either in c
Steve Ellcey writes:
> On Sat, 2014-05-03 at 07:52 +0100, Richard Sandiford wrote:
>
>> > Old:
>> >
>> >li $5,305397760# 0x1234
>> >addiu $4,$5,1
>> >addiu $5,$5,-1
>> >
>> > New:
>> >
>> >li $5,305332224# 0x1233
>> >
Jakub Jelinek writes:
> On Sat, May 03, 2014 at 08:34:07AM +0100, Richard Sandiford wrote:
>> Ping for this old patch. I didn't ping it before because I can imagine
>> it wasn't a good idea at that stage in 4.8. But I've been using it locally
>> since and it really does make a big difference whe
Ping!
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01618.html
-Sandra
On Mon, May 05, 2014 at 10:27:03PM +0200, Marek Polacek wrote:
> In this PR the issue is that we reject (valid) code such as
> _Alignas (long long) long long foo;
> with -m32, because we trip this condition:
>
>alignas_align = 1U << declspecs->align_log;
>if (alignas_align < TYPE_ALIGN_UNI
In this PR the issue is that we reject (valid) code such as
_Alignas (long long) long long foo;
with -m32, because we trip this condition:
alignas_align = 1U << declspecs->align_log;
if (alignas_align < TYPE_ALIGN_UNIT (type))
{
if (name)
error_at (loc, "%<_Alignas%> spe
On May 5, 2014, at 1:00 AM, Richard Biener wrote:
> And can we remove TYPE_ALIGN_OK as followup? (ISTR it's used
> by obj-c/c++ as well, but I can't find such use)
I didn’t find any current hint… the only landmine I found was:
./gcc/config/pa/pa.c:1878:/* Using TYPE_ALIGN_O
[ Oh no! I wrote this on a plane two days ago and now it got stuck
in my outbox. Let's get this patch in before any further delays
happen. ]
On Sun, 27 Apr 2014, dw wrote:
> The goal of this patch was to rewrite section 6.41. That's no simple
> task, since 6.41 was ~10 very full pages. U
On 05/05/14 08:13, Marek Polacek wrote:
It seems it's better to error out when someone passes bogus option to
-fsanitize rather than only give a warning. Error gives non-zero exit
status so with this patch the behavior is friendlier to configure
scripts.
Bootstrapped on x86_64-linux, ok for tru
On Mon, May 05, 2014 at 01:44:06PM -0600, Jeff Law wrote:
> On 05/05/14 11:37, Richard Biener wrote:
> >
> >Well, I hope that Andrew doesn't do without a namespace (and I still
> >don't believe in what he tries to achieve without laying proper ground-work
> >throughout the compiler). With a namesp
On Mon, May 05, 2014 at 01:44:06PM -0600, Jeff Law wrote:
> On 05/05/14 11:37, Richard Biener wrote:
> >
> >Well, I hope that Andrew doesn't do without a namespace (and I still
> >don't believe in what he tries to achieve without laying proper ground-work
> >throughout the compiler). With a namesp
Hi,
this patch fixes unfortunate thinko in get_class_context that invalidates
transitions from non-POD type to a polymorphic type that may happen by virtue
of placement new and apparently breaks openJDK and Qt. I really tried to keep
placement new in mind when implementing ipa-devirt, so hope there
On 05/05/14 11:37, Richard Biener wrote:
Well, I hope that Andrew doesn't do without a namespace (and I still
don't believe in what he tries to achieve without laying proper ground-work
throughout the compiler). With a namespace gimple we can use
gimple::stmt.
namespaces, while nice, aren't goi
On Sat, 2014-05-03 at 07:52 +0100, Richard Sandiford wrote:
> > Old:
> >
> > li $5,305397760# 0x1234
> > addiu $4,$5,1
> > addiu $5,$5,-1
> >
> > New:
> >
> > li $5,305332224# 0x1233
> > ori $5,$5,0x
> >
On 05/05/14 12:37, David Malcolm wrote:
FWIW I assumed the ick from Jeff was in relation to CamelCase.
Yes. That is a personal preference, of course.
Note that it's not just GIMPLE_SWITCH that has this problem when using
this naming convention; I believe the list of codes that would have
cla
On Sat, May 03, 2014 at 08:34:07AM +0100, Richard Sandiford wrote:
> Ping for this old patch. I didn't ping it before because I can imagine
> it wasn't a good idea at that stage in 4.8. But I've been using it locally
> since and it really does make a big difference when testing lots of
> multilib
This patch by Chris Manghane changes the Go frontend to use the backend
interface for sink expressions. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r e59376bb96c4 go/expressions.cc
--- a/go/expressions.cc Mon May 05 14:49:01 2014 -0400
+++ b/g
> After tomorrow, this should be:
>
> MAX_BITSIZE_MODE_ANY_INT, not 128.
Heh.
Ok, after tomorrow, assume my patch has that instead :-)
On May 4, 2014, at 2:09 PM, DJ Delorie wrote:
> Here's an independent change that removes the decimal table and
> replaces it with generated hex values. I included the relevent output
> of gcc -E -dM also.
> + /* Allows bit sizes up to 128 bits. */
> +#define PBOH_SZ (128/4+4)
After tomorrow,
This patch by Chris Manghane changes the Go frontend to use the backend
interface for set-and-use temporary variables. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 9ec9e72945e4 go/expressions.cc
--- a/go/expressions.cc Mon May 05 13:54:25 201
On Mon, 2014-05-05 at 19:37 +0200, Richard Biener wrote:
> On Mon, May 5, 2014 at 6:01 PM, Jeff Law wrote:
> > On 05/05/14 02:22, Richard Biener wrote:
> >>>
> >>>
> >>> Also, AIUI, Andrew is looking at introducing concepts of gimple types and
> >>> gimple expressions, so "gimple" may no longer im
Currently, the IBM long double routines in libgcc use a union to construct
a long double from two double values. This causes horrific code generation
that copies the two double from the FP registers over to GPRs and back
again, giving us two loads and two stores, which leads to two load-hit-store
On 05/05/14 12:14, Mike Stump wrote:
On May 5, 2014, at 9:08 AM, Jeff Law wrote:
It would mean a bit of pain for initial system bootstraps by the
distributors,
I don’t expect any pain there. System distributors usually have a
distribution for the last release that includes binaries for all,
On May 5, 2014, at 9:08 AM, Jeff Law wrote:
> It would mean a bit of pain for initial system bootstraps by the distributors,
I don’t expect any pain there. System distributors usually have a distribution
for the last release that includes binaries for all, including python, tcl and
gcc. They
On Mon, May 05, 2014 at 07:32:31PM +0200, Richard Biener wrote:
> > void_zero_node is used for ubsan too, and survives into gimple.
> > I did hit this in real tests, it wasn't just theoretical.
>
> Ugh - for what does it use that ... :/
It's used like this:
t = fold_build3 (COND_EXPR, void_type_n
This patch by Chris Manghane changes the Go frontend to use the backend
interface for struct field offsets. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r d87cfc273ffc go/expressions.cc
--- a/go/expressions.cc Mon May 05 13:21:55 2014 -0400
+++
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-05-05 Richard Biener
* passes.c (execute_function_todo): Don't reset TODO_verify_ssa
from last_verified if update_ssa ran. Move TODO_verify_rtl_sharing
under the TODO_verify_il umbrella.
Ind
On Mon, May 5, 2014 at 6:44 PM, Joseph S. Myers wrote:
>> These are due to TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL tuning flag.
>> Currently, this flag applies to all vector sizes (128, 256 and 512
>> bits), but I guess it is effective only for 128 bit sizes. Can you
>> please review usage of this
On Mon, May 5, 2014 at 6:01 PM, Jeff Law wrote:
> On 05/05/14 02:22, Richard Biener wrote:
>>>
>>>
>>> Also, AIUI, Andrew is looking at introducing concepts of gimple types and
>>> gimple expressions, so "gimple" may no longer imply a *statement*.
>>>
>>> Alternatively, we could make the base clas
On Mon, May 5, 2014 at 4:51 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
wrote:
> I'd hoped the days of zero-precision INTEGER_CST
This patch from Chris Manghane changes the Go frontend to use the
backend interface for bound method expressions. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r e828f77c32b7 go/expressions.cc
--- a/go/expressions.cc Thu May 01 15:18:08 2014 -04
Assuming first part of the patch is committed. Is the following patch
ok? It passes bootstrap and make check.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 91f6f21..475448e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42808,6 +42808,7 @@ expand_vec_perm
On Mon, May 5, 2014 at 11:08 AM, Richard Biener
wrote:
> On Mon, Apr 28, 2014 at 8:14 PM, Jason Merrill wrote:
>> Applied, thanks. Sorry for the delay.
>
> It caused PR61066 on the branch.
>
> Richard.
>
>> Jason
It seems some tests didn't run when I tested the patch, sorry about that.
I'll try
Is the following patch ok? It passes bootstrap and make check.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 88142a8..91f6f21 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42807,6 +42807,8 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
return
On Wed, 2 Apr 2014, Uros Bizjak wrote:
> These are due to TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL tuning flag.
> Currently, this flag applies to all vector sizes (128, 256 and 512
> bits), but I guess it is effective only for 128 bit sizes. Can you
> please review usage of this flag in i386/sse.md?
Hi,
On 05/05/2014 03:32 PM, Jason Merrill wrote:
On 05/03/2014 06:55 PM, Paolo Carlini wrote:
On 05/03/2014 11:14 PM, Jason Merrill wrote:
Do you want CLASSTYPE_IS_TEMPLATE here?
Uhm, you mean something simple like the attached? Because certainly I
tried it and didn't fully work (nsdmi-temp
With the following patch, gfortran can be regtested with -flto
with no failure, but pr54852 and pr60061.
OK for trunk?
Dominique
2014-05-05 Dominique d'Humieres
* gfortran.dg/gfortran.dg/bind_c_array_params_2.f90:
Adjust regexp for -flto.
* gfortran.dg/gfortran.dg/pr4
On 04/30/14 21:07, David Malcolm wrote:
Currently, gengtype does not support template arguments that are
explicitly pointers, such as:
static GTY(()) vec test_gimple; giving this
error:
../../src/gcc/gimple-expr.c:902: parse error: expected a string constant or
',', have '*' instead
requir
On Sat, 2014-05-03 at 07:52 +0100, Richard Sandiford wrote:
> > Old:
> >
> > li $5,305397760# 0x1234
> > addiu $4,$5,1
> > addiu $5,$5,-1
> >
> > New:
> >
> > li $5,305332224# 0x1233
> > ori $5,$5,0x
> >
On 02/13/14 02:18, Richard Sandiford wrote:
http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00025.html
the script takes just over 5 hours to produce the gcc.log file.
Good grief...
This patch tries to reduce that by providing an alternative single-script
version. I was torn between P
On 05/05/14 02:22, Richard Biener wrote:
Also, AIUI, Andrew is looking at introducing concepts of gimple types and
gimple expressions, so "gimple" may no longer imply a *statement*.
Alternatively, we could make the base class be just "gimple" (which would
be more consistent with the names of th
On 2014-04-24, 3:12 AM, Tom de Vries wrote:
On 23-04-14 17:10, Richard Sandiford wrote:
FWIW I think this should be a plain bool rather than a function,
like delay_sched2 etc.
Vladimir,
I've reimplemented the hook using DEFHOOKPOD instead of DEFHOOK, to make
it a plain bool.
OK for trunk?
On 2014-04-25, 11:35 PM, Wei Mi wrote:
Hi,
This patch is to address the missing optimization reported in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60738
Now in process_single_reg_class_operands, any allocno A conflicting
with a single reg class operand B is marked to never use the reg class
i
If no one objects, I'll commit the following patch in a couple of days
2014-05-05 Dominique d'Humieres
* gfortran.dg/list_read_12.f90: Delete the file.
* gfortran.dg/gfortran.dg/vect/fast-math-real8-pr40801.f90:
Cleanup module yomphy0.
--- ../_clean/gcc/testsuite/gfort
Richard Biener writes:
> On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>>> wrote:
I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
Richard's patch to remove min amd max
As posted in the PR, neither the patch in the PR nor the one in this thread
fixes the test for powerpc-apple-darwin9.
Cheers,
Dominique
It seems it's better to error out when someone passes bogus option to
-fsanitize rather than only give a warning. Error gives non-zero exit
status so with this patch the behavior is friendlier to configure
scripts.
Bootstrapped on x86_64-linux, ok for trunk?
2014-05-05 Marek Polacek
On Mon, Apr 28, 2014 at 8:14 PM, Jason Merrill wrote:
> Applied, thanks. Sorry for the delay.
It caused PR61066 on the branch.
Richard.
> Jason
On 05/03/2014 06:55 PM, Paolo Carlini wrote:
On 05/03/2014 11:14 PM, Jason Merrill wrote:
Do you want CLASSTYPE_IS_TEMPLATE here?
Uhm, you mean something simple like the attached? Because certainly I
tried it and didn't fully work (nsdmi-template7.C?) and for sure we
would regress on the belo
On Sun, May 4, 2014 at 10:32 AM, Thomas Preud'homme
wrote:
> Warning for use of a partially initialized complex is displayed on the wrong
> line (the one where the partial initialization is done) and is not consistent
> between target (or even within a given target, for instance between hardfloa
On Mon, May 5, 2014 at 8:47 AM, Richard Biener
wrote:
> On Mon, May 5, 2014 at 4:45 AM, Patrick Palka wrote:
>> On Sun, May 4, 2014 at 12:20 PM, Patrick Palka wrote:
>>> This patch causes a latent test failure in gcc.dg/uninit-pred-9_b.c
>>> due to an oversight in the tree-ssa-uninit code for wh
On Thu, May 01, 2014 at 11:55:38PM +, Joseph S. Myers wrote:
> On Fri, 25 Apr 2014, Marek Polacek wrote:
>
> > Another minor fix: use loc instead of input_location. Also add
> > missing OPT_Wpedantic.
>
> Why do you say it's missing? A default pedwarn generally means "this is
> dubious co
On Mon, May 5, 2014 at 4:45 AM, Patrick Palka wrote:
> On Sun, May 4, 2014 at 12:20 PM, Patrick Palka wrote:
>> This patch causes a latent test failure in gcc.dg/uninit-pred-9_b.c
>> due to an oversight in the tree-ssa-uninit code for which I will send
>> a fix shortly.
>
> Never mind, I spoke to
On Mon, May 5, 2014 at 12:54 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
>> wrote:
>>> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
>>> Richard's patch to remove min amd max values from zero-width bitfields,
Hi!
I'd like to install this patch, which would help me to run the build
robot (http://toolchain.lug-owl.de/buildbot/):
2014-05-05 Jan-Benedict Glaw
contrib/
* config-list.mk (show): New target.
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index ddf24a2..cea0a94 10064
On 02/03/2014 10:05 AM, Florian Weimer wrote:
On 01/17/2014 11:26 AM, Florian Weimer wrote:
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is
I found a way to improve the function find_bswap/find_bswap_or_nop
and reduce its size. Please hold for the review, I will post an updated
version as soon as I finish testing.
Best regards,
Thomas Preud'homme
Richard Biener writes:
> On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
> wrote:
>> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
>> Richard's patch to remove min amd max values from zero-width bitfields,
>> but a boostrap-ubsan showed otherwise. One source is in:
>>
Bootstrapped/regtested on x86_64-linux-gnu.
One test, gcc/testsuite/g++.old-deja/g++.pt/friend5.C, breaks, as it should,
and was fixed.
~chill
Hello,
A friend function, defined in a class and not declared outside should
be hidden from ordinary name lookup and only found by argument-dependent
lookup, like:
struct S
{
friend void f() {}
friend void g(const S &) {}
};
int
main()
{
f(); // error
g(S()); // correct, found by AD
Status
==
After releasing GCC 4.9.0 it is now time to think about a GCC 4.8.3
release. The branch remains in release-branch mode for now until
we do a first release candidate somewhen next week. This means you
have about a week to do backports of important regression fixes - now
that GCC 4.
This tackles TODO_verify_flow_info, the last existing bit. Similar
to others we have to avoid running after IPA passes as they leave
CFG bits to be fixed up by the fixup_cfg pass invocations.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
The next bit will be removing of all the
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61062
On 30 April 2014 11:18, Ramana Radhakrishnan wrote:
> On Thu, Mar 27, 2014 at 10:53 AM, Alan Lawrence wrote:
>> Final patch adds new tests of the ARM ZIP Intrinsics (subsuming the
>> autogenerated ones in testsuite/gcc.target/arm/n
No, this is quite different issue related to safety of load/stores
which are on branched paths, i.e. not always executed and may trap.
Note that we don't have such issue for HSW which have masked
load/stores.
Yuri.
2014-05-05 11:44 GMT+04:00 Richard Biener :
> On Wed, Apr 30, 2014 at 5:50 PM, Yu
On Fri, May 2, 2014 at 9:19 PM, Richard Sandiford
wrote:
> I'd hoped the days of zero-precision INTEGER_CSTs were behind us after
> Richard's patch to remove min amd max values from zero-width bitfields,
> but a boostrap-ubsan showed otherwise. One source is in:
>
> null_pointer_node = build_in
On Sun, May 4, 2014 at 5:03 AM, Patrick Palka wrote:
> We can check if any assertions were found by simply inspecting the
> need_assert_for bitmap. This eliminates the need to pass all these
> bools around everywhere.
>
> 2014-05-03 Patrick Palka
>
> * tree-vrp.c (register_edge_assert_
On Fri, May 2, 2014 at 11:56 PM, David Malcolm wrote:
> This patch series demonstrates a way of reimplementing the 89-patch series:
> "[PATCH 00/89] Compile-time gimple-checking"
> http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01148.html
>
> whilst avoiding introducing a pair of "gimple_foo/
Committed to trunk.
Andreas.
* config/abi/post/ia64-linux-gnu/baseline_symbols.txt
(CXXABI_1.3.9): Remove __float128 symbols.
Index: config/abi/post/ia64-linux-gnu/baseline_symbols.txt
===
--- config/abi/post/ia64-li
On Fri, May 2, 2014 at 5:20 PM, Richard Sandiford
wrote:
> I locally tried adding an assertion to the wide-int version of set_bit
> to make sure that the bit number was in range. It triggers for this
> code in boehm.c:mark_reference_fields (quoting trunk version):
>
> /* First word in o
On Fri, May 2, 2014 at 12:39 PM, Richard Earnshaw wrote:
> On 02/05/14 11:28, James Greenhalgh wrote:
>> On Fri, May 02, 2014 at 10:29:06AM +0100, pins...@gmail.com wrote:
>>>
>>>
On May 2, 2014, at 2:21 AM, James Greenhalgh
wrote:
> On Fri, May 02, 2014 at 10:00:15AM +0100, A
On Fri, May 2, 2014 at 8:18 AM, Jeff Law wrote:
> On 04/22/14 03:25, Eric Botcazou wrote:
>>>
>>> Sure, and thanks again for your help.
>>
>>
>> Thanks!
>>
>>> I was not able to find any difference on the generated code with
>>> or without that patch.
>>
>>
>> Yes, my gut feeling is that TYPE_ALIG
On Thu, May 1, 2014 at 4:50 PM, Richard Sandiford
wrote:
> bootstrap-asan failed on wide-int from what looks like a typo in
> compute_ltrans_boundary. The first loop uses the function-wide "node"
> variable while the second loop uses a local "vnode" variable. The problem
> was that the second lo
On Wed, Apr 30, 2014 at 5:50 PM, Yuri Rumyantsev wrote:
> Thanks a lot Richard for you review.
> I did all proposed changes, checked that bootstrap and regression
> testing did not show new failures.
> Updated patch is attached.
As said, this is ok for checkin.
Thanks,
Richard.
> Best regards.
Ping!
On 04/28/2014 01:35 PM, Dimitris Papavasiliou wrote:
On 04/25/2014 07:50 PM, Mike Stump wrote:
On Apr 25, 2014, at 9:34 AM, Dimitris Papavasiliou
wrote:
--Wreturn-type -Wsequence-point -Wshadow @gol
+-Wreturn-type -Wsequence-point -Wshadow -Wshadow-ivar @gol
This has to be -Wno-shadow
> -Original Message-
> From: Richard Earnshaw
> Sent: Thursday, May 01, 2014 10:03 PM
> To: Bin Cheng
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH ARM]Handle REG addressing mode in
> output_move_neon explicitly
>
> On 29/04/14 04:02, bin.cheng wrote:
> > Hi,
> > Function output_mo
88 matches
Mail list logo
