On Wed, Feb 19, 2014 at 08:43:14PM -0800, Linus Torvalds wrote:
On Wed, Feb 19, 2014 at 8:01 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
The control dependency should order subsequent stores, at least assuming
that a and b don't start off with identical stores that the compiler
On Thu, Feb 20, 2014 at 12:30:32AM -0800, Paul E. McKenney wrote:
On Wed, Feb 19, 2014 at 08:43:14PM -0800, Linus Torvalds wrote:
[ . . . ]
So, if you make one of two changes to your example, then I will agree
with you. The first change is to have a real data dependency between
the read of
On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 13 February 2014 20:47, Patrick Palka wrote:
On a related note, would a patch to officially enable
-Wmissing-declarations in the build process be well regarded?
What would be the advantage?
A missing declaration
On Wed, Feb 19, 2014 at 11:19 PM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin renato.go...@linaro.org wrote:
On 19 February 2014 11:58, Richard Sandiford
rsand...@linux.vnet.ibm.com wrote:
I agree that having an unrecognised asm shouldn't be a hard
On 20 February 2014 10:11, Ramana Radhakrishnan
ramana@googlemail.com wrote:
The current behaviour is that when the compiler generates code for
Thumb1 and Thumb2 we switch back to the appropriate state after inline
assembler is emitted. We don't switch back to ARM state on the (fairly
On Wed, 19 Feb 2014, Jan Hubicka wrote:
On Tue, 18 Feb 2014, Jan Hubicka wrote:
Non-ODR types born from other frontends will then need to be made to
alias all the ODR variants that can be done by storing them into the
current canonical type hash.
(I wonder if we want to
On 19/02/14 23:19, Andrew Pinski wrote:
On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin renato.go...@linaro.org wrote:
On 19 February 2014 11:58, Richard Sandiford
rsand...@linux.vnet.ibm.com wrote:
I agree that having an unrecognised asm shouldn't be a hard error until
assembly time though.
Hi,
I am using sets of stl in gcc. I need to perform operations like set
union, set intersection and set difference for my analysis. These
functions are defined in the header algorithm. However, when I include
this header in my file, I get the following error:
On Thu, 20 Feb 2014, Pritam Gharat wrote:
I am using sets of stl in gcc. I need to perform operations like set
union, set intersection and set difference for my analysis. These functions
are defined in the header algorithm. However, when I include this header in
my file, I get the following
On 20 February 2014 10:02, Patrick Palka patr...@parcs.ath.cx wrote:
On Thu, Feb 20, 2014 at 2:16 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 13 February 2014 20:47, Patrick Palka wrote:
On a related note, would a patch to officially enable
-Wmissing-declarations in the build process
It worked. Thank You :-)
On Thursday 20 February 2014 06:03 PM, Marc Glisse wrote:
On Thu, 20 Feb 2014, Pritam Gharat wrote:
I am using sets of stl in gcc. I need to perform operations like
set union, set intersection and set difference for my analysis. These
functions are defined in the
On Wed, Feb 19, 2014 at 11:26 PM, Renato Golin renato.go...@linaro.org wrote:
On 19 February 2014 23:19, Andrew Pinski pins...@gmail.com wrote:
With the unified assembly format, you should not need those
.arm/.thumb and in fact emitting them can make things even worse.
If only we could get
On 20 February 2014 12:59, Ramana Radhakrishnan
ramana@googlemail.com wrote:
It's not really because GAS supports it, but there exists a large body
of code out there which uses inline assembler with pre-UAL syntax. I'm
not sure people will appreciate a blanket break in one version of the
Hi,
I've uploaded a prebuilt arm cross compiler for Linux x86_64, built on
Debian Jessie, should work fine, crosses fingers :D
https://www.dropbox.com/s/273e1pbez0qgqkp/tinyada-arm-none-eabi-4.9.0-20140122.tbz
Thanks,
Luke.
On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
So lets make this really simple: if you have a consume-cmp-read, is
the ordering of the two reads guaranteed?
Not as far as I know. Also, as far as I know, there is no difference
between consume and relaxed
On Wed, 2014-02-19 at 16:53 -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel trie...@redhat.com wrote:
On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
Can you point to it? Because I can find a draft standard, and it sure
as hell does *not* contain any
On Wed, 2014-02-19 at 20:01 -0800, Paul E. McKenney wrote:
On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds wrote:
On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel trie...@redhat.com wrote:
On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
Can you point to it? Because I
On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel trie...@redhat.com wrote:
So the clarification is basically to the statement that the if
(consume(p)) a version *would* have an ordering guarantee between the
read of p and a, but the consume(p) ? a : b would *not* have
such an ordering
On Wed, 2014-02-19 at 20:43 -0800, Linus Torvalds wrote:
[Paul has already answered many of your questions, and my reply to your
previous email should also answer some.]
If the consumer of an atomic load isn't a pointer chasing operation,
then the consume should be defined to be the same as
On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote:
Well, all the compilers currently convert consume to acquire, so you have
your wish there. Of course, that also means that they generate actual
unneeded memory-barrier instructions, which seems extremely sub-optimal
to me.
GCC
Patrick Palka patr...@parcs.ath.cx writes:
Maybe others will disagree and will think enabling
-Wmissing-declarations would be a useful change, but I don't see the
point.
In my novice opinion, I think the flag helps keep source files tidy
and modular, and their interfaces well-defined. Its
On Thu, Feb 20, 2014 at 09:01:06AM -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
So lets make this really simple: if you have a consume-cmp-read, is
the ordering of the two reads guaranteed?
Not as far as I know.
On Thu, 2014-02-20 at 09:34 -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel trie...@redhat.com wrote:
So the clarification is basically to the statement that the if
(consume(p)) a version *would* have an ordering guarantee between the
read of p and a, but the
On 20 February 2014 15:31, Patrick Palka wrote:
(I counted nearly 100 (non-debug)
functions that could be made static in gcc, and 4 in libstdc++, by the
way.)
Which were the four in libstdc++?
I only see __gslice_on_index and __concat_size_t.
On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 20 February 2014 15:31, Patrick Palka wrote:
(I counted nearly 100 (non-debug)
functions that could be made static in gcc, and 4 in libstdc++, by the
way.)
Which were the four in libstdc++?
I only see
On Thu, Feb 20, 2014 at 06:26:08PM +0100, Torvald Riegel wrote:
xagsmtp2.20140220172700.0...@vmsdvm4.vnet.ibm.com
X-Xagent-Gateway: vmsdvm4.vnet.ibm.com (XAGSMTP2 at VMSDVM4)
On Wed, 2014-02-19 at 20:01 -0800, Paul E. McKenney wrote:
On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds
On 20 February 2014 18:16, Patrick Palka wrote:
On Thu, Feb 20, 2014 at 1:14 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 20 February 2014 15:31, Patrick Palka wrote:
(I counted nearly 100 (non-debug)
functions that could be made static in gcc, and 4 in libstdc++, by the
way.)
On Thu, Feb 20, 2014 at 06:54:06PM +0100, Torvald Riegel wrote:
xagsmtp4.20140220175519.1...@vmsdvm6.vnet.ibm.com
X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP4 at VMSDVM6)
On Thu, 2014-02-20 at 00:30 -0800, Paul E. McKenney wrote:
Well, all the compilers currently convert consume to
On Thu, Feb 20, 2014 at 9:49 AM, Torvald Riegel trie...@redhat.com wrote:
Yes, mo_consume is more tricky than mo_acquire.
However, that has an advantage because you can avoid getting stronger
barriers if you don't need them (ie, you can avoid the auto-update to
acquire you seem to have in
On Thu, Feb 20, 2014 at 09:34:57AM -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel trie...@redhat.com wrote:
So the clarification is basically to the statement that the if
(consume(p)) a version *would* have an ordering guarantee between the
read of p and a,
On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
You really need that consume to be acquire.
So I think we now all agree that that is what the standard is saying.
And I'm saying that that is wrong, that the standard is badly written,
and should be fixed.
On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote:
But yes, the compiler guys would be extremely happy to simply drop
memory_order_consume from the standard, as it is the memory order
that they most love to hate.
Getting them to agree to any sort of peep-hole optimization semantics
On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
You really need that consume to be acquire.
So I think we now all agree that that is what the standard is saying.
Huh?
The standard says that
On Thu, Feb 20, 2014 at 10:32:51AM -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
You really need that consume to be acquire.
So I think we now all agree that that is what the standard is saying.
And I'm saying that
On Thu, Feb 20, 2014 at 07:44:32PM +0100, Torvald Riegel wrote:
xagsmtp3.20140220184514.1...@bldgate.vnet.ibm.com
X-Xagent-Gateway: bldgate.vnet.ibm.com (XAGSMTP3 at BLDGATE)
On Thu, 2014-02-20 at 10:11 -0800, Paul E. McKenney wrote:
But yes, the compiler guys would be extremely happy to
On Thu, Feb 20, 2014 at 10:25 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
While in my *sane* model, where you can consume things even if they
then result in control dependencies, there will still eventually be a
sync instruction on powerpc (because you really need one between the
On Thu, Feb 20, 2014 at 11:02 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Again, the way I'd expect a compiler writer to actually *do* this is
to just default to ac
Oops, pressed send by mistake too early.
I was almost done:
I'd expect a compiler to just default to acquire
On Thu, Feb 20, 2014 at 10:53 AM, Torvald Riegel trie...@redhat.com wrote:
On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
You really need that consume to be acquire.
So I think we now all agree
On Thu, Feb 20, 2014 at 10:56 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
The example gcc breakage was something like this:
i = atomic_load(idx, memory_order_consume);
x = array[0 + i - i];
Then gcc optimized this to:
i = atomic_load(idx,
On 02/15/2014 05:09 AM, Richard Biener wrote:
On Sat, 15 Feb 2014, Jan Hubicka wrote:
The code really seems to be adding only cases of zero sized classes.
zero-size as in with no fields? Then we can't do anything with such
classes and thus we don't need to record component aliases?
Right.
On 02/17/2014 03:55 PM, Jan Hubicka wrote:
I also think we want explicit representation of types known to be local to
compilation
unit - anonymous namespaces in C/C++, types defined within function bodies in C
and
god knows what in Ada/Fortran/Java.
In the C++ front end we set TREE_PUBLIC
On Thu, Feb 20, 2014 at 11:45:29AM -0800, Linus Torvalds wrote:
On Thu, Feb 20, 2014 at 10:56 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
The example gcc breakage was something like this:
i = atomic_load(idx, memory_order_consume);
x = array[0 + i - i];
Snapshot gcc-4.8-20140220 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Feb 20, 2014 at 2:10 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Linus, given that you are calling me out for pushing legalistic and bad
things, syntactic bullshit, and playing little games, I am forced
to conclude that you have never attended any sort of standards-committee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907
--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Thu Feb 20 08:00:48 2014
New Revision: 207935
URL: http://gcc.gnu.org/viewcvs?rev=207935root=gccview=rev
Log:
2014-02-20 Janus Weil ja...@gcc.gnu.org
Backport from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55907
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281
Bug ID: 60281
Summary: Address Sanitizer triggers alignment fault in ARM
machines
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281
--- Comment #1 from linzj manjian2006 at gmail dot com ---
I have summit a patch for this bug,and tested in my Nexus 4.It works fine.Check
gcc-patches at gcc dot gnu dot org for that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60282
Bug ID: 60282
Summary: memory leak - Double from string, _Jv_Balloc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60283
Bug ID: 60283
Summary: Wrong code: decode_omp_directive: implicit_pure not
correctly unset
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60261
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Feb 20 08:43:04 2014
New Revision: 207936
URL: http://gcc.gnu.org/viewcvs?rev=207936root=gccview=rev
Log:
2014-02-20 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42844
David Krauss potswa at mac dot com changed:
What|Removed |Added
CC||potswa at mac dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60285
Bug ID: 60285
Summary: std::listT::insert(position, x) does not accept
const_iterator position
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284
Bug ID: 60284
Summary: Default-initialization without user-provided
constructor allowed
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60285
--- Comment #1 from Petr Kmoch petr.kmoch at gmail dot com ---
Created attachment 32177
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32177action=edit
gcc -v output when building test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60046
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286
Bug ID: 60286
Summary: INQUIRE reports STDOUT as not writable
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Feb 20 09:00:23 2014
New Revision: 207937
URL: http://gcc.gnu.org/viewcvs?rev=207937root=gccview=rev
Log:
2014-02-20 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60287
Bug ID: 60287
Summary: Various issues on -Wformat=
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #14 from Uroš Bizjak ubizjak at gmail dot com ---
I have found where corruption of const_int_rtx array happens.
1. Put breakpoint on gen_rtx_CONST_INT to determine address of
const_int_rtx[24], a.k.a (const_int -40) and put HW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
I'll have a look (unless you want to continue poking).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60285
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60284
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
Bug ID: 60288
Summary: gccgo crashes compiling '*func_ptr(0)'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #16 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jakub Jelinek from comment #15)
I'll have a look (unless you want to continue poking).
According to ChangeLogs, you have much more experience in this part, so I would
be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286
--- Comment #1 from Alexander Vogt a.vogt at fulguritus dot com ---
I just found out that the same holds true for STDERR...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #17 from Uroš Bizjak ubizjak at gmail dot com ---
Somehow we get old_size = 0 in gen_reg_rtx. It is calculated as:
int old_size = crtl-emit.regno_pointer_align_length;
Trivial patch that prevents this situation and fixes the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60287
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #13 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 19 Feb 2014, steven at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
Steven Bosscher steven at gcc dot gnu.org changed:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60286
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #18 from Uroš Bizjak ubizjak at gmail dot com ---
And finally, it looks that expand_vector_operations doesn't call init_emit ().
Backtrace:
Breakpoint 1, gen_reg_rtx (mode=V4SImode) at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Component|middle-end |target
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, from quick skim of relevant routines that do gen_reg_rtx, I see:
gen_reg_rtx called only after if (d-testing_p) return true;, thus ok:
expand_vec_perm_blend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #21 from Uroš Bizjak ubizjak at gmail dot com ---
--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 207935)
+++ config/i386/i386.c (working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60280
--- Comment #3 from bin.cheng amker.cheng at gmail dot com ---
I think 4_8 is ok for this case. At least it doesn't have
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01530.html committed if I was
right.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
Bug ID: 60289
Summary: allocating class(*) pointer as character gives
type-spec requires the same character-length parameter
Product: gcc
Version: 4.9.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60288
--- Comment #1 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
So it looks like gccgo reads the expression as
(*pg)(0)
I meant
- (*(g))(0)
while golang reads it as
*(pg(0))
- *((g(0)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #21)
--- config/i386/i386.c (revision 207935)
+++ config/i386/i386.c (working copy)
@@ -40666,9 +40666,9 @@ ix86_vectorize_vec_perm_const_ok
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #23 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jakub Jelinek from comment #22)
IMHO that is way too expensive.
Agreed.
Anyway, it looks you got this problem under control ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60236
--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
This patch tries to solve the problem in a more general way.
I wonder if one of you could try this patch on PowerPC?
Sorry for the late answer, but my G5 was buzzy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Target||x86
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32180
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32180action=edit
gcc48-pr57896.patch
So like this (4.8 version, untested)? Uros, can you please
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60268
--- Comment #4 from Andrey Belevantsev abel at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
I forgot the single block regions case, so the nr_regions_initial init should
be moved to the bottom of sched_rgn_init.
The check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
--- Comment #2 from janus at gcc dot gnu.org ---
The error can easily be silenced with this patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 207896)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
extern void abort (void);
static void
foo (short *out, const short *lp, const short *hp, unsigned samples)
{
int x, target;
for (x = 0, target = 0; x (int)samples; x += 2,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 32181
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32181action=edit
gcc49-pr57896.patch
Corresponding 4.9 version, which is somewhat different due to my?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60287
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||chengniansun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
--- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr ---
What should we do about this test? Having it fail everywhere a current
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896
--- Comment #27 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jakub Jelinek from comment #25)
Created attachment 32180 [details]
gcc48-pr57896.patch
So like this (4.8 version, untested)? Uros, can you please double-check it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
And with less convoluted vectorized code but still broken (avoids integer
promotions):
extern void abort (void);
static void
foo (int *out, const int *lp, const int *hp, unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60276
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
But you can clearly see that this isn't valid vectorization because of the
read-after-write dependence of out[x].
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
Bug ID: 60290
Summary: 32-bit g++.dg/cilk-plus/CK/catch_exc.cc FAILs on
Solaris/x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60290
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
1 - 100 of 278 matches
Mail list logo
