On Mon, Feb 6, 2017 at 7:00 AM, Prasad Ghangal wrote:
> On 4 January 2017 at 16:02, Richard Biener wrote:
>> On Wed, Dec 28, 2016 at 7:27 PM, Prasad Ghangal
>> wrote:
>>> Hi,
>>> The attached patch tries fix ICE due to undeclared variable(s) in the input.
>>> Successfully bootstrapped on x86_64-
Hi,
On 6 February 2017 at 17:56, Richard Earnshaw (lists)
wrote:
> On 06/02/17 15:54, Jiong Wang wrote:
>> On 06/02/17 15:26, Jan Hubicka wrote:
>>> I think it is not a regression, just the testcase if fragile and
>>> depends on outcome
>>> of ifcombine. It seems it was updated several time in
On Mon, Feb 6, 2017 at 10:57 PM, Jeff Law wrote:
> On 02/06/2017 08:33 AM, Richard Biener wrote:
>
>> ah, indeed vr0type is VR_ANTI_RANGE and yes we have the case
>> of a range with an anti-range "inside". This also covers [-1,1] v ~[0,0]
>> where you choose the much larger anti-range now. So at
This avoids the C machinery when building CALL_EXPRs (folding and argument
promotion).
Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.
Richard.
2017-02-07 Richard Biener
c/
* gimple-parser.c (c_parser_gimple_expr_list): Simplify.
(c_parser_gimple_postf
On 01/26/2017 01:04 PM, Thomas Preudhomme wrote:
> Hi JonY,
>
> On 19/01/17 01:37, JonY wrote:
>> On 01/18/2017 09:48 AM, Thomas Preudhomme wrote:
>>> By default, wildcard support on Windows for programs compiled with mingw
>>> depends on how the mingw runtime was configured. This means if one wan
On 07/02/17 08:37, Christophe Lyon wrote:
> Hi,
>
>
> On 6 February 2017 at 17:56, Richard Earnshaw (lists)
> wrote:
>> On 06/02/17 15:54, Jiong Wang wrote:
>>> On 06/02/17 15:26, Jan Hubicka wrote:
I think it is not a regression, just the testcase if fragile and
depends on outcome
>>>
Within the last 3 days, gcc.target/i386/pr78419.c started to FAIL on
Solaris/x86:
FAIL: gcc.target/i386/pr78419.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr78419.c:10:10:
error: the call requires ifunc, which is not supported by this targ
On Tue, Feb 07, 2017 at 10:32:33AM +0100, Rainer Orth wrote:
> Within the last 3 days, gcc.target/i386/pr78419.c started to FAIL on
> Solaris/x86:
>
> FAIL: gcc.target/i386/pr78419.c (test for excess errors)
>
> Excess errors:
> /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/pr78419.c:
On 7 February 2017 at 14:10, Richard Biener wrote:
>
> This avoids the C machinery when building CALL_EXPRs (folding and argument
> promotion).
>
> Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.
Hi Richard,
IIUC, __builtin_abs(a) would now get built as a call instead of
abs_expr wi
On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
> On 7 February 2017 at 14:10, Richard Biener wrote:
> >
> > This avoids the C machinery when building CALL_EXPRs (folding and argument
> > promotion).
> >
> > Bootstrap and regtest in progress on x86_64-unknown-linux-gnu.
> Hi Richard,
> IIUC, __bui
Mike Stump writes:
> On Feb 6, 2017, at 3:33 AM, Rainer Orth wrote:
>>
>> Hi Gerald,
>>
>>> Copying the two guys listed as testsuite maintainers in gcc/MAINTAINERS
>>> may help; let me do that for you.
>>>
>>> That said, if this fails to fail, the patch might be considered obvious,
>>> not re
Matthew Fortune writes:
>
> Almost but not quite. There is a force_reg helper that takes care of
> this i.e. can get rid of the qireg local and the whole if statement.
>
> emit_insn (gen_zero_extendqisi2 (sireg, force_reg (ops[2].value)));
>
> OK with that change.
>
> Thanks,
> Matthew
C
Hi all,
I tried building a cc1 for riscv-x-elf and I got a build error about INT16_MAX
not being defined on my system.
I think it's not a standard macro. This patch fixes that with what I think is
the equivalent definition using
GCC modes logic.
With this my build proceeds to build a cc1 succ
On Wed, 1 Feb 2017, Richard Biener wrote:
> Applied as follows, bootstrapped & tested on x86_64-unknown-linux-gnu.
And as shown by the new testcase (ICEing on the gcc-6-branch only) the
fix is not enough as breadth merging of loop and loop->next may pull in
other loops into the region. Eventuall
> The attached patch to gcc trunk enables Ada support on
> aarch64-*-freebsd*. All tests pass except those affected by the
> currently missing unwind support (c52103x, c52104x, c52104y,
> cb1010a, cb1010c, cb1010d, gnat.dg/null_pointer_deref* (3)).
>
> I'd also like to get this patch backported
Hi,
The patch fixes some bugs as mentioned below.
1. mips_gen_const_int_vector(): Change type for argument VAL from int to
HOST_WIDE_INT to allow const vector of type doubleword. It in turn enables
generation of BCLRI.d instead of AND.d for immediate const vector operand with
only one bit clea
On Fri, 3 Feb 2017, Iain Sandoe wrote:
>
> > On 2 Feb 2017, at 08:08, Richard Biener wrote:
> >
> > On Wed, 1 Feb 2017, Segher Boessenkool wrote:
> >
> >> On Wed, Feb 01, 2017 at 03:53:09PM -0600, Segher Boessenkool wrote:
> >>> On Wed, Feb 01, 2017 at 11:59:10AM +0100, Richard Biener wrote:
>
> You could drop the namespace. Also "struct A" would be better, because
> otherwise fn1 is a private and thus unaccessible in fn2.
True. So how about this extended version, which also mentions more examples
of what might now fail?
Index: porting_to.html
=
On 2/7/2017 05:37, Arnaud Charlet wrote:
The attached patch to gcc trunk enables Ada support on
aarch64-*-freebsd*. All tests pass except those affected by the
currently missing unwind support (c52103x, c52104x, c52104y,
cb1010a, cb1010c, cb1010d, gnat.dg/null_pointer_deref* (3)).
I'd also lik
> This is exactly what aarch64-*-linux* is doing is doing in gcc 6
> branch (e.g. system.ads modeled it after, but now I see it has been changed to
Well no, you are reusing an x86_64 file for an aarch64 architecture, so
this is exactly the same issue.
Arno
On 07/02/17 14:27 +0100, Marek Polacek wrote:
You could drop the namespace. Also "struct A" would be better, because
otherwise fn1 is a private and thus unaccessible in fn2.
True. So how about this extended version, which also mentions more examples
of what might now fail?
Index: porting_to.h
On 2/7/2017 07:41, Arnaud Charlet wrote:
This is exactly what aarch64-*-linux* is doing is doing in gcc 6
branch (e.g. system.ads
Well no, you are reusing an x86_64 file for an aarch64 architecture, so
this is exactly the same issue.
I was pointing out that on gcc-6, aarch64-linux is using x8
> I was pointing out that on gcc-6, aarch64-linux is using x86-64
> system file too. Since I used gcc-6 for the original testing on
> freebsd, that's where it came from. It's been changed on trunk, but
> nobody backported those changes to gcc-6. It was obviously "good
> enough" and a "placeholde
Hi Richard,
The attached patch tries to handle ABS_EXPR in gimple-fe.
I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
or parse it as keyword (like __GIMPLE). Currently in the patch, I
parse it as id.
Patch passes gimplefe tests, is it OK to commit after bootstrap+test ?
Thanks,
Pra
Hi all,
Currently, -mprint-tune-info gives an assembly file that cannot be assembled
because the branch cost values
are not properly commented. For example:
@.tune parameters
@constant_limit:1
@max_insns_skipped: 5
@prefetch.num
On Tue, Feb 07, 2017 at 01:44:44PM +, Jonathan Wakely wrote:
> On 07/02/17 14:27 +0100, Marek Polacek wrote:
> > > You could drop the namespace. Also "struct A" would be better, because
> > > otherwise fn1 is a private and thus unaccessible in fn2.
> >
> > True. So how about this extended ver
Hi,
This change deals with reloading a subreg(reg) using the inner mode
to prevent partial spilling of data like in the case described here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660#c8
No test case for now but I am investigating a targeted test using
the RTL frontend for later submissio
Hi,
This patch series addresses a variety of issues in LRA that the MIPS
target has exposed but are not specific to MIPS.
The fixes are primarily related to how WORD_REGISTER_OPERATIONS needs
to be accounted for in LRA SUBREG reloading. In almost all cases LRA
needs to reload the inner REG/MEM/
Hi,
This change addresses a comment from Richard Sandiford in:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02165.html
where a previous fix was over eager in converting OP_OUT reloads to
OP_INOUT.
No testcase here either but I will try and exercise this code later
with a targeted test using the
Hi,
This patch is a minimal change to prevent (subreg(mem)) from being
simplified to use the outer mode for WORD_REGISTER_OPERATIONS. There
is high probability of refining and/or re-implementing this for GCC 8
but such a change would be too invasive. This change at least ensures
correctness but
Hi,
This patch partially reverts r243782 where a return false was added
expecting it to be a no-op. Detailed inspection shows this was not
true. Despite no bug being identified following the change, removing
the early return is likely to be safer than leaving it in place.
This is supported by t
On 07/02/17 15:04 +0100, Marek Polacek wrote:
Thanks much for the review. Looks ok now?
Looks great.
Hi,
This patch addresses a problem with LRA splitting hard registers
where the mode requires multiple registers. When splitting then
each constituent register is split individually using the widest
mode for each register but no check is made that such a mode is
actually supported in those registe
On 2/7/2017 07:53, Arnaud Charlet wrote:
I was pointing out that on gcc-6, aarch64-linux is using x86-64
system file too. Since I used gcc-6 for the original testing on
freebsd, that's where it came from. It's been changed on trunk, but
nobody backported those changes to gcc-6. It was obviousl
On Tue, 7 Feb 2017, Prathamesh Kulkarni wrote:
> Hi Richard,
> The attached patch tries to handle ABS_EXPR in gimple-fe.
> I am not sure if __ABS_EXPR should be parsed as id (like __MEM)
> or parse it as keyword (like __GIMPLE). Currently in the patch, I
> parse it as id.
> Patch passes gimplefe t
On 18/01/17 09:49, Kyrill Tkachov wrote:
On 19/12/16 14:53, Jakub Jelinek wrote:
On Thu, Dec 15, 2016 at 10:00:14AM +, Richard Earnshaw (lists) wrote:
sorry, pasted the wrong bit of code.
That should read when we generate:
(insn 55 19 67 3 (parallel [
(set (reg:SI 0 r0)
Hi!
I'd like to ping:
- P1 PR79299 AVX512{F,VL} -masm=intel v*gather* fixes
http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02409.html
Thanks
Jakub
On Tue, Feb 7, 2017 at 4:11 PM, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping:
>
> - P1 PR79299 AVX512{F,VL} -masm=intel v*gather* fixes
> http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02409.html
LGTM.
Thanks,
Uros.
On 2/7/2017 07:53, Arnaud Charlet wrote:
I was pointing out that on gcc-6, aarch64-linux is using x86-64
system file too. Since I used gcc-6 for the original testing on
freebsd, that's where it came from. It's been changed on trunk, but
nobody backported those changes to gcc-6. It was obviousl
> gcc/ada/Changelog:
> 2017-02-XX John Marino
>
> * system-freebsd-x86.ads: Rename into...
> * system-freebsd.ads: ...this
> (Default_Bit_Order): Define using Standard'Default_Bit_Order
> * gcc-interface/Makefile.in: Support aarch64-freebsd
> (x86_64/FreeBSD): Adju
On Tue, Feb 7, 2017 at 5:19 AM, Richard Biener wrote:
> On Wed, 1 Feb 2017, Richard Biener wrote:
>
>> Applied as follows, bootstrapped & tested on x86_64-unknown-linux-gnu.
>
> And as shown by the new testcase (ICEing on the gcc-6-branch only) the
> fix is not enough as breadth merging of loop an
On Feb 7, 2017, at 2:20 AM, Rainer Orth wrote:
> No. In fact, I'd go for something like this:
>
> 2017-02-07 Dominik Vogt
> Rainer Orth
>
> * g++.dg/tls/thread_local-order2.C: Only xfail execution on
> *-*-solaris*.
>
> # HG changeset patch
> # Parent 031bb7a327cc98
Dear All,
This bug generates an ICE because the symbol for dummy 'n' in the
specification expression for the result of 'fun1' is not the same as
the symbol in the formal arglist. For some reason that I have been
unable to uncover, this false dummy is associated with a unique
symtree. The odd thing
On 18/01/17 17:10, Jiong Wang wrote:
aarch64 cross check OK with the following options enabled on all testcases.
-fstack-protector-all -mstack-protector-pauth
OK for trunk?
gcc/
2017-01-18 Jiong Wang
* config/a
On Feb 6, 2017, at 6:37 PM, Segher Boessenkool
wrote:
>
> Revision r245228 introduced a syntax error in a target selector in
> builtin-apply-2.c: || wants a single expression on each side, you
> cannot have "{a} || {b} || {c}", instead you need to write this as
> "{a} || {{b} || {c}}". In this
On Tue, 7 Feb 2017, Richard Biener wrote:
> I'm not sure whether new RID_ keywords would be prefered for this
> kind of stuff. We added one for __PHI. Joseph, is the RID_ space
> somehow limited so that we should avoid ending up with, say, up to
> 226 RID_s for GIMPLE (upper estimate taken from
On 02/06/2017 07:37 PM, Segher Boessenkool wrote:
Revision r245228 introduced a syntax error in a target selector in
builtin-apply-2.c: || wants a single expression on each side, you
cannot have "{a} || {b} || {c}", instead you need to write this as
"{a} || {{b} || {c}}". In this testcase b and
On 02/06/2017 12:41 PM, Jakub Jelinek wrote:
Hi!
The recent r244993 change where bypass_conditional_jumps is called only
after splitting blocks for unconditional traps can result in ICEs during
bypass_conditional_jumps, because on the (unreachable, to be removed later)
new basic blocks created b
In working on 79393 I ended up in synthesized_method_walk, which is
unnecessarily confusing. This patch cleans it up by,
1) breaking out the base object checking, which can now be called from
two places.
2) move some var declarations to their initializing statement.
committed to trunk.
nathan
This second version of the proposed patch removes redundant and unnecessary
default arguments to the dg-skip-if directive, as requested by Rainer Orth.
Thank you Rainer for your review and feedback.
The test g++.dg/cpp1y/vla-initlist1.C makes assumptions that the memory
used to represent the priv
It would appear that I originally posted this to the wrong list! So
sorry to those have gotten this twice.
This is a test program designed to test 64-bit Microsoft ABI functions
that call System V functions in a multitude of permutations to attempt
to discover flaws in the generation of prologues
This patch addresses issues Richi raised from V1. Specifically the
users of overflow_comparison_1 don't need to worry about trying both the
original comparison and the reversed comparison. This slightly
simplifies the callers.
Bootstrapped and regression tested as part of the full patch seri
This patch addresses issues Richi raised from V1. Specifically it moves
EXACT_DIV_EXPR handling into extract_range_from_binary_expr_1 and less
aggressively uses ~[0,0] when intersecting ranges -- only doing so when
vr1's range is > 65536 elements. That number is highly arbitrary. I'm
certa
This patch addresses issues Richi raised from V1. Specifically it
relieves the callers from having to try op0 COND op1 and op1 COND' op0
separately and adds some additional comments about motivation. There
may have been minor nits Richi pointed out, if so, they were addressed
as well.
Boo
This is unchanged from the original posting. Reposting to make review
easier.
The tests in g++.dg start with a reduced test from Martin (pr79095-1.C)
that includes a size check. With the size != 0 check this testcase
should not issue any warnings as the path that turns into a
__builtin_m
On 02/07/2017 01:39 AM, Richard Biener wrote:
On Mon, Feb 6, 2017 at 10:57 PM, Jeff Law wrote:
On 02/06/2017 08:33 AM, Richard Biener wrote:
ah, indeed vr0type is VR_ANTI_RANGE and yes we have the case of a
range with an anti-range "inside". This also covers [-1,1] v
~[0,0] where you choose
I apologize to those of you who get this twice, but I accidentally
posted to the wrong list!
Uros or Jan,
Please take this as a ping, as I never bothered pinging after submitting
v2 since I found a few more issues with it. :) Although I realize this
would be a GCC 8 stage 1 item, I would like
Adds the option to i386.opt and i386.c and adds documentation to
invoke.texi.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 3 ++-
gcc/config/i386/i386.opt | 5 +
gcc/doc/invoke.texi | 11 ++-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/gcc/co
Of the new fields added to struct machine_function, outline_ms_sysv is
initially set in ix86_expand_call, but may later be cleared when
ix86_compute_frame_layout is called (both of these are in subsequent
patch). If it is not cleared, then the remaining new fields will be
set.
The new class xloug
For the sake of clarity, I've separated out these minor refactoring
changes from the rest of the patches.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 21 ++---
gcc/config/i386/i386.h | 4 +++-
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/gcc/con
Adds HARD_REG_SET stub_managed_regs to track registers that will be
managed by the pro/epilogue stubs for the function.
Adds a third parameter bool ignore_outlined to ix86_save_reg to specify
rather or not the count should include registers marked in
stub_managed_regs.
Signed-off-by: Daniel Santo
ix86_compute_frame_layout will now populate fields added to structs
machine_function and ix86_frame and modify the frame layout specific to
facilitate the use of save & restore stubs.
Signed-off-by: Daniel Santos
---
gcc/config/i386/i386.c | 105 +++--
Adds libgcc/config/i386/i386-asm.h to manage common cpp and gas macros.
stubs use the following naming convention:
(sav|res)ms64[f][x]
save|resSave or restore
ms64Avoid possible name collisions with future stubs
(specific to 64-bit msabi --> sysv scenario)
Adds the predicates save_multiple and restore_multiple to predicates.md,
which are used by following patterns in sse.md:
* save_multiple - insn that calls a save stub
* restore_multiple - call_insn that calls a save stub and returns to the
function to allow a sibling call (which should typically
On Feb 7, 2017, at 10:00 AM, Kelvin Nilsen wrote:
>
> While these assumptions are valid with some optimization choices on some
> architectures, these assumptions do not hold universally.
> Is this ok for trunk?
Ok.
I'm working on the assumption that this doesn't fail too often. If it did,
th
All,
The attach patch maps REAL128 from iso_fortran_env to
the REAL kind type with widest precision. Prior to
this patch, REAL128 is mapped to the first REAL kind
type with a matching storage size of 128 bits. On
x86_64-*-freebsd both REAL(10) and REAL(16) occupy
16 bytes, but REAL(10) is mapp
Hi,
current trunk ipa-prop passes NULL by C++ reference to
ipa_alloc_node_params when analyzing functions without any parameters
which is harmless because that function immediately returns but is
undefined and ubsan rightly complains about it. The following patch
avoids calling the call under suc
On Feb 7, 2017, at 10:27 AM, Daniel Santos wrote:
>
> This is a test program designed to test 64-bit Microsoft ABI functions
> that call System V functions in a multitude of permutations to attempt
> to discover flaws in the generation of prologues and epilogues and the
> optimizations and featur
The attached documentation-only patch clarifies the description
of the -dM option to mention that __FILE__ (and other predefined
macros) do no appear on the list generated by the option.
Martin
PR preprocessor/41540 - -dM -E doesn't #define __FILE__
gcc/ChangeLog:
PR preprocessor/41540
* do
Approved.
And thanks for the reminder about the MAINTAINERS file.
On Tue, Feb 7, 2017 at 2:45 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> I tried building a cc1 for riscv-x-elf and I got a build error about
> INT16_MAX not being defined on my system.
> I think it's not a standard macro. This patch
Currently, clang rejects all attempts to visit a libstdc++ variant:
https://godbolt.org/g/kSmBTg
While gcc doesn't reject such code, that seems like an access checking
bug. This patch makes the offending _M_u member accessible for the rest
of the code.
2017-02-07 Ville Voutilainen
Fix an
Le 07/02/2017 à 19:46, Steve Kargl a écrit :
All,
The attach patch maps REAL128 from iso_fortran_env to
the REAL kind type with widest precision. Prior to
this patch, REAL128 is mapped to the first REAL kind
type with a matching storage size of 128 bits. On
x86_64-*-freebsd both REAL(10) and R
I am surprised this old URL has survived as long (and as it turns
out in as many places).
Of course I had put a redirect in place (cf. wwwdocs/htdocs/.htaccess),
so perhaps that is why we did not notice this earlier.
Applied (as revision 245253).
Gerald
2017-02-07 Gerald Pfeifer
*
Hi!
As mentioned in the PR, on a huge function init_costs attempts to allocate
124 * 17380077 bytes, 124 is max_struct_costs_size and 17380077
is cost_elements_num. The problem is that the multiplication is done in
int type, so it overflows and we attempt to allocate 0x8074aacc
bytes. Ot
On Tue, Feb 7, 2017 at 9:13 AM, Jonathan Wakely wrote:
> On 07/02/17 15:04 +0100, Marek Polacek wrote:
>>
>> Thanks much for the review. Looks ok now?
I'd suggest adding something to say that the reason these are now
being diagnosed is that G++ used to treat e.g. this->member, where
member has a
Hi!
While looking at the RTL problem when combiner optimizes away
(x & 0xfffe) % 0x into just (x & 0xfffe), I've looked at VRP
which optimizes that case well (-O2 only, the PR is -O1), but discovered
that it isn't generic enough, we actually don't need op1 to be constant
in this case, a range
On 7 February 2017 at 22:00, Ville Voutilainen
wrote:
> Currently, clang rejects all attempts to visit a libstdc++ variant:
> https://godbolt.org/g/kSmBTg
>
> While gcc doesn't reject such code, that seems like an access checking
> bug. This patch makes the offending _M_u member accessible for the
Hi!
P0017R1 added in [dcl.init.aggr]/1 that classes with inherited constructors
are not aggregate. CLASSTYPE_NON_AGGREGATE is set slightly before
add_implicitly_declared_members is called and so we don't know about the
inherited ctors yet.
Not 100% sure if we want to do this even for -std=c++1z
On 02/07/2017 04:17 PM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, on a huge function init_costs attempts to allocate
124 * 17380077 bytes, 124 is max_struct_costs_size and 17380077
is cost_elements_num. The problem is that the multiplication is done in
int type, so it overflows and we
On Sun, 5 Feb 2017, Gerald Pfeifer wrote:
> ...which is now asking for username and password.
And here are some further updates for our go-parts.com mirror,
removing the rsync mirror and adding Dan as a contact.
Applied.
Gerald
Index: mirrors.html
===
On Mon, 6 Feb 2017, Jakub Jelinek wrote:
>> One old link in svn.html contained "319433-020" in its file name, the
>> new one I found shows "319433-028" on the title page, so I assume this
>> is a newer version of the same?
> Unfortunately not. In -025 they've removed most of the instructions
> fr
On 02/07/2017 09:08 AM, Matthew Fortune wrote:
Hi,
This patch addresses a problem with LRA splitting hard registers
where the mode requires multiple registers. When splitting then
each constituent register is split individually using the widest
mode for each register but no check is made that
On 02/07/2017 09:08 AM, Matthew Fortune wrote:
Hi,
This patch partially reverts r243782 where a return false was added
expecting it to be a no-op. Detailed inspection shows this was not
true. Despite no bug being identified following the change, removing
the early return is likely to be safe
On 02/07/2017 09:08 AM, Matthew Fortune wrote:
Hi,
This patch is a minimal change to prevent (subreg(mem)) from being
simplified to use the outer mode for WORD_REGISTER_OPERATIONS. There
is high probability of refining and/or re-implementing this for GCC 8
but such a change would be too invas
On 02/07/2017 09:08 AM, Matthew Fortune wrote:
Hi,
This change deals with reloading a subreg(reg) using the inner mode
to prevent partial spilling of data like in the case described here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660#c8
No test case for now but I am investigating a targe
What difference a single letter can make...
Applied (revision 245257).
Gerald
2017-02-07 Gerald Pfeifer
* doc/xml/manual/status_cxx2017.xml: Fix link to N4284.
Index: doc/xml/manual/status_cxx2017.xml
===
--- doc/xml/m
On 02/07/2017 09:08 AM, Matthew Fortune wrote:
Hi,
This change deals with reloading a subreg(reg) using the inner mode
to prevent partial spilling of data like in the case described here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660#c8
No test case for now but I am investigating a targe
On Tue, Feb 07, 2017 at 11:02:38PM +0100, Gerald Pfeifer wrote:
> On Mon, 6 Feb 2017, Jakub Jelinek wrote:
> >> One old link in svn.html contained "319433-020" in its file name, the
> >> new one I found shows "319433-028" on the title page, so I assume this
> >> is a newer version of the same?
> >
The natural replacement would be
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.tr1
alas that is for the current version of GCC, and I doubt even a link
to the then current version would be of value.
Applied.
Gerald
Index: gcc-4.2/changes.html
This patch was submitted last year by Andrew Pinski, this is a
resubmit/ping of that patch.
https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01726.html
During the initial submittal James Greenhalgh asked if this was an ABI change.
I do not believe it is because while it is changing the size
On Tue, Jan 3, 2017 at 1:04 PM, Andrew Pinski wrote:
> Ping?
>
> On Sat, Dec 10, 2016 at 1:24 PM, Andrew Pinski wrote:
>> On Thu, Nov 10, 2016 at 6:58 PM, Andrew Pinski wrote:
>>> On Tue, Oct 25, 2016 at 3:25 PM, Matthias Klose wrote:
On 07.10.2016 23:08, Andrew Pinski wrote:
> Hi,
>>>
I noticed that http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
has a broken link to http://gcc.gnu.org/onlinedocs/libitm/Enabling-libitm.html
At which point I noticed that we simply never added libitm documentation
to our onlinedocs.
Fixed thusly, tested on gcc.gnu.org, and also install
Applied.
Gerald
2017-02-08 Gerald Pfeifer
* doc/xml/manual/abi.xml: Update link to "Sun Studio 11: C++
Migration Guide".
Index: doc/xml/manual/abi.xml
===
--- doc/xml/manual/abi.xml (revision 245252)
+++ doc
Update link to OpenMP 4.5 standard; remove links to older versions
in the news section.
(Kudos to the OpenMP webmaster for not actually breaking any of these.)
Applied.
Gerald
Index: projects/gomp/index.html
===
RCS file: /cvs/gcc/
Thanks for the quick action Paul - I hope the fix goes through
A small correction in the example problem though: there is no begin
program statement in your snippet. It still fails, as is, due to the
ICE, but I think if you make the fix this example program will still
fail to compile. A simple `pr
These were suggested as part of our review process, but I never got an OK on
them. Am I meant to just commit these?
Index: htdocs/backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.73
diff -u
On 02/07/2017 01:12 PM, Mike Stump wrote:
On Feb 7, 2017, at 10:27 AM, Daniel Santos wrote:
This is a test program designed to test 64-bit Microsoft ABI functions
that call System V functions in a multitude of permutations to attempt
to discover flaws in the generation of prologues and epilogue
I could find a replacement link for ARC on synopsys.com, but
failed for the two Fortran test references and the link on
tru64unix.compaq.com.
Applied.
Gerald
Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,
I'm a little surprised how many different places in GCC carry the
bug reporting URL (this must make it hard for distributors to find
and patch all of them) and why there is this one in the depths of
a sole source file in libstdc++, but at least it was easy enough to
fix.
Applied.
Gerald
2017-02
Applied (revision 245269).
Gerald
2017-02-08 Gerald Pfeifer
* doc/xml/manual/profile_mode.xml: Unbreak link to
"Optimizing Sorting with Machine Learning Algorithms".
2017-02-08 Gerald Pfeifer
Index: doc/xml/manual/profile_mode.xml
===
100 matches
Mail list logo
