[Bug tree-optimization/61175] failing vectorization in case of "complex access pattern"

[vincenzo.innocente at cern dot ch]

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

[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239

[rguenth at gcc dot gnu.org]

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 group per
> rank. In our case, we have (view of the source with loop unrolling):
> 
> Arr_2_Par_Ref [Int_Loc] [Int_Loc] = Int_Loc;
> /* some stmts */
> Arr_2_Par_Ref [Int_Loc+10] [Int_Loc] = Arr_1_Par_Ref [Int_Loc];
> 
> If I'm not mistaken, in the first case you'd have:
> 
> Int_Loc * 4
> Int_Loc * 100
> Arr_2_Par_Ref
> 
> that would be added together with several statements. However in the second
> case you'd have:
> 
> Int_Loc * 4
> Int_Loc * 100
> 1000
> Arr_2_Par_Ref
> 
> that would be added together with several statements. I don't see how could
> 1000 being added first or last, it seems to me that it's always going to be
> in an intermediate statement and thus not all redanduncy would be eliminated
> by CSE.
> 
> Please let me know if my reasonning is flawed so that I can progress toward
> a solution.

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) + (_41 + (pretmp_20 + 1000));

so if _51 were Arr_2_Par_Ref_22(D) + ((_41 + pretmp_20) + 1000);

then _41 + pretmp_20 would be fully redundant with the expression needed
by _40.

Note that IIRC one issue with TER is that it is no longer happening as
there are dead stmts around that confuse its has_single_use logic.  Thus
placing a dce pass right before expand would fix that and might be a good
idea anyway (see comment #3).  Implementing a "proper" poor-mans SSA-based
DCE would be a good way out (out-of-SSA already has one to remove dead
PHIs).

[Bug bootstrap/61084] [4.10 regression] wide-int merge broke Solaris/SPARC bootstrap

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

Thanks.
Rainer

[Bug bootstrap/61084] [4.10 regression] wide-int merge broke Solaris/SPARC bootstrap

[ebotcazou at gcc dot gnu.org]

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.

[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239

[thomas.preudhomme at arm dot com]

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) + (_41 + (pretmp_20 + 1000));
> 
> so if _51 were Arr_2_Par_Ref_22(D) + ((_41 + pretmp_20) + 1000);
> 
> then _41 + pretmp_20 would be fully redundant with the expression needed
> by _40.

Yes I saw that but I was wondering why would reassoc try this association
rather than another since the header of the file doesn't mention any special
treatment of explicit integer constants.

Besides, wouldn't it still misses that fact that _51 = _40 + 1000?

> 
> Note that IIRC one issue with TER is that it is no longer happening as
> there are dead stmts around that confuse its has_single_use logic.  Thus
> placing a dce pass right before expand would fix that and might be a good
> idea anyway (see comment #3).  Implementing a "proper" poor-mans SSA-based
> DCE would be a good way out (out-of-SSA already has one to remove dead
> PHIs).

Ok

[Bug c++/58753] Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58753

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #10 from Paolo Carlini  ---
Ville, I believe PR58930 is essentially the same issue with a slightly smaller
testcase. What do you think?

[Bug c/61191] New: cilkplus ICE on syntax error

[jtaylor.debian at googlemail dot com]

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: unassigned at gcc dot gnu.org
  Reporter: jtaylor.debian at googlemail dot com

following file with a syntax error (wrong braces at end of line) results in an
ICE with gcc-4.9.0 and recent SVN head (14. may 2014):

double f(double * A, double * B)
{
return  __sec_reduce_add((B[0:500])(;
}


$ gcc-4.10 -v
Using built-in specs.
COLLECT_GCC=/scratch/jtaylor/gcc/local-trunk/bin//gcc
COLLECT_LTO_WRAPPER=/scratch/jtaylor/gcc/local-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /media/jtaylor/external1/buildacc/gcc-trunk/configure
--disable-werror --enable-languages=c,c++,fortran --enable-tls
--prefix=/scratch/jtaylor/gcc/local-trunk --with-gmp=/usr --with-mpfr=/usr
--with-mpc=/usr --with-cloog=/usr --with-ppl=/usr --with-isl=/usr
--disable-shared --disable-bootstrap
Thread model: posix
gcc version 4.10.0 20140514 (experimental) (GCC) 

$ gcc-4.10 -fcilkplus test.c -c
test.c: In function ‘f’:
test.c:3:40: error: expected expression before ‘;’ token
 return  __sec_reduce_add((B[0:500])(;
^
test.c:3:29: error: called object is not a function or function pointer
 return  __sec_reduce_add((B[0:500])(;
 ^
test.c:4:1: error: expected ‘)’ before ‘}’ token
 }
 ^
test.c:4:1: error: expected ‘;’ before ‘}’ token
gcc: internal compiler error: Segmentation fault (program cc1)
0x40c663 execute
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:2848
0x40c969 do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:4652
0x40f420 process_brace_body
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5935
0x40f420 handle_braces
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5849
0x40d160 do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5306
0x40f420 process_brace_body
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5935
0x40f420 handle_braces
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5849
0x40d160 do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5306
0x40d6ab do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5421
0x40f420 process_brace_body
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5935
0x40f420 handle_braces
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5849
0x40d160 do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5306
0x40f420 process_brace_body
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5935
0x40f420 handle_braces
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5849
0x40d160 do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5306
0x40f420 process_brace_body
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5935
0x40f420 handle_braces
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5849
0x40d160 do_spec_1
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5306
0x40f420 process_brace_body
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5935
0x40f420 handle_braces
/media/jtaylor/external1/buildacc/gcc-trunk/gcc/gcc.c:5849

[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239

[rguenther at suse dot de]

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 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) + (_41 + (pretmp_20 + 1000));
> > 
> > so if _51 were Arr_2_Par_Ref_22(D) + ((_41 + pretmp_20) + 1000);
> > 
> > then _41 + pretmp_20 would be fully redundant with the expression needed
> > by _40.
> 
> Yes I saw that but I was wondering why would reassoc try this association
> rather than another since the header of the file doesn't mention any special
> treatment of explicit integer constants.
> 
> Besides, wouldn't it still misses that fact that _51 = _40 + 1000?

Yes.  But reassoc doesn't associate across POINTER_PLUS_EXPRs.

RTL CSE could catch it, but for it the association would have to
be the same for both.  If we start from the proposed form
then at RTL expansion time we could associate
pointer + (X + CST) to (pointer + X) + CST.

Feels all somewhat hacky, of course (and relies on TER).  There
may be cases where doing the opposite is better (for example
if you have ptr1 + (X + 1000) and ptr2 + (X + 1000)).  Association
to make CSE possible is always hard if CSE itself cannot associate
to maximize the number of CSE opportunities.  So at the moment
any choice is just canonicalization.

> > Note that IIRC one issue with TER is that it is no longer happening as
> > there are dead stmts around that confuse its has_single_use logic.  Thus
> > placing a dce pass right before expand would fix that and might be a good
> > idea anyway (see comment #3).  Implementing a "proper" poor-mans SSA-based
> > DCE would be a good way out (out-of-SSA already has one to remove dead
> > PHIs).
> 
> Ok

[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239

[thomas.preudhomme at arm dot com]

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 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) + (_41 + (pretmp_20 + 1000));
> > > 
> > > so if _51 were Arr_2_Par_Ref_22(D) + ((_41 + pretmp_20) + 1000);
> > > 
> > > then _41 + pretmp_20 would be fully redundant with the expression needed
> > > by _40.
> > 
> > Yes I saw that but I was wondering why would reassoc try this association
> > rather than another since the header of the file doesn't mention any special
> > treatment of explicit integer constants.
> > 
> > Besides, wouldn't it still misses that fact that _51 = _40 + 1000?
> 
> Yes.  But reassoc doesn't associate across POINTER_PLUS_EXPRs.

Is there a reason for that?

> 
> RTL CSE could catch it, but for it the association would have to
> be the same for both.  If we start from the proposed form
> then at RTL expansion time we could associate
> pointer + (X + CST) to (pointer + X) + CST.

Right.

> 
> Feels all somewhat hacky, of course (and relies on TER).  There
> may be cases where doing the opposite is better (for example
> if you have ptr1 + (X + 1000) and ptr2 + (X + 1000)).  Association
> to make CSE possible is always hard if CSE itself cannot associate
> to maximize the number of CSE opportunities.  So at the moment
> any choice is just canonicalization.

Exactly my thought. I'm not sure if that's what you have in mind when you write
association for CSE but I was thinking about a scheme that ressemble what
tree_to_aff_combination_expand does and organize all expanded expression to
compare them easily (read efficiently). With such a capability it would then
not be necessary to do the first replacement with forprop+reassoc+dom as
everything could be done in CSE.

[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)

[ro at gcc dot gnu.org]

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
* configure.ac: Check for -static-libgcc.
* configure: Regenerate.

Modified:
trunk/lto-plugin/ChangeLog
trunk/lto-plugin/configure   (contents, props changed)
trunk/lto-plugin/configure.ac

[Bug lto/61192] New: Conflict between register and function name for lto on sparc

[cederman at gaisler dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192

Bug ID: 61192
   Summary: Conflict between register and function name for lto on
sparc
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cederman at gaisler dot com

Created attachment 32799
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32799&action=edit
Preprocessed files

This line in the attached preprocessed file:

register struct Per_CPU_Control *_SPARC_Per_CPU_current __asm__( "g6" );

seems to conflict with this line:

int g6() {}

when using lto on sparc. If I change the function name I get no error. If I
change both the register and the function name to g5 instead I get the same
error.

$ sparc-rtems-gcc -v  bug.i  -flto -flto-partition=none -O2

Using built-in specs.
COLLECT_GCC=sparc-rtems-gcc
COLLECT_LTO_WRAPPER=/opt/rtems-4.11/libexec/gcc/sparc-rtems/4.9.1/lto-wrapper
Target: sparc-rtems
Configured with: ../../gcc/configure --target=sparc-rtems --with-gnu-as
--with-gnu-ld --with-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) 
COLLECT_GCC_OPTIONS='-v' '-flto' '-flto-partition=none' '-O2' '-mcpu=v7'
 /opt/rtems-4.11/libexec/gcc/sparc-rtems/4.9.1/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.i -mcpu=v7 -auxbase bug -O2 -version -flto -flto-partition=none
-o /tmp/cczGxKWE.s
GNU C (GCC) version 4.9.1 20140515 (prerelease) (sparc-rtems)
compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.1, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.9.1 20140515 (prerelease) (sparc-rtems)
compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.1, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 86c088340ea65899e71f0200a3b56ac7
In file included from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/cpuatomic.h:12:0,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/atomic.h:21,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/smplock.h:27,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/percpu.h:28,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/system.h:23,
 from /opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems.h:29,
 from bug.c:1:
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/cpustdatomic.h: In
function '_CPU_atomic_Store_ptr':
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/cpustdatomic.h:179:117:
warning: initialization makes integer from pointer without a cast
   atomic_store_explicit( object, pointer, (memory_order) order );
   
 ^
In file included from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/cpuatomic.h:12:0,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/atomic.h:21,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/smplock.h:27,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/percpu.h:28,
 from
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/system.h:23,
 from /opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems.h:29,
 from bug.c:1:
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/cpustdatomic.h: In
function '_CPU_atomic_Compare_exchange_ptr':
/opt/rtems-4.11/sparc-rtems/leon3/lib/include/rtems/score/cpustdatomic.h:412:157:
warning: initialization makes integer from pointer without a cast
   return atomic_compare_exchange_strong_explicit( object, old_pointer,
   
 ^
COLLECT_GCC_OPTIONS='-v' '-flto' '-flto-partition=none' '-O2' '-mcpu=v7'
 /opt/rtems-4.11/lib/gcc/sparc-rtems/4.9.1/../../../../sparc-rtems/bin/as -v -s
-o /tmp/ccurbDPh.o /tmp/cczGxKWE.s
GNU assembler version 2.23.52 (sparc-rtems) using BFD version (GNU Binutils)
2.23.52.20130918
COMPILER_PATH=/opt/rtems-4.11/libexec/gcc/sparc-rtems/4.9.1/:/opt/rtems-4.11/libexec/gcc/sparc-rtems/4.9.1/:/opt/rtems-4.11/libexec/gcc/sparc-rtems/:/opt/rtems-4.11/lib/gcc/sparc-rtems/4.9.1/:/opt/rtems-4.11/lib/gcc/sparc-r

[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)

[ro at gcc dot gnu.org]

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
* configure.ac: Check for -static-libgcc.
* configure: Regenerate.

Modified:
branches/gcc-4_9-branch/lto-plugin/ChangeLog
branches/gcc-4_9-branch/lto-plugin/configure   (contents, props changed)
branches/gcc-4_9-branch/lto-plugin/configure.ac

[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981

Rainer Orth  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Rainer Orth  ---
Fixed for 4.9.1, 4.10.0.

[Bug middle-end/61158] negative shift at fold-const.c:12095

[jakub at gcc dot gnu.org]

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 is zero-extended and
shiftc >= prec, make sure zerobits is all ones instead of
invoking undefined behavior.

* gcc.dg/pr61158.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr61158.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug libgcc/61097] Solaris linker change broke --disabled-shared support

[ro at gcc dot gnu.org]

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)

Backport from mainline
2014-05-08  Rainer Orth  

PR libgcc/61097
* config/t-slibgcc-sld: Only build and install libgcc-unwind.map
if --enable-shared.

Modified:
branches/gcc-4_9-branch/libgcc/ChangeLog
branches/gcc-4_9-branch/libgcc/config/t-slibgcc-sld

[Bug libgcc/61097] Solaris linker change broke --disabled-shared support

[ro 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|--- |FIXED

--- Comment #4 from Rainer Orth  ---
Backport applied to 4.9 branch, too.

[Bug lto/61192] Conflict between register and function name for lto on sparc

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
This looks like a symtab issue to me.  Honza?

[Bug middle-end/61158] negative shift at fold-const.c:12095

[jakub at gcc dot gnu.org]

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 is zero-extended and
shiftc >= prec, make sure zerobits is all ones instead of
invoking undefined behavior.

* gcc.dg/pr61158.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr61158.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/fold-const.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/61158] negative shift at fold-const.c:12095

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158

--- Comment #6 from Jakub Jelinek  ---
Fixed for 4.9.1+ so far.

[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra

[dominiq at lps dot ens.fr]

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 implementation of
this option does not warn about unused dummy arguments (see
-Wunused-dummy-argument), but about unused PARAMETER values. -Wunused-parameter
is not included in -Wall but is implied by -Wall -Wextra. 

This should probably be changed if -Wunused-parameter is implied by -Wextra.

Note that if -Wextra can be used alone without implying -Wall, it is yet
another poor choice for the -W naming (starting with -Wall which is not all
warnings at all).

[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239

[rguenther at suse dot de]

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.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 Thomas Preud'homme  > > com> ---
> > > (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) + (_41 + (pretmp_20 + 1000));
> > > > 
> > > > so if _51 were Arr_2_Par_Ref_22(D) + ((_41 + pretmp_20) + 1000);
> > > > 
> > > > then _41 + pretmp_20 would be fully redundant with the expression needed
> > > > by _40.
> > > 
> > > Yes I saw that but I was wondering why would reassoc try this association
> > > rather than another since the header of the file doesn't mention any 
> > > special
> > > treatment of explicit integer constants.
> > > 
> > > Besides, wouldn't it still misses that fact that _51 = _40 + 1000?
> > 
> > Yes.  But reassoc doesn't associate across POINTER_PLUS_EXPRs.
> 
> Is there a reason for that?

Yes.  It's not easy and it involves undefined overflow (reassoc
doesn't associate signed arithmetic either)

> > 
> > RTL CSE could catch it, but for it the association would have to
> > be the same for both.  If we start from the proposed form
> > then at RTL expansion time we could associate
> > pointer + (X + CST) to (pointer + X) + CST.
> 
> Right.
> 
> > 
> > Feels all somewhat hacky, of course (and relies on TER).  There
> > may be cases where doing the opposite is better (for example
> > if you have ptr1 + (X + 1000) and ptr2 + (X + 1000)).  Association
> > to make CSE possible is always hard if CSE itself cannot associate
> > to maximize the number of CSE opportunities.  So at the moment
> > any choice is just canonicalization.
> 
> Exactly my thought. I'm not sure if that's what you have in mind when you 
> write
> association for CSE but I was thinking about a scheme that ressemble what
> tree_to_aff_combination_expand does and organize all expanded expression to
> compare them easily (read efficiently). With such a capability it would then
> not be necessary to do the first replacement with forprop+reassoc+dom as
> everything could be done in CSE.

Yeah, but that's not how CSE on GIMPLE or RTL works right now ;)
(patches welcome?)  I suppose teaching reassoc to look for CSE
opportunities may be easier (needs separating analysis and transform
stages for the whole function).

Richard.

[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra

[manu at gcc dot gnu.org]

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 arguments (see
> -Wunused-dummy-argument), but about unused PARAMETER values.
> -Wunused-parameter is not included in -Wall but is implied by -Wall -Wextra. 
> 
> This should probably be changed if -Wunused-parameter is implied by -Wextra.

What is that gfortran wants? 

1. -Wunused-parameter is enabled just by -Wextra. This needs the patches above
plus update the manual. This means that -Wextra -Wno-unused, will keep giving
-Wunused-parameter warnings.

2. Follow all the other FEs, that is, -Wunused-parameter is enabled by the
combination of -Wunused and -Wextra. This needs just the patch in comment #10
plus change -Wall to -Wunused in the manual (the current text is correct, but
the actual reason is that -Wall implies -Wunused, so -Wall -Wextra => -Wunused
-Wextra => -Wunused-parameter).

[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)

[tony.theodore at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981

--- Comment #11 from Tony Theodore  ---
Thanks!

[Bug c++/58753] Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template

[ville.voutilainen at gmail dot com]

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.

[Bug target/61064] ARM G++ compiler mis-optimizes safe Abs function

[ramana at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61064

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-05-15
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
What's the version, command line options used so that someone can even begin to
reproduce the problem. 

Please follow. https://gcc.gnu.org/bugs/#report for information needed in a bug
report and how to report a problem with the compiler.

[Bug target/61193] New: ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner 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
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org

An ABI incompatibility between POWER and Z HTM builtins and intrinsics has been
found.  The incompatibility is on mainline, 4.9 and 4.8.  We're still waiting
to hear what the XL team has implemented for their return status.  Does the XL
on POWER and Z match the POWER or Z sematics?  Does XL on POWER match GCC on
POWER and XL on Z match GCC on Z?  We're tracking that answer down now.  The
intent was that common code on all platforms and compilers would have the same
ABI.

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193

Peter Bergner  changed:

   What|Removed |Added

 CC||dje at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||krebbel at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.8.3

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc*-linux s390-linux
   Priority|P3  |P1

[Bug tree-optimization/61194] New: vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[vincenzo.innocente at cern dot ch]

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: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch

z[i] = ( (x[i]>0) & (w[i]<0)) ? z[i] : y[i];
produces

bit-precision arithmetic not supported.
note: not vectorized: relevant stmt not supported: _6 = _5 > 0.0;

while integer bitwise operators are vectorized at will
 z[i] = ( k[i] & j[i] ) ? z[i] : y[i];

I tried to force conversion to int in many ways (see below) such as 
z[i] = ( int(x[i]>0) & int(w[i]<0)) ? z[i] : y[i];
succeeding only with the quite expensive
z[i] = (2==(int(x[i]>0) + int(w[i]<0))) ? z[i] : y[i];

is there a way to force gcc to use integer w/o using arithmetic operators?

c++ -Ofast -Wall -fno-tree-slp-vectorize -ftree-loop-if-convert-stores -S
cond.cc -msse4.2 -fopt-info-vec -fno-tree-slp-vectorize  -fopenmp
cat cond.cc
float x[1024];
float y[1024];
float z[1024];
float w[1024];

int k[1024];
int j[1024];


void bar() {
  for (int i=0; i<1024; ++i)
z[i] = ( (x[i]>0) & (w[i]<0)) ? z[i] : y[i];
}


void barMP() {
#pragma omp simd
  for (int i=0; i<1024; ++i)
z[i] = ( int(x[i]>0) & int(w[i]<0)) ? z[i] : y[i];
}


void barInt() {
  for (int i=0; i<1024; ++i)
z[i] = ( int(x[i]>0) & int(w[i]<0)) ? z[i] : y[i];
}

void barInt0() {
  for (int i=0; i<1024; ++i)
z[i] = ( (0+int(x[i]>0)) & (0+int(w[i]<0)) ) ? z[i] : y[i];
}


void barPlus() {
  for (int i=0; i<1024; ++i)
z[i] = (2==(int(x[i]>0) + int(w[i]<0))) ? z[i] : y[i];
}


void foo() {
  for (int i=0; i<1024; ++i)
z[i] = ( k[i] & j[i] ) ? z[i] : y[i];
}


void foo2() {
  for (int i=0; i<1024; ++i) {
k[i] = x[i]>0; j[i] = w[i]<0;
  }
}

void bar2() {
  for (int i=0; i<1024; ++i) {
k[i] = x[i]>0; j[i] = w[i]<0;
z[i] = ( k[i] & j[i]) ? z[i] : y[i];
 }
}

[Bug gcov-profile/60897] Mangled function name in warning during -fprofile-use phase of Firefox build

[jamborm at gcc dot gnu.org]

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_modify_formal_parameters): Reset DECL_LANG_SPECIFIC.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ipa-prop.c

[Bug gcov-profile/60897] Mangled function name in warning during -fprofile-use phase of Firefox build

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60897

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Martin Jambor  ---
Fixed, at least as far as IPA-SRA clones are concerned.

[Bug c++/58753] Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template

[paolo.carlini at oracle dot com]

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 issues at once without causing
regressions:

Index: init.c
===
--- init.c  (revision 210459)
+++ init.c  (working copy)
@@ -644,7 +644,8 @@
|| (TREE_CODE (init) == TREE_LIST
&& DIRECT_LIST_INIT_P (TREE_VALUE (init
   && (CP_AGGREGATE_TYPE_P (type)
-  || is_std_init_list (type)
+  || is_std_init_list (type)))
+  || DIRECT_LIST_INIT_P (init)))
 {
   /* With references and list-initialization, we need to deal with
 extending temporary lifetimes.  12.2p5: "A temporary bound to a

[Bug c++/58930] [C++11] Bogus error: converting to ... from initializer list would use explicit constructor

[paolo.carlini at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #2 from Paolo Carlini  ---
Mine.

[Bug c++/58753] Brace-initializing a vector with a direct-initialization NSDMI doesn't work in a template

[ville.voutilainen at gmail dot com]

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 recommend sending it to the mighty maintainer for review.

[Bug libstdc++/60326] Incorrect type from std::make_unsigned

[redi at gcc dot gnu.org]

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, __make_signed): Define
specializations for wchar_t, char16_t and char32_t.
* testsuite/20_util/make_signed/requirements/typedefs-4.cc: New.
* testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Correct
test for make_unsigned.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc:
Likewise.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line number.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-4.cc
  - copied, changed from r210471,
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug libstdc++/60326] Incorrect type from std::make_unsigned

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk so far

[Bug target/61195] New: single precision fmov does not need to switch mode

[chrbr at gcc dot gnu.org]

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
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org

for SH4/SH2A the compiler forces a PR mode switch for the floating point moves:

so

float
foo(float f)
{
return f;
}

compiles as:

mov.l   .L2,r1
lds.l   @r1+,fpscr
add #-4,r1
fmovfr4,fr0
add #4,r1
rts
lds.l   @r1+,fpscr
.L3:
.align 2
.L2:
.long   ___fpscr_values

This is not necessary, since the prevailing mode for PR=0 is single precision
(double precision would be set with SZ=1)

so the function can be just be compiled as

_foo:
rts
fmovfr4,fr0

[Bug fortran/61180] surprising -Wsurprising warning

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||jvdelisle at gcc dot gnu.org,
   ||sgk at troutmask dot 
apl.washingto
   ||n.edu

--- Comment #3 from Dominique d'Humieres  ---
(1) I shall RTFM before rather than after answering: -Wsurprising is indeed
included in -Wall!(which I find surprising, yet another bad naming).

(2) with the following patch

--- ../_clean/gcc/fortran/expr.c2014-05-07 12:46:43.0 +0200
+++ gcc/fortran/expr.c2014-05-15 12:00:21.0 +0200
@@ -3157,7 +3157,8 @@ gfc_check_assign (gfc_expr *lvalue, gfc_

   /* This is possibly a typo: x = f() instead of x => f().  */
   if (gfc_option.warn_surprising
-  && rvalue->expr_type == EXPR_FUNCTION && gfc_expr_attr (rvalue).pointer)
+  && rvalue->expr_type == EXPR_FUNCTION && gfc_expr_attr (rvalue).pointer
+  && gfc_expr_attr (lvalue).pointer)
 gfc_warning ("POINTER-valued function appears on right-hand side of "
  "assignment at %L", &rvalue->where);

--- ../_clean/gcc/fortran/invoke.texi2014-05-08 19:46:13.0 +0200
+++ gcc/fortran/invoke.texi2014-05-15 14:38:09.0 +0200
@@ -852,21 +852,26 @@ This currently produces a warning under 

I get (without regression)

[Book15] f90/bug% gfc pr61180.f90 -Wall
pr61180.f90:27.8:

  data3=get_data(foo)
1
Warning: POINTER-valued function appears on right-hand side of assignment at
(1)

I shamelessly admit a very limited understanding of 'gfc_expr_attr
(lvalue).(pointer|target))': replacing 'gfc_expr_attr (lvalue).pointer' with
'gfc_expr_attr (lvalue).target' gives the last two warning, while
'!gfc_expr_attr (lvalue).pointer' gives the first one only.

(3) Is the following change in the manual OK?

 @itemize @bullet
 @item
-An INTEGER SELECT construct has a CASE that can never be matched as its
-lower value is greater than its upper value.
+An @code{INTEGER SELECT} construct has a @code{CASE} that can never be
+matched as its lower value is greater than its upper value.

 @item
-A LOGICAL SELECT construct has three CASE statements.
+A @code{LOGICAL SELECT} construct has three @code{CASE} statements.

 @item
-A TRANSFER specifies a source that is shorter than the destination.
+A @code{TRANSFER} specifies a source that is shorter than the destination.

 @item
-The type of a function result is declared more than once with the same type. 
If
-@option{-pedantic} or standard-conforming mode is enabled, this is an error.
+The type of a function result is declared more than once with the same
+type.  If @option{-pedantic} or standard-conforming mode is enabled,
+this is an error.

 @item
 A @code{CHARACTER} variable is declared with negative length.
+
+@item
+@code{POINTER}-valued function appears on right-hand side of assignment
+to a pointer.
 @end itemize

 @item -Wtabs

Note I have wrapped some additional keyword in @code. Is it OK?

[Bug tree-optimization/61194] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[vincenzo.innocente at cern dot ch]

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]

[Bug target/61195] single precision fmov does not need to switch mode

[chrbr at gcc dot gnu.org]

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.

[Bug tree-optimization/61194] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[vincenzo.innocente at cern dot ch]

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;


Vectorizing loop at cond0.cc:9

cond0.cc:9: note: LOOP VECTORIZED.
cond0.cc:8: note: vectorized 1 loops in function.
c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/sw/lcg/contrib/gcc/4.8.1/x86_64-slc6-gcc48-opt/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/vdiez/gcc-4.8.1/configure
--prefix=/build/vdiez/gcc-4.8.1-installation
--with-mpfr=/afs/cern.ch/sw/lcg/external/mpfr/3.1.2/x86_64-slc6-gcc48-opt
--with-gmp=/afs/cern.ch/sw/lcg/external/gmp/5.1.1/x86_64-slc6-gcc48-opt
--with-mpc=/afs/cern.ch/sw/lcg/external/mpc/1.0.1/x86_64-slc6-gcc48-opt
--enable-libstdcxx-time --enable-lto
--with-isl=/afs/cern.ch/sw/lcg/external/isl/0.11.1/x86_64-slc6-gcc48-opt
--with-cloog=/afs/cern.ch/sw/lcg/external/cloog/0.18.0/x86_64-slc6-gcc48-opt
--enable-languages=c,c++,fortran,go
Thread model: posix
gcc version 4.8.1 (GCC) 


c++ -Ofast -Wall -fno-tree-slp-vectorize -ftree-loop-if-convert-stores -S
cond0.cc -msse4.2 -fopt-info-vec-missed

cond0.cc:9:3: note: misalign = 0 bytes of ref x[i_18]
cond0.cc:9:3: note: misalign = 0 bytes of ref w[i_18]
cond0.cc:9:3: note: misalign = 0 bytes of ref y[i_18]
cond0.cc:9:3: note: misalign = 0 bytes of ref k[i_18]
cond0.cc:9:3: note: misalign = 0 bytes of ref z[i_18]
cond0.cc:9:3: note: misalign = 0 bytes of ref z[i_18]
cond0.cc:9:3: note: virtual phi. skip.
cond0.cc:9:3: note: num. args = 4 (not unary/binary/ternary op).
cond0.cc:9:3: note: not ssa-name.
cond0.cc:9:3: note: use not simple.
cond0.cc:9:3: note: bit-precision arithmetic not supported.
cond0.cc:9:3: note: not vectorized: relevant stmt not supported: _6 = _5 > 0.0;

cond0.cc:9:3: note: bad operation or unsupported loop bound.
Vincenzos-MacBook-Pro-2:vectorize innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.1.0/4.10.0/lto-wrapper
Target: x86_64-apple-darwin13.1.0
Configured with: ../gcc-trunk/configure --disable-multilib --disable-bootstrap
--disable-libitm --enable-languages=c,c++,fortran,lto --disable-libsanitizer
--enable-lto
Thread model: posix
gcc version 4.10.0 20140430 (experimental) [trunk revision 209930] (GCC)

[Bug tree-optimization/61090] [4.10 Regression] ICE in build_ref_for_offset

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Martin Jambor  ---
I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01197.html

[Bug tree-optimization/61194] [4.9 Regression] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to work||4.7.0
   Target Milestone|--- |4.9.1
Summary|[regression 4.9.0]  |[4.9 Regression]
   |vectorization failed with   |vectorization failed with
   |"bit-precision arithmetic   |"bit-precision arithmetic
   |not supported" even if  |not supported" even if
   |conversion to int is|conversion to int is
   |requested   |requested

[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Martin Jambor  ---
I have proposed a fix on the mailing list:

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01199.html

[Bug tree-optimization/61090] [4.10 Regression] ICE in build_ref_for_offset

[jamborm at gcc dot gnu.org]

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-sra.c (sra_modify_expr): Pass the current gsi to
build_ref_for_model.

testsuite/
* gcc.dg/tree-ssa/pr61090.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61090.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug tree-optimization/61090] [4.10 Regression] ICE in build_ref_for_offset

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-05-15
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
Summary|[4.9 Regression]|[4.9/4.10 Regression]
   |vectorization failed with   |vectorization failed with
   |"bit-precision arithmetic   |"bit-precision arithmetic
   |not supported" even if  |not supported" even if
   |conversion to int is|conversion to int is
   |requested   |requested
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I see on trunk after if-conversion

  _6 = _5 > 0.0;
  _9 = _7 < _8;
  _10 = _9 & _6;
  _11 = (int) _10;
  k[i_18] = _11;
  iftmp.0_13 = z[i_18];
  iftmp.0_2 = _10 ? iftmp.0_13 : _8;
  z[i_18] = iftmp.0_2;

so what happens is that we do have "bit-precision" arithmetic with the
bitwise and.

This is a regression because of the way we lower comparisons now I guess.

I will have a look.

[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)

[jamborm at gcc dot gnu.org]

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_indirect_edges_after_inlining): Check
type_preserved flag when the indirect edge is polymorphic.

testsuite/
* g++.dg/ipa/pr61085.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr61085.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[rguenth at gcc dot gnu.org]

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 widened then
(though they are supported as bit-precision).

[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)

[jamborm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Martin Jambor  ---
Fixed.

[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)

[jamborm at gcc dot gnu.org]

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_indirect_edges_after_inlining): Check
type_preserved flag when the indirect edge is polymorphic.

testsuite/
* g++.dg/ipa/pr61085.C: New test.


Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr61085.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/ipa-prop.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with "bit-precision arithmetic not supported" even if conversion to int is requested

[vincenzo.innocente at cern dot ch]

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!

[Bug c/56724] sub-optimal location in error

[tromey at gcc dot gnu.org]

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 incompatible pointer type
   return callf (23, 72,
  ^
r.c:3:5: note: expected ‘int (*)(double *)’ but argument is of type ‘int
(*)(int *)’
 int callf (int, int, int (*)(double *));
 ^


Note how the first warning now points to "callf", whereas
in comment #0 it pointed to the actual argument causing the diagnostic.

The new situation is much worse for me as it prevents automated
rewriting...

[Bug c/56724] sub-optimal location in error

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Tom Tromey from comment #5)
> The new situation is much worse for me as it prevents automated
> rewriting...

What automated rewriting?

For 4.10/11, I would like to implement either fix-it hints or location ranges,
and I wonder what would be the most useful of the two.

[Bug fortran/61028] [4.9/4.10 Regression] -g3 -g leads to spurious warnings

[dominiq at lps dot ens.fr]

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.

[Bug c/56724] sub-optimal location in error

[tromey at gcc dot gnu.org]

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'm experimenting with automated rewriting of C to C++
using -Wc++-compat and some scripts.
https://github.com/tromey/gdb-refactoring-scripts

It's fairly specific to gdb.

[Bug fortran/61028] [4.9/4.10 Regression] -g3 -g leads to spurious warnings

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Joost VandeVondele  
---
so, fixed.

[Bug middle-end/61196] New: Optimizer does not handle memory accesses with two pointers to same location correctly

[bjoern.m.haase at web dot de]

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
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjoern.m.haase at web dot de

Created attachment 32800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32800&action=edit
testcase program

The following test case program boils down an issue with gcc.4.5.3 on the
cygwin platform. The bug is not present in the mingw version 4.7.2 that I also
have on my system. It, thus, might be fixed, but adding the test case might be
worth the effort to check for regressions.

When compiling with -O0 -O1 it outputs the expected result, when compiling with 
-O2 or -O3, it produces an error. 

The code is somewhat strange but I stumbled over this segment in production
code of the libsodium crypto library. Since it's a wrong code bug on an
important platform (X86), I did classify it as "major" bug.


Output of "gcc testcase.c -O0 -o test.exe && test.exe" :
bbccddee 
66778899 
22334455 
ff001122 

Output of "gcc testcase.c -O3 -o test.exe && test.exe" :

0 
28d41c 
28ac88 
49435341 
We had an error.

Output of "gcc testcase.c -O2 -o test.exe && test.exe" :

bbccddee 
28d41c 
28ac68 
2d465455 
We had an error.


Declaring the tp pointer in the testcase as volatile fixes the problem. For
this reason, I doubt that it's rather the middle end than the X86 backend.


///
/// File testcase.c
///

#include 

typedef unsigned long int uint32;

typedef struct {
  unsigned long long a;
  unsigned long long b;
} int128;

int128 x = {0x1234567,0x1234567};

void copy2(int128 *r, const int128 *x)
{
  r->a = x->a;
  r->b = x->b;
}

void shufd(int128 *r, const int128 *x, const unsigned int c)
{
  int128 t;
  uint32 *tp = (uint32 *)&t;
  const uint32 *xp = (const uint32 *)x;
  tp[0] = xp[c&3];
  tp[1] = xp[(c>>2)&3];
  tp[2] = xp[(c>>4)&3];
  tp[3] = xp[(c>>6)&3];
  copy2(r,&t);
}

int main (void)
{
   int didErrorOccur = 0;

   x.a = 0x112233445566778899ll;
   x.b = 0xaabbccddeeff001122ll;
   shufd (&x,&x,0x93);
   printf ("%x \n", x.a);
   printf ("%x \n", (x.a >> 32));
   printf ("%x \n", x.b);
   printf ("%x \n", (x.b >> 32));
   if (x.a != 0x66778899bbccddeell)
   {
  didErrorOccur = 1;
   }
   if (x.b != 0xff0011334455ll)
   {
  didErrorOccur = 1;
   }
   if (didErrorOccur)
   {
  printf ("We had an error.\n");
   }
}

[Bug c++/61151] [4.9/4.10 Regression] ICE with lambda

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61151

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug libstdc++/61166] overflow when parse number in std::duration operator""

[redi at gcc dot gnu.org]

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 implement without using templates.

[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775

[law at redhat dot com]

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 (r0))

If we process B first, then we will set the modified flag for A as well as a
mode for A.  At that time we will verify that (set (r0) (r1)) in the desired
mode is valid.  We'll update A appropriately and queue B for removal and a copy
insn for insertion.

If we then process C, we may decide that we want an even wider mode for A. 
This will change A in the obvious ways.

At a later point we'll emit the queued copy insn which take the wider mode
which has not been verified and we lose.

The key realization is that we can store more than just "we modified A".   So
when processing B, we set A's state to "modifed, do not change its mode
further".  When we process C, we'd see that status on A and punt optimizing C.

I would expect this to be rare in practice, but I'll do some experiments to see
how often we have to suppress an optimization.

[Bug c++/61103] False-positive, template-independent name taken as dependent name

[synxis at gmx dot fr]

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.

[Bug tree-optimization/61197] New: wrong code at -O3 on x86_64-linux (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61197

Bug ID: 61197
   Summary: wrong code at -O3 on x86_64-linux (in both 32-bit and
64-bit modes)
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code on x86_64-linux at -O3 in
both 32-bit and 64-bit modes.  

This is a regression from 4.9.x. 

It seems different from PR 61140 and PR 61150 as -fno-tree-dce makes both
disappear, but not this one. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
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 -O3 small.c; a.out
Aborted (core dumped)
$





int a, b = 1, *c = &a; 

int
foo ()
{
  if (b)
b |= 1;
  else
{
  b = 1;
  return 0;
}
  return 1;
}

int
main ()
{
  *c = foo ();
  if (a != 1) 
__builtin_abort (); 
  return 0;
}

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

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

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

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(DummyTask* task) {
> task->pr.get_future().wait();

There's a race condition here between the calls to get_future() and
set_value(), so the program has undefined behaviour.

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
promise.

The easiest fix is to call get_future() before passing the task into a new
thread, and store it in a std::vector>

If I do that I can't make it hang any longer.

I'll keep looking into it though ...

[Bug libstdc++/60966] std::call_once sometime hangs

[hideaki.kimura at gmail dot com]

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 promise.
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 difference between future/shared_future)

Taking a glance at boost::promise code, I got an impression that their code is
safe against concurrent get_future() and set_value() because get_future()
either does atomic swap in lazy_init() or does nothing (allocated in
constructor).
I guess that's why Thomas observed that the issue doesn't happen in
boost::promise.

I'm not sure what the C++ standard says. I haven't seen a single human being
who has read it through.

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

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 difference between future/shared_future)

It's the same rule to applies to all types in the standard library unless
specified otherwise: concurrent accesses are only safe if they are all reads
(i.e. const operations). Any writes (non-const operations) must be manually
synchronised.

get_future() is non-const, set_value() is non-const.

> I'm not sure what the C++ standard says. I haven't seen a single human being
> who has read it through.

30.6.4 [futures.state] says which functions are synchronised,
promise::get_future() is not one of them.

I'm still looking into whether there is a bug that allows the shared state to
be destroyed while the call to std::call_once() is still in progress, or if
that can only happen due to user error.

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

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 ensuring the shared state is not deleted
because there is a future object still referring to it) but the fundamental
problem with that code remains:

You are calling the promise destructor before the call to set_value()
completes.

You are assuming that as soon as the shared state becomes ready the promise is
no longer in use, but that's not true. After the shared state is made ready the
rest of the set_value() function runs, which accesses members of the shared
state. If you destroy the promise (and it has the only reference to the shared
state) then it will destroy its members while they are still being used.

This is a bug in your code, std::promise is like any other type: you must not
delete it while another thread is still using it.

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-05-15
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #20 from Jonathan Wakely  ---
I see an easy way to make std::promise handle this form of user error though.

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

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 state will not be destroyed even if ~promise()
starts before the return from set_value.

It also moves the condition variables broadcast later, so that waiting threads
are not signalled until right before returning.

[Bug libstdc++/60966] std::call_once sometime hangs

[hideaki.kimura at gmail dot com]

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, with some simplification
std::promise promise;
auto future = promise.get_future();
std::async or thread ( {promise.set_value();});
future.get();
}

The user of std::promise must make sure the asynchronous thread has surely
exitted at least from promise.set_value() before std::promise gets out of
scope.
promise/future is a handy way to synchronize between threads, but to use it one
must protect it with thread synchronization..? That's quite tedious.


I've just seen the patch as of writing this comment. I guess it solves the
issue?

(In reply to Jonathan Wakely from comment #19)
> (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 ensuring the shared state is not
> deleted
> because there is a future object still referring to it) but the fundamental
> problem with that code remains:
> 
> You are calling the promise destructor before the call to set_value()
> completes.
> 
> You are assuming that as soon as the shared state becomes ready the promise
> is no longer in use, but that's not true. After the shared state is made
> ready the rest of the set_value() function runs, which accesses members of
> the shared state. If you destroy the promise (and it has the only reference
> to the shared state) then it will destroy its members while they are still
> being used.
> 
> This is a bug in your code, std::promise is like any other type: you must
> not delete it while another thread is still using it.

[Bug libstdc++/60966] std::call_once sometime hangs

[redi at gcc dot gnu.org]

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 shared state is
ready between the value being set and the condvar signal)

> ... ah, and that's why what Thomas initially posted could also see a hang.
> { // copy-paste again to refresh memory, with some simplification
> std::promise promise;
> auto future = promise.get_future();
> std::async or thread ( {promise.set_value();});
> future.get();
> }
> 
> The user of std::promise must make sure the asynchronous thread has surely
> exitted at least from promise.set_value() before std::promise gets out of
> scope.
> promise/future is a handy way to synchronize between threads, but to use it
> one must protect it with thread synchronization..? That's quite tedious.

If you give references to local variables to other threads then you need to be
careful about lifetimes, but this code is reasonable and should work.

> I've just seen the patch as of writing this comment. I guess it solves the
> issue?

Yes, it should solve the problem, by incrementing the reference count on the
shared state temporarily, until the set_value() call has completed.

[Bug libstdc++/60966] std::call_once sometime hangs

[fawaka at gmail dot com]

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 either way (most document
> > just mentions about difference between future/shared_future)
> 
> It's the same rule to applies to all types in the standard library unless
> specified otherwise: concurrent accesses are only safe if they are all reads
> (i.e. const operations). Any writes (non-const operations) must be manually
> synchronised.
> 
> get_future() is non-const, set_value() is non-const.

I can see your point from a C++ point of view, but this doesn't make sense from
a usable threading point of view. IMHO, the whole point of abstractions such as
promises is to isolate the user from such issues.

Leon

[Bug c++/61198] Crash when selecting specializations through aliases.

[i-photon at hotmail dot com]

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.

[Bug c++/61198] New: Crash when selecting specializations through aliases.

[i-photon at hotmail dot com]

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
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i-photon at hotmail dot com

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.8.2/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: /cygdrive/i/szsz/tmpp/gcc4/gcc-4.8.2-2/src/gcc-4.8.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc4/gcc-4.8.2-2/src/gcc-4.8.2 --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-arch=i686
--with-tune=generic --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/cc1plus.exe -E -quiet -v -Dunix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../include/w32api -idirafter
../../include/w32api test.cpp -mtune=generic -march=i686 -std=c++11
-fpch-preprocess -o test.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../i686-pc-cygwin/include"
ignoring nonexistent directory "../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/i686-pc-cygwin
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/include/c++/backward
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/include
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/include-fixed
 /usr/include
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/../../../../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-pc-cygwin/4.8.2/cc1plus.exe -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -std=c++11 -version
-o test.s
GNU C++ (GCC) version 4.8.2 (i686-pc-cygwin)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.2 (i686-pc-cygwin)
compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2, MPC
version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 68b77e646651014e4504034a5c7768ce
test.cpp: In substitution of ‘template using rebind = broken<2,
derp_t> [with target_t = float]’:
test.cpp:18:33:   required from here
test.cpp:13:36: internal compiler error: in retrieve_specialization, at
cp/pt.c:1021
  using rebind = broken<2, target_t>;
^

test.cpp:13:36: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

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_STARTED): New define.
(__TM_simple_begin): Use it.
(__TM_begin): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/htmxlintrin.h

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

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_STARTED): New define.
(__TM_simple_begin): Use it.
(__TM_begin): Likewise.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/htmxlintrin.h

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

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/61193
* config/rs6000/htmxlintrin.h (_HTM_TBEGIN_STARTED): New define.
(__TM_simple_begin): Use it.
(__TM_begin): Likewise.

Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/rs6000/htmxlintrin.h

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-05-16
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Peter Bergner  ---
After discussing this with the XL compiler team, the S390 GCC team and
the Power GCC team, we have decided to leave the incompatibility between
Power and S390.  However, the XL and GCC compilers will be compatible
with each other when targeting the same processor target.  To mitigate
the incompatibility somewhat, we have decided to add a macro to the
powerpc*-linux's htmintrin.h file that defines what the "sucessful"
return status value of the __TM_simple_begin() and __TM_begin() intrinsic
function is.  This macro is already defined in the S390's htmintrin.h
header file and is used by the S390 to determine whether the transaction
was successfully started or not.  By adding the same macro on Power, we
allow users to write common code between Power and S390, even though our
successful return status values are different.

For example, the following code can be used on Power and S390, even
though the actual value returned by __TM_simple_begin() is different.

  if ((tx_state = __TM_simple_begin ()) == _HTM_TBEGIN_STARTED)
{
  /* Transaction State Initiated.  */
  ...
}
  else
{
  /* Transaction State Failed.  */
  ...
}

[Bug target/61193] ABI incompatibility between POWER and Z HTM builtins and intrinsics

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61193

Peter Bergner  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2014-05/msg01239.ht
   ||ml
 Resolution|--- |FIXED

--- Comment #5 from Peter Bergner  ---
Fixes committed to mainline and the 4.9 and 4.8 branches.

[Bug libstdc++/61166] overflow when parse number in std::duration operator""

[kan.liu.229 at gmail dot com]

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 required by the standard but impossible to implement without using
> templates.

_Select_type already does the overflow check, so *template implemented
operators* is still redundant I think. Since the standard units (std::hours,
milliseconds ...) requires the duration::rep to be *int64_t*, there's no need
to do too much check.