https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
--- Comment #10 from Kan Liu ---
(In reply to Jonathan Wakely from comment #9)
> I can see one good reason to implement those operators as templates: it
> allows us to check if the literal value overflows the duration::rep type,
> which is requir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
Peter Bergner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
--- Comment #3 from Peter Bergner ---
Author: bergner
Date: Fri May 16 03:46:23 2014
New Revision: 210488
URL: http://gcc.gnu.org/viewcvs?rev=210488&root=gcc&view=rev
Log:
Backport from mainline
2014-05-15 Peter Bergner
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
--- Comment #2 from Peter Bergner ---
Author: bergner
Date: Fri May 16 03:44:19 2014
New Revision: 210487
URL: http://gcc.gnu.org/viewcvs?rev=210487&root=gcc&view=rev
Log:
PR target/61193
* config/rs6000/htmxlintrin.h (_HTM_TBEGIN_STARTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
--- Comment #1 from Peter Bergner ---
Author: bergner
Date: Fri May 16 03:43:12 2014
New Revision: 210486
URL: http://gcc.gnu.org/viewcvs?rev=210486&root=gcc&view=rev
Log:
PR target/61193
* config/rs6000/htmxlintrin.h (_HTM_TBEGIN_STARTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198
Bug ID: 61198
Summary: Crash when selecting specializations through aliases.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198
--- Comment #1 from Chris ---
Created attachment 32802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32802&action=edit
A sample of offending code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #24 from Leon Timmermans ---
(In reply to Jonathan Wakely from comment #18)
> (In reply to Hideaki Kimura from comment #17)
> > Oh, is it the design of promise::get_future/set_value?
> > I so far don't see any reference that clarifies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #23 from Jonathan Wakely ---
(In reply to Hideaki Kimura from comment #22)
> Ah, you are right, set_value() might have context switch after signaling
> before exitting.
Or even before signalling (a waiting thread could check if the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #22 from Hideaki Kimura ---
Ah, you are right, set_value() might have context switch after signaling before
exitting.
... ah, and that's why what Thomas initially posted could also see a hang.
{ // copy-paste again to refresh memory,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #21 from Jonathan Wakely ---
Created attachment 32801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32801&action=edit
increase reference count on shared state during set_value / set_exception
This patch ensures the shared stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> The easiest fix is to call get_future() before passing the task into a new
> thread, and store it in a std::vector>
Actually this only hides the error (by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #18 from Jonathan Wakely ---
(In reply to Hideaki Kimura from comment #17)
> Oh, is it the design of promise::get_future/set_value?
> I so far don't see any reference that clarifies either way (most document
> just mentions about diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #17 from Hideaki Kimura ---
(In reply to Jonathan Wakely from comment #16)
> promise::get_future() is a non-const function that modifies the promise
> object, therefore it must not be called while any other object is accessing
> the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #16 from Jonathan Wakely ---
(In reply to Hideaki Kimura from comment #14)
> void run_task(DummyTask* task) {
> std::this_thread::sleep_for(std::chrono::milliseconds(100));
> task->pr.set_value();
> }
>
> void wait_for_task(D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #15 from Jonathan Wakely ---
(In reply to Hideaki Kimura from comment #14)
> I'm not sure if this helps, but could you try the following code snippet?
Very helpful, thanks
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140515 (experimental) [trunk revision 210458] (GCC)
$
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.9.0 -O3 small.c; a.out
$
$ gcc-trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61103
--- Comment #1 from synxis at gmx dot fr ---
I did some testing and this bug is present on:
gcc 4.7.2
gcc 4.8.1
gcc 4.9.0
at least. Is it possible to have some feedback on it ? Thanks in advance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #12 from Jeffrey A. Law ---
I think the cascading problem can be pretty easily addressed.
The problematical sequence of insns would look something like this:
A (set (r0) (expression))
B (set (r1) (extend (r0))
C (set (r0) (extend (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
--- Comment #9 from Jonathan Wakely ---
I can see one good reason to implement those operators as templates: it allows
us to check if the literal value overflows the duration::rep type, which is
required by the standard but impossible to implemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61151
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61196
Bug ID: 61196
Summary: Optimizer does not handle memory accesses with two
pointers to same location correctly
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #7 from Tom Tromey ---
(In reply to Manuel López-Ibáñez from comment #6)
> (In reply to Tom Tromey from comment #5)
> > The new situation is much worse for me as it prevents automated
> > rewriting...
>
> What automated rewriting?
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028
--- Comment #3 from Dominique d'Humieres ---
> I remember some posts about the order of -gx -gy, but cannot find it right
> now.
It is pr61013, fixed by r210442 on trunk and r210456 for 4.9.1. AFAICT the
warnings are gone at r210475.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #5 from Tom Tromey ---
I tried this today with a recent-ish gcc trunk build, and
there's been a regression.
Now:
barimba. gcc --syntax-only r.c
r.c: In function ‘docall’:
r.c:7:10: warning: passing argument 3 of ‘callf’ from incompa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #5 from vincenzo Innocente ---
of course if you can make
z[i] = ( (x[i]>0) & (w[i]<0)) ? z[i] : y[i];
to vectorize would be even better!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085
--- Comment #6 from Martin Jambor ---
Author: jamborm
Date: Thu May 15 15:10:58 2014
New Revision: 210478
URL: http://gcc.gnu.org/viewcvs?rev=210478&root=gcc&view=rev
Log:
2014-05-15 Martin Jambor
PR ipa/61085
* ipa-prop.c (update_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #4 from Richard Biener ---
Actually the vectorizer punts on the comparisons itself. The pattern
recognizer handles some of them as
patt_10 = _4 > 0.0 ? 1 : 0;
but not those feeding the BIT expressions which would need to be widen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085
--- Comment #5 from Martin Jambor ---
Author: jamborm
Date: Thu May 15 15:04:18 2014
New Revision: 210477
URL: http://gcc.gnu.org/viewcvs?rev=210477&root=gcc&view=rev
Log:
2014-05-15 Martin Jambor
PR ipa/61085
* ipa-prop.c (update_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090
--- Comment #4 from Martin Jambor ---
Author: jamborm
Date: Thu May 15 14:54:29 2014
New Revision: 210476
URL: http://gcc.gnu.org/viewcvs?rev=210476&root=gcc&view=rev
Log:
2014-05-15 Martin Jambor
PR tree-optimization/61090
* tree-sr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Martin Jamb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Martin Jamb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #2 from vincenzo Innocente ---
new test code
cat cond0.cc
float x[1024];
float y[1024];
float z[1024];
float w[1024];
int k[1024];
void barX() {
for (int i=0; i<1024; ++i) {
k[i] = (x[i]>0) & (w[i] 0.0 ? patt_25 : 0;
Vectori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61195
--- Comment #1 from chrbr at gcc dot gnu.org ---
movsf_ie forces the fp_mode attr for all constraints. Testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #1 from vincenzo Innocente ---
what I find quite absurd is that
void barX() {
for (int i=0; i<1024; ++i) {
k[i] = x[i]>0;
k[i] &= w[i]0;
k[i] &= w[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61195
Bug ID: 61195
Summary: single precision fmov does not need to switch mode
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326
--- Comment #4 from Jonathan Wakely ---
Fixed on trunk so far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Thu May 15 12:31:05 2014
New Revision: 210473
URL: http://gcc.gnu.org/viewcvs?rev=210473&root=gcc&view=rev
Log:
PR libstdc++/60326
* include/std/type_traits (__make_unsigned, __m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #13 from Ville Voutilainen ---
(In reply to Paolo Carlini from comment #12)
Ah, indeed, comment 2 has an explicit diagnostic as well. The patch
looks reasonable (to my taste the condition doesn't, but that's another
matter), so I rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #12 from Paolo Carlini ---
It is in Comment #2, though. In fact, I *only* noticed that one when I asked ;)
Anyway, I was looking a bit into the other bug and interestingly a rather rough
draft I have got appears to fix all these issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60897
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60897
--- Comment #5 from Martin Jambor ---
Author: jamborm
Date: Thu May 15 12:16:33 2014
New Revision: 210472
URL: http://gcc.gnu.org/viewcvs?rev=210472&root=gcc&view=rev
Log:
2014-05-15 Martin Jambor
PR ipa/60897
* ipa-prop.c (ipa_modif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
Bug ID: 61194
Summary: vectorization failed with "bit-precision arithmetic
not supported" even if conversion to int is requested
Product: gcc
Version: 4.9.0
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
Peter Bergner changed:
What|Removed |Added
Target||powerpc*-linux s390-linux
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193
Bug ID: 61193
Summary: ABI incompatibility between POWER and Z HTM builtins
and intrinsics
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61064
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
--- Comment #11 from Ville Voutilainen ---
(In reply to Paolo Carlini from comment #10)
Looks somewhat similar, but not identical. In this particular
bug it doesn't seem to be a case of explicitness being the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981
--- Comment #11 from Tony Theodore ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #22 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #21)
> -Wunused-parameter
> Contrary to gcc's meaning of -Wunused-parameter, gfortran's implementation
> of this option does not warn about unused dummy a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #21 from rguenther at suse dot de ---
On Thu, 15 May 2014, thomas.preudhomme at arm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
>
> --- Comment #20 from Thomas Preud'homme ---
> (In reply to rguent...@suse.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #21 from Dominique d'Humieres ---
> > -Wunused-parameter is enabled by -Wall.
>
> No, according to the manual it isn't.
The gfortran manual reads:
-Wunused-parameter
Contrary to gcc's meaning of -Wunused-parameter, gfortran's implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
--- Comment #6 from Jakub Jelinek ---
Fixed for 4.9.1+ so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Thu May 15 10:08:12 2014
New Revision: 210469
URL: http://gcc.gnu.org/viewcvs?rev=210469&root=gcc&view=rev
Log:
PR tree-optimization/61158
* fold-const.c (fold_binary_loc): If X i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61097
Rainer Orth changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61097
--- Comment #3 from Rainer Orth ---
Author: ro
Date: Thu May 15 10:02:04 2014
New Revision: 210468
URL: http://gcc.gnu.org/viewcvs?rev=210468&root=gcc&view=rev
Log:
Don't build libgcc-unwind.map with --disable-shared (PR libgcc/61097)
Backp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Thu May 15 10:01:11 2014
New Revision: 210467
URL: http://gcc.gnu.org/viewcvs?rev=210467&root=gcc&view=rev
Log:
PR tree-optimization/61158
* fold-const.c (fold_binary_loc): If X i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981
Rainer Orth changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981
--- Comment #9 from Rainer Orth ---
Author: ro
Date: Thu May 15 09:56:22 2014
New Revision: 210466
URL: http://gcc.gnu.org/viewcvs?rev=210466&root=gcc&view=rev
Log:
Check for -static-libgcc before use (PR lto/60981)
PR lto/60981
* confi
-newlib --verbose --enable-threads --enable-languages=c,c++
--disable-nls --prefix=/opt/rtems-4.11 --enable-version-specific-runtime-libs
--with-system-zlib --disable-libstdcxx-pch --disable-win32-registry
--without-included-gettext
Thread model: rtems
gcc version 4.9.1 20140515 (prerelease) (GCC)
CO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981
--- Comment #8 from Rainer Orth ---
Author: ro
Date: Thu May 15 09:52:37 2014
New Revision: 210465
URL: http://gcc.gnu.org/viewcvs?rev=210465&root=gcc&view=rev
Log:
Check for -static-libgcc before use (PR lto/60981)
PR lto/60981
* confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #20 from Thomas Preud'homme ---
(In reply to rguent...@suse.de from comment #19)
> On Thu, 15 May 2014, thomas.preudhomme at arm dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
> >
> > --- Comment #18 from Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #19 from rguenther at suse dot de ---
On Thu, 15 May 2014, thomas.preudhomme at arm dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
>
> --- Comment #18 from Thomas Preud'homme ---
> (In reply to Richard Biener f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61191
Bug ID: 61191
Summary: cilkplus ICE on syntax error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #18 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #17)
>
> Citing myself:
>
> On the GIMPLE level before expansion we have
>
> +40 = Arr_2_Par_Ref_22(D) + (_41 + pretmp_20);
>
> _51 = Arr_2_Par_Ref_22(D) +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61084
--- Comment #11 from Eric Botcazou ---
> I haven't yet had an opportunity to look into the two gnat.dg testcases
> that still time out.
I'll look into these ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61084
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
Thanks for the fix. The second part, fixing the pdist failures, is
still missing, though.
I haven't yet had an opportunity to look into the two gnat.dg testcases
that still time out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #17 from Richard Biener ---
(In reply to Thomas Preud'homme from comment #16)
> Hi Richard,
>
> could you expand on what you said in comment #13? I don't see how reassoc
> could help cse here. From what I understood, reassoc tries to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61175
--- Comment #1 from vincenzo Innocente ---
adding
#pragma GCC ivdep
before the loop makes no difference
81 matches
Mail list logo