On 08/21/2015 07:54 PM, David Malcolm wrote:
pHere's an actual check-in session for a patch John Carr recently
Can this really be described as an actual check-in session when we're
changing the contents? :)
Jason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67316
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67317
Bug ID: 67317
Summary: [x86] Silly code generation for
_addcarry_u32/_addcarry_u64
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: minor
On 08/21/2015 06:44 PM, Mikhail Maltsev wrote:
On 08/20/2015 11:09 PM, Jason Merrill wrote:
Absolutely, a non-fast-forward push is anathema for anything other people might
be working on. The git repository already prohibits this; people that want to
push-rebase-push their own branches need to
On 08/18/2015 10:00 PM, Jeff Law wrote:
On 08/14/2015 10:02 PM, Mikhail Maltsev wrote:
gcc/ChangeLog:
2015-08-15 Mikhail Maltsev malts...@gmail.com
* dominance.c (new_zero_array): Define.
(dom_info): Redefine as class with proper encapsulation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67302
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67306
Bug ID: 67306
Summary: Patterns ICEs when moved using simplify and match
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The git repository already prohibits this; people that
want to push-rebase-push their own branches need to delete the branch before
pushing again.
On the FSF trunk and the main release branches -
On Fri, Aug 21, 2015 at 12:44 PM, Uday P. Khedker u...@cse.iitb.ac.in wrote:
On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker u...@cse.iitb.ac.in
wrote:
Why is this different? Why is __comp_ctor not invoked in each case?
This looks like the
2015-08-21 11:15 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Thu, Aug 20, 2015 at 8:46 PM, Jeff Law l...@redhat.com wrote:
On 08/17/2015 10:25 AM, Ilya Enkovich wrote:
Hi,
This patch intoriduces a new vectorizer hook use_scalar_mask_p which
affects code generated by
This fixes the libgo breakage. Seems I really should have removed the
edge after we split the block with null dereference after __builtin_trap
statement so that it's unreachable.
Bootstrapped/regtested on x86_64-linux + ppc64-linux + bootstrapped on
aarch64-linux, ok for trunk?
2015-08-21
On 21 August 2015 at 09:26, Richard Biener wrote:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good, the future bad) - I've tried to find a change that was _fixing_
a problem,
On Fri, Aug 21, 2015 at 12:49 PM, Ilya Enkovich enkovich@gmail.com wrote:
2015-08-21 11:15 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Thu, Aug 20, 2015 at 8:46 PM, Jeff Law l...@redhat.com wrote:
On 08/17/2015 10:25 AM, Ilya Enkovich wrote:
Hi,
This patch intoriduces a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
--- Comment #6 from Vittorio Zecca zeccav at gmail dot com ---
A shorter source file displaying the same bug:
// from pr42049.c
// gcc -funroll-loops -O
// ../../gcc-5.2.0/gcc/loop-iv.c:2670:14: runtime error:
// signed integer overflow: 7 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 21 August 2015 at 09:26, Richard Biener wrote:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67305
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker u...@cse.iitb.ac.in wrote:
Why is this different? Why is __comp_ctor not invoked in each case?
This looks like the function has been inlined as it is short.
Thanks, this is a useful lead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67302
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The git repository already prohibits this; people that
want to push-rebase-push their own branches need to delete the branch before
pushing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:
-D generate documentation
The driver needs to know what's an option and what's an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #13 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Looks like the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957
may have fixed this one, too.
Claudiu reported that I'd botched the definition of LAST_INSN_CODE
in my recent patches to reduce the size of insn_data. I'd defined
it as the last valid insn code, whereas it's supposed to be the
last valid code +1.
This patch replaces LAST_INSN_CODE with a separate NUM_INSN_CODES
count,
On Fri, Aug 21, 2015 at 12:52 PM, Marek Polacek pola...@redhat.com wrote:
This fixes the libgo breakage. Seems I really should have removed the
edge after we split the block with null dereference after __builtin_trap
statement so that it's unreachable.
Bootstrapped/regtested on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67306
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 36233
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36233action=edit
patch
Patch I am testing
On Thu, 20 Aug 2015, Richard Biener wrote:
On Thu, 20 Aug 2015, Richard Biener wrote:
On Wed, 19 Aug 2015, Richard Biener wrote:
On Tue, 18 Aug 2015, Aldy Hernandez wrote:
On 08/18/2015 07:20 AM, Richard Biener wrote:
This starts a series of patches (still in
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill ja...@redhat.com wrote:
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
--- Comment #8 from Vittorio Zecca zeccav at gmail dot com ---
Maybe the easiest way to reproduce the issue is as in the following;
gdb ~/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1
GNU gdb (GDB) Fedora 7.8.2-39.fc21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
--- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01308.html
On 2015.08.21 at 06:47 -0700, H.J. Lu wrote:
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a
Richard Sandiford richard.sandif...@arm.com writes:
Claudiu reported that I'd botched the definition of LAST_INSN_CODE
in my recent patches to reduce the size of insn_data. I'd defined
it as the last valid insn code, whereas it's supposed to be the
last valid code +1.
This patch replaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308
Bug ID: 67308
Summary: FATAL: ThreadSanitizer: unexpected memory mapping
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
Hi Ville. Unfortunately it still fails for me, in the same way. Are you using
the complete testcase, including the line outside namespace std?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67307
--- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
I don't see an obvious reason to disregard limits here, but haven't
checked the history of the code. C99 inline functions must always have an
extern version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc
H.J. Lu hjl.to...@gmail.com writes:
One very frustrating thing for me is git bisect doesn't always
work. I think cherry-pick is OK, but probably not rebase nor merge.
Can we enforce that git bisect must work on official branches?
bisect works fine with merges.
Andreas.
--
Andreas Schwab,
On Fri, Aug 21, 2015 at 6:59 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
BTW while I have your attention: Why are you constantly creating
(rebasing) and deleting branches? Why not simply use a local git tree
for this purpose?
I want to share my branches with people who have no
On Fri, Aug 21, 2015 at 01:27:43PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:52 PM, Marek Polacek pola...@redhat.com wrote:
This fixes the libgo breakage. Seems I really should have removed the
edge after we split the block with null dereference after __builtin_trap
statement
Hi,
On 08/21/2015 11:23 AM, Markus Trippelsdorf wrote:
On 2015.08.21 at 11:06 +0200, Paolo Carlini wrote:
... I'm testing the below. So far appears to work well for me.
Yes for me, too. Firefox now builds without any issues.
So emitting an error (like clang) is fine after all.
Excellent.
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The git repository already prohibits this; people that
want to
On Fri, Aug 21, 2015 at 2:49 PM, Marek Polacek pola...@redhat.com wrote:
On Fri, Aug 21, 2015 at 01:27:43PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:52 PM, Marek Polacek pola...@redhat.com wrote:
This fixes the libgo breakage. Seems I really should have removed the
edge after
2015-08-20 21:41 GMT+03:00 Jeff Law l...@redhat.com:
On 08/17/2015 10:22 AM, Ilya Enkovich wrote:
Hi,
This patch starts a series introducing scalar masks support in the
vectorizer. It was discussed on the recent Cauldron and changes overiew is
available here:
Richard Biener richard.guent...@gmail.com writes:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good, the future bad) - I've tried to find a change that was _fixing_
a problem,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67306
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
-Original Message-
From: Richard Sandiford [mailto:richard.sandif...@arm.com]
Sent: Friday, August 21, 2015 1:15 PM
To: gcc-patches@gcc.gnu.org
Cc: Claudiu Zissulescu; Claudiu Zissulescu; Francois Bedard; Jeff Law
Subject: RFA: Replace LAST_INSN_CODE with NUM_INSN_CODES
Claudiu
On Thu, 2015-08-06 at 10:52 -0400, David Malcolm wrote:
Ping:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00355.html
In particular, I'm hoping for review of patch 1, which provides a way to
clean up state within the driver code (patch 2 uses this from libgccjit
to embed it in-process, rather
On Fri, Aug 21, 2015 at 3:09 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a different model could use a separate repo shared by
those
Hello,
Please have a look at updated patch.
On Tue, Aug 4, 2015 at 3:15 PM, Richard Biener rguent...@suse.de wrote:
On Fri, 31 Jul 2015, Petr Murzin wrote:
@@ -5586,8 +5770,6 @@ vectorizable_store (gimple stmt,
gimple_stmt_iterator *gsi, gimple *vec_stmt,
prev_stmt_info = NULL;
for (j
On 08/21/2015 09:47 AM, H.J. Lu wrote:
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward
Hi,
On 08/21/2015 02:57 PM, Jonathan Wakely wrote:
On 21/08/15 00:03 +0200, Paolo Carlini wrote:
Hi,
On 08/20/2015 10:21 PM, Jonathan Wakely wrote:
Jason pointed out this isn't valid, and is going to fail to compile
soon with a fix he's making.
I seem to remember that at some point we had
On Fri, Aug 21, 2015 at 1:41 PM, Swati Rathi swatira...@cse.iitb.ac.in wrote:
On 2015-08-21 16:16, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:44 PM, Uday P. Khedker u...@cse.iitb.ac.in
wrote:
On 08/19/2015 04:44 PM, Andrew Pinski wrote:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P.
bootstrap-ubsan shows:
loop-iv.c:2626:14: runtime error: signed integer overflow: 9223372036854775806
- -9223372036854775808 cannot be represented in type 'long int'
Fixed by moving the variables in question from signed to unsigned.
Bootstrapped and tested on ppc64le.
OK for trunk and gcc-5
On 20/08/15 09:36, Kyrylo Tkachov wrote:
On 19/08/15 12:49, Renlin Li wrote:
Hi all,
This simple patch will tighten the conditions when matching movw and
arm_movt rtx pattern.
Those two patterns will generate the following assembly:
movw w1, #:lower16: dummy + addend
movt w1, #:upper16:
This is yet another bug caused by rtx having modeless scalar integer
constants. We need to use context to find the actual mode of a
CONST_INT or CONST_WIDE_INT.
Getting a mode is especially awkward here. Decls have two modes
associated with them: TYPE_MODE (TREE_TYPE (decl)) and DECL_MODE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67304
--- Comment #3 from Iain Buclaw ibuclaw at gdcproject dot org ---
(In reply to jos...@codesourcery.com from comment #1)
On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:
-D generate documentation
The driver needs to
On Fri, Aug 21, 2015 at 03:37:38PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 2:49 PM, Marek Polacek pola...@redhat.com wrote:
On Fri, Aug 21, 2015 at 01:27:43PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:52 PM, Marek Polacek pola...@redhat.com wrote:
This fixes the
2015-08-21 14:00 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Fri, Aug 21, 2015 at 12:49 PM, Ilya Enkovich enkovich@gmail.com
wrote:
2015-08-21 11:15 GMT+03:00 Richard Biener richard.guent...@gmail.com:
On Thu, Aug 20, 2015 at 8:46 PM, Jeff Law l...@redhat.com wrote:
On
On Mon, 2015-08-17 at 13:16 +0200, Gleb Fotengauer-Malinovskiy wrote:
On Sun, Aug 16, 2015 at 07:35:17PM +0200, Torvald Riegel wrote:
On Thu, 2015-06-11 at 14:36 +0300, Gleb Fotengauer-Malinovskiy wrote:
On Fri, May 15, 2015 at 03:04:27PM +0200, Torvald Riegel wrote:
On Wed, 2015-05-06
On 21/08/15 00:03 +0200, Paolo Carlini wrote:
Hi,
On 08/20/2015 10:21 PM, Jonathan Wakely wrote:
Jason pointed out this isn't valid, and is going to fail to compile
soon with a fix he's making.
I seem to remember that at some point we had the exact same issue with
some member operator and
On 08/21/2015 04:26 AM, Richard Biener wrote:
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill ja...@redhat.com wrote:
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient branch,
push-rebase-push on that branch,
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a different model could use a separate repo shared by
those developers, not the gcc.gnu.org one. It's much easier to do that
with git.
Yes
I've committed this patch to:
1) Remove the partitioning field I recently added to call_insn patterns. It
will not be needed.
2) Change the fork/join and associated instructions and machinery to have a
partioning mask, rather than a mode. This allows them to specify multiple modes
On 08/21/2015 08:41 AM, Marek Polacek wrote:
On Fri, Aug 21, 2015 at 03:37:38PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 2:49 PM, Marek Polacek pola...@redhat.com wrote:
On Fri, Aug 21, 2015 at 01:27:43PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:52 PM, Marek Polacek
On 08/20/2015 02:09 PM, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with the compiler
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner berg...@vnet.ibm.com wrote:
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a
On 08/21/2015 02:15 AM, Richard Biener wrote:
Indeed. I don't remember my exact comments during the talk at the
Cauldron but the scheme used there was sth like
mask = GEN_MASK vec1 vec2; b = a + 1; x = VEC_COND mask, a, b
to model conditional execution already at the if-conversion stage
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner berg...@vnet.ibm.com wrote:
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a
H.J. Lu hjl.to...@gmail.com writes:
On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
git bisect good/git bisect bad land my tree not on trunk when
they are used on commits from wide-int branch merge.
Yes, that is bisect
It's nice that GCC has included a constructor attribute, but it
doesn't work in complex scenarios.
I was considering tinkering with adding a 'initializer' and '?exiter'
or maybe 'deinitializer'? (not sure what to name the other side) But
on to the primary...
__attribute((initializer(priority)))
2015-08-03 23:52 GMT+03:00 Jeff Law l...@redhat.com:
On 06/19/2015 07:21 AM, Ilya Enkovich wrote:
Hi,
This patch tries to improve 64bit integer computations on 32bit
target. This is achieved by an additional i386 target pass which
searches for all conversion candidates and tries to
On 08/21/2015 08:41 AM, Marek Polacek wrote:
On Fri, Aug 21, 2015 at 03:37:38PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 2:49 PM, Marek Polacek pola...@redhat.com wrote:
On Fri, Aug 21, 2015 at 01:27:43PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:52 PM, Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 58972, which changed state.
Bug 58972 Summary: Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
What|Removed |Added
On 08/21/2015 02:10 AM, FX wrote:
Attached patch removes special cases for the following unsupported targets as
build and host environments:
- uwin*
- i370-*-opened* | i370-*-mvs*
- i[34567]86-*-sco3.2v5*
- i[34567]86-sequent-ptx4* | i[34567]86-sequent-sysv4*
- i[34567]86-*-sysv4*
-
On 08/21/2015 07:44 AM, Ilya Enkovich wrote:
Our of curiosity, what does LLVM do here in terms of costing
models?
Unfortunately I have no idea where and how LLVM does this
optimization. Will try to find out. For now I just try to follow a
common sense and don't hurt any benchmark performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67310
Bug ID: 67310
Summary: [PATCH] gcc 4.8.4 fails to compile with -march=native
on VIA nano CPU
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity:
On Fri, Aug 21, 2015 at 06:23:09PM +0200, Richard Biener wrote:
Yes, but gimple_call_noreturn_p is false on __builtin_trap. That's
quite
confusing... but flags_from_decl_or_type really returns 0 for
__builtin_trap.
Well, if that's intentional (and offhand I have no idea if it is), then
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a different model could use a separate repo shared by
those developers, not the
On 08/20/15 18:52, Joseph Myers wrote:
On Tue, 18 Aug 2015, Thomas Schwinge wrote:
This is what I've committed to gomp-4_0-branch, with the driver changes
substantially cleaned up and smaller changes to the other bits of the
patch.
gcc:
2015-08-20 Thomas Schwinge tho...@codesourcery.com
On 08/21/2015 07:58 AM, Richard Sandiford wrote:
This is yet another bug caused by rtx having modeless scalar integer
constants. We need to use context to find the actual mode of a
CONST_INT or CONST_WIDE_INT.
We've been bumping into these as long as I can remember. I suspect I
still have a
On August 21, 2015 5:09:46 PM GMT+02:00, Jeff Law l...@redhat.com wrote:
On 08/21/2015 08:41 AM, Marek Polacek wrote:
On Fri, Aug 21, 2015 at 03:37:38PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 2:49 PM, Marek Polacek pola...@redhat.com
wrote:
On Fri, Aug 21, 2015 at 01:27:43PM
On 08/21/2015 07:40 AM, Markus Trippelsdorf wrote:
bootstrap-ubsan shows:
loop-iv.c:2626:14: runtime error: signed integer overflow:
9223372036854775806 - -9223372036854775808 cannot be represented in type 'long
int'
Fixed by moving the variables in question from signed to unsigned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
On Fri, Aug 21, 2015 at 7:33 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
One very frustrating thing for me is git bisect doesn't always
work. I think cherry-pick is OK, but probably not rebase nor merge.
Can we enforce that git bisect must work on
On Fri, 21 Aug 2015, H.J. Lu wrote:
Can we enforce that git bisect must work on official branches?
I think a good principle independent of moving to git is that commits
should be bisectable. In particular, if a patch series is committed as
separate commits, each commit should be intended to
On 08/21/2015 05:06 AM, Paolo Carlini wrote:
if (DECL_NAME (decl)
MAIN_NAME_P (DECL_NAME (decl))
- CP_DECL_CONTEXT (decl) == global_namespace)
+ CP_DECL_CONTEXT (decl) == global_namespace
+ !at_function_scope_p ())
How about looking at the scope local variable
H.J. Lu hjl.to...@gmail.com writes:
git bisect good/git bisect bad land my tree not on trunk when
they are used on commits from wide-int branch merge.
Yes, that is bisect working as designed.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756
2015-08-21 18:57 GMT+03:00 Jeff Law l...@redhat.com:
On 08/21/2015 06:30 AM, Ilya Enkovich wrote:
2015-08-20 21:41 GMT+03:00 Jeff Law l...@redhat.com:
2015-08-17 Ilya Enkovich enkovich@gmail.com
* expr.c (expand_expr_real_2): Support GEN_MASK_EXPR.
*
This patch implements the the goacc.reduction hook introduced here
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01130.html for the nvptx
target. Each new nvptx_goacc_reduction_* function is commented with a
description of how each internal function gets implemented for each
parallel dimension.
On Fri, 21 Aug 2015, Nathan Sidwell wrote:
this appears to cause an ICE in add_omp_infile_spec_func at;
gcc_assert (offload_targets != NULL);
when you use something like -foffload='-save-temps -v -fdump-rtl-all
-fdump-tree-all -fno-verbose-asm'
Is that use ill-formed?
I'll need to
On 08/21/2015 08:36 AM, Richard Sandiford wrote:
Richard Sandiford richard.sandif...@arm.com writes:
Claudiu reported that I'd botched the definition of LAST_INSN_CODE
in my recent patches to reduce the size of insn_data. I'd defined
it as the last valid insn code, whereas it's supposed to be
On August 21, 2015 5:09:46 PM GMT+02:00, Jeff Law l...@redhat.com wrote:
On 08/21/2015 08:41 AM, Marek Polacek wrote:
On Fri, Aug 21, 2015 at 03:37:38PM +0200, Richard Biener wrote:
On Fri, Aug 21, 2015 at 2:49 PM, Marek Polacek pola...@redhat.com
wrote:
On Fri, Aug 21, 2015 at 01:27:43PM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67309
Bug ID: 67309
Summary: Error compiling with -std=c++11 and
-fsingle-precision-constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816
--- Comment #4 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Sorry for the noise, I managed to drop out that last line, bummer. So no, this
hasn't been fixed yet.
On Fri, Aug 21, 2015 at 8:39 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
up to date by git merge origin/master. I never tried git bisect
on it since I know that commits on that branch aren't consecutive.
bisect works with any kind of repository.
Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
--- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Author: trippels
Date: Fri Aug 21 16:44:30 2015
New Revision: 227075
URL: https://gcc.gnu.org/viewcvs?rev=227075root=gccview=rev
Log:
Fix PR61657 (undefined behavior in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 61657, which changed state.
Bug 61657 Summary: Undefined behavior in loop-iv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657
What|Removed |Added
1 - 100 of 207 matches
Mail list logo
