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
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
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
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: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,
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.
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
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
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
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 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
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,
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
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
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.
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
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 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)))
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 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
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
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
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 git bisect doesn't work on gcc trunk in GCC git mirror
for commits around
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 working as designed.
But this doesn't help
Jason Merrill ja...@redhat.com writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in a sensible order, but the history is available.
That would be worse, since changes are
One other thing to watch out for in the conversion:
* Where trunk got accidentally deleted and recreated as a copy of the
trunk version before the deletion (recreations r130805, r184997), make
sure this doesn't get represented as deletion followed by recreation of
all files on trunk. (It
On 08/21/2015 04:10 PM, Joseph Myers wrote:
On Fri, 21 Aug 2015, Jason Merrill wrote:
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
On 08/21/2015 03:21 PM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in a sensible order, but the history is
On Fri, 21 Aug 2015, Jason Merrill wrote:
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
branches created by $user to be in
On Fri, 21 Aug 2015, Jason Merrill wrote:
We should also talk about a policy for when we delete branches; there are a
bunch of ancient feature and testing branches in SVN that I think are no
longer interesting.
My view is don't delete (except for leaving user / company branches up to
those
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 03:21 PM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in
On 08/21/2015 11:26 AM, Joseph Myers wrote:
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
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
branches created by $user to be in namespace $user?
git will create new namespaces for its
On 08/21/2015 11:30 AM, Ramana Radhakrishnan wrote:
My query was whether allowing for rebase (rewriting history) in
published feature branches was a decision to be left to the branch
maintainers or was this going to be a repository wide restriction. It
also seems odd to me that trunk follows a
Jason Merrill ja...@redhat.com writes:
I had been thinking of namespace as a subdirectory of refs/heads.
If Richard wants something not pulled by default, then he must have
thought of something outside of refs/heads.
But now I see that there is something called namespace in git.
Where did
Jason Merrill ja...@redhat.com writes:
I would expect feature branches to merge from trunk when needed during
development. When merging the feature into trunk the developer can just
use git merge --squash and then decide whether to commit it in one hunk or
several.
This will of course lose
On 08/21/2015 02:28 PM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
I would expect feature branches to merge from trunk when needed during
development. When merging the feature into trunk the developer can just
use git merge --squash and then decide whether to commit it in
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 delete the branch before pushing
again.
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. Khedker
u...@cse.iitb.ac.in
wrote:
Why is this different? Why is __comp_ctor not
On Wed, Aug 19, 2015 at 11:02:14PM -0700, David Wohlferd wrote:
how about replacing the existing
text (It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.) with
Do not use this feature with a non-static local variable.
On 21 August 2015 at 12:25, Richard Biener wrote:
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
On Thu, 2015-08-20 at 18:37 -0400, Jason Merrill wrote:
On 08/20/2015 06:32 PM, Segher Boessenkool wrote:
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill ja...@redhat.com 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
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Friday, August 21, 2015 2:03 PM
To: Ajit Kumar Agarwal
Cc: Jeff Law; GCC Patches; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta;
Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [RFC]:
Hi,
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that
On Fri, Aug 21, 2015 at 7:18 AM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
All:
I have done the vectorization cost changes as given below. I have considered
only the cost associated with the inner instead of outside.
The consideration of inside scalar and vector cost is done as
Hi,
On Thu, Aug 20, 2015 at 05:32:26PM -0500, Segher Boessenkool wrote:
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?
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/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
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 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
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
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
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
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
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
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 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:
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
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
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
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
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
1 - 100 of 207 matches
Mail list logo
