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

2014-05-17 Thread bjoern.m.haase at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61196

--- Comment #2 from Björn Haase  ---
@Eric: Thank you for your fast feedback :-).
I have contacted the maintainer of the library and the original author of the
code so that we may fix the problem there. I've just again learnt something on
an additional aspect in the C language definition that I've not been aware of
beforehand.

[Bug c++/21802] Two-stage name lookup fails for operators

2014-05-17 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot 
com,
   ||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #3 from Paolo Carlini  ---
Let's double check with Richard that this specific issue can be closed.


[Bug c++/47202] Endless recursion during mangling

2014-05-17 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47202

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  ---
Let's add Jason in CC about this. In particular the snippet in Comment #2.


[Bug bootstrap/61210] New: bootstrap failure with clang

2014-05-17 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210

Bug ID: 61210
   Summary: bootstrap failure with clang
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com

For months, I've been using clang and clang++ to bootstrap trunk gcc.
Works faster than gcc and the warning messages are interesting ;->

In the last couple of weeks, since wide-int code went into gcc trunk,
this has broke. 

clang suggested using flag -fheinous-gnu-extensions, but that didn't help.

Here is 20140514 failing to bootstrap

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/simplify-rtx.o differs
gcc/fold-const.o differs
gcc/tree-ssa-ccp.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/dcb/gcc/working'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/dcb/gcc/working'
make: *** [bootstrap] Error 2
Thu 15 May 18:28:51 BST 2014

Configure line is

../src/trunk/configure --prefix=/home/dcb/gcc/results --enable-checking=release
--enable-languages=c,c++,fortran --disable-werror CC="clang -g -O2 -Wall
-fheinous-gnu-extensions" CXX="clang++ -g -O2 -Wall -fheinous-gnu-extensions"

and bootstrap line is

make BOOT_CFLAGS='-g -O3' CFLAGS_FOR_TARGET='-g -O3' -j 2 bootstrap


[Bug bootstrap/61210] bootstrap failure with clang

2014-05-17 Thread manu at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to David Binderman from comment #0)
> For months, I've been using clang and clang++ to bootstrap trunk gcc.
> Works faster than gcc and the warning messages are interesting ;->

In which sense are they interesting?

[Bug ipa/61211] New: [4.9/4.10 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -O3 -fno-inline

2014-05-17 Thread zsojka at seznam dot cz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61211

Bug ID: 61211
   Summary: [4.9/4.10 Regression] ICE: verify_cgraph_node failed:
edge points to wrong declaration with -O3 -fno-inline
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 32813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32813&action=edit
preprocessed source (g++.dg/ipa/pr60640-2.C)

Maybe related to PR61160.

Compiler output:
$ gcc -O3 -fno-inline pr60640-2.ii 
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C:15:8: error: edge
points to wrong declaration:
 H h (0);
^
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x7f22df143738
precision 32 min  max 
pointer_to_this >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x7f22df2d7348
arg-types >>
readonly addressable used nothrow static autoinline decl_5 QI defer-output
file /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C line 8 col 25
align 16 context  initial 
abstract_origin 
result 
used unsigned ignored SI file
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C line 8 col 40 size
 unit size 
align 32 context 
abstract_origin >
struct-function 0x7f22df2cb540>
 Instead of: 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x7f22df143738
precision 32 min  max 
pointer_to_this >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x7f22df2b9690 method
basetype 
arg-types 
chain 
chain >>>
pointer_to_this >
readonly addressable asm_written used nothrow public weak virtual decl_5 QI
file /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C line 8 col 25
align 8 context 
arguments 
readonly unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7f22df2b97e0>
readonly unsigned DI file
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C line 8 col 34 size
 unit size 
align 64 context 
arg-type 
chain 
unsigned QI file
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C line 8 col 28 size
 unit size 
align 8 context 
arg-type >>
full-name "virtual unsigned int G::_ZThn8_NK1G1fEb(bool) const"
   >
_ZNK1H1fEv/3 (virtual unsigned int H::f() const) @0x7f22df2c
  Type: function definition analyzed
  Visibility: externally_visible public weak comdat comdat_group:_ZNK1H1fEv
one_only virtual
  Address is taken.
  References: 
  Referring: _ZTV1H/5 (addr)
  Availability: available
  First run: 0
  Function flags: body
  Called by: 
  Calls: _ZNK1G1fEb.constprop.1/41 (1.00 per call) (can throw external) 
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ipa/pr60640-2.C:15:8: internal compiler
error: verify_cgraph_node failed
0x941bff verify_cgraph_node(cgraph_node*)
/mnt/svn/gcc-trunk/gcc/cgraph.c:2996
0x942987 verify_cgraph()
/mnt/svn/gcc-trunk/gcc/cgraph.c:3011
0x94e3d7 cgraph_materialize_all_clones()
/mnt/svn/gcc-trunk/gcc/cgraphclones.c:1134
0x94ab17 compile()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2208
0x94b844 finalize_compilation_unit()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2329
0x7291ae cp_write_global_declarations()
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4625
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r210490 - ICE
4.9 r210307 - ICE
4.8 r210303 - OK
4.7 r210302 - OK
4.6 r197894 - OK


[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

2014-05-17 Thread uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

--- Comment #24 from uros at gcc dot gnu.org ---
Author: uros
Date: Sat May 17 10:35:44 2014
New Revision: 210549

URL: http://gcc.gnu.org/viewcvs?rev=210549&root=gcc&view=rev
Log:
Backport from mainline
2014-04-25  H.J. Lu  

PR target/60969
* config/i386/i386.md (*movsf_internal): Set MODE to SI for
alternative 12.


Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.md


[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

2014-05-17 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #25 from Uroš Bizjak  ---
Fixed.

[Bug bootstrap/61210] bootstrap failure with clang

2014-05-17 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61210

--- Comment #2 from David Binderman  ---
(In reply to Manuel López-Ibáñez from comment #1)
> In which sense are they interesting?

They show bugs in gcc trunk.

Same as running cppcheck over gcc trunk shows bugs.

Both both cases, I've reported the ones that I think are worth fixing.

[Bug c/61212] New: gcc build failure on "dos file system" due to warnings treated as errors

2014-05-17 Thread tprince at computer dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61212

Bug ID: 61212
   Summary: gcc build failure on "dos file system" due to warnings
treated as errors
   Product: gcc
   Version: fortran-dev
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tprince at computer dot org

gcc trunk and fortran-dev build failure
../../libcpp/files.c:393:56: error: suggest parentheses around ‘&&’ within ‘||’
[-Werror=parentheses]
   if (CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp
^
cc1plus: all warnings being treated as errors



Adding the parens as suggested has been working:

  if ((CPP_OPTION (pfile, canonical_system_headers) && file->dir->sysp)
#ifdef HAVE_DOS_BASED_FILE_SYSTEM
  || !file->dir->sysp
#endif
 )


Apparently, this is exposed only on "dos based file system."

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

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194

--- Comment #15 from Marc Glisse  ---
Seems related to PR 57328.


[Bug tree-optimization/61150] wrong code at -O3 on x86_64-linux

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61150

--- Comment #2 from Marc Glisse  ---
Author: glisse
Date: Sat May 17 12:37:58 2014
New Revision: 210554

URL: http://gcc.gnu.org/viewcvs?rev=210554&root=gcc&view=rev
Log:
2014-05-17  Marc Glisse  

PR tree-optimization/61140
PR tree-optimization/61150
PR tree-optimization/61197
gcc/
* tree-ssa-phiopt.c (value_replacement): Punt on multiple phis.
gcc/testsuite/
* gcc.dg/tree-ssa/pr61140.c: New file.
* gcc.dg/tree-ssa/pr61150.c: New file.
* gcc.dg/tree-ssa/pr61197.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61140.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61150.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61197.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c


[Bug tree-optimization/61140] [4.10 Regression] wrong code at -O1 and above on x86_64-linux-gnu

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61140

--- Comment #3 from Marc Glisse  ---
Author: glisse
Date: Sat May 17 12:37:58 2014
New Revision: 210554

URL: http://gcc.gnu.org/viewcvs?rev=210554&root=gcc&view=rev
Log:
2014-05-17  Marc Glisse  

PR tree-optimization/61140
PR tree-optimization/61150
PR tree-optimization/61197
gcc/
* tree-ssa-phiopt.c (value_replacement): Punt on multiple phis.
gcc/testsuite/
* gcc.dg/tree-ssa/pr61140.c: New file.
* gcc.dg/tree-ssa/pr61150.c: New file.
* gcc.dg/tree-ssa/pr61197.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61140.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61150.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61197.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c


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

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61197

--- Comment #4 from Marc Glisse  ---
Author: glisse
Date: Sat May 17 12:37:58 2014
New Revision: 210554

URL: http://gcc.gnu.org/viewcvs?rev=210554&root=gcc&view=rev
Log:
2014-05-17  Marc Glisse  

PR tree-optimization/61140
PR tree-optimization/61150
PR tree-optimization/61197
gcc/
* tree-ssa-phiopt.c (value_replacement): Punt on multiple phis.
gcc/testsuite/
* gcc.dg/tree-ssa/pr61140.c: New file.
* gcc.dg/tree-ssa/pr61150.c: New file.
* gcc.dg/tree-ssa/pr61197.c: New file.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61140.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61150.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61197.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c


[Bug tree-optimization/61140] [4.10 Regression] wrong code at -O1 and above on x86_64-linux-gnu

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61140

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #4 from Marc Glisse  ---
Thanks a lot for the PR, getting a nice short testcase so soon after the
commit, while the patch was still fresh in my mind, was very useful.


[Bug tree-optimization/61150] wrong code at -O3 on x86_64-linux

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61150

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #3 from Marc Glisse  ---
.


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

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61197

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #5 from Marc Glisse  ---
(In reply to Richard Biener from comment #3)
> Make sure to add all the various testcases.

Done.


[Bug tree-optimization/61110] Simplify value_replacement in phiopt

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61110

--- Comment #1 from Marc Glisse  ---
Another extension is discussed here:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00704.html
(also transform if there is a second phi but it could be turned into a cmove)


[Bug c++/61213] New: std::forward_as_tuple and std::tuple and any rvalue loose data

2014-05-17 Thread tower120 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61213

Bug ID: 61213
   Summary: std::forward_as_tuple and std::tuple and any
rvalue loose data
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tower120 at gmail dot com

std::forward_as_tuple elements loose data on -O2.
Works fine with -O0


Consider the following code:
http://coliru.stacked-crooked.com/a/67499e052283bd5a

#include 
#include 

class Widget {
public:
  Widget(int h) : h(h){}
  int h;
};

template
struct RvalueTest{
RvalueTest(T&& value) : value( std::forward(value) ){}
T&& value;
};

int main() {
auto t = std::forward_as_tuple(Widget(12));
//auto t = std::tuple(Widget(12));  // this not work also
std::cout << std::get<0>(t).h;// <-- some random value here

/// This one not work, either:
/*RvalueTest r(Widget(12));
std::cout << r.value.h;*/
}


Code from above works fine with clang compiler.
I suspect that rvalue object life time is wrong in -O2 mode.


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

2014-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966

--- Comment #27 from Jonathan Wakely  ---
Author: redi
Date: Sat May 17 12:58:46 2014
New Revision: 210556

URL: http://gcc.gnu.org/viewcvs?rev=210556&root=gcc&view=rev
Log:
PR libstdc++/60966
* include/std/future (__future_base::_State_baseV2::_M_set_result):
Pass lock into _M_do_set and hold it until the function returns.
Signal condition variable after call_once completes.
(__future_base::_State_baseV2::_M_do_set): Use lock argument. Do not
signal here.
* testsuite/30_threads/promise/60966.cc: New.

Added:
trunk/libstdc++-v3/testsuite/30_threads/promise/60966.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/future


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

2014-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966

--- Comment #28 from Jonathan Wakely  ---
Author: redi
Date: Sat May 17 13:01:11 2014
New Revision: 210557

URL: http://gcc.gnu.org/viewcvs?rev=210557&root=gcc&view=rev
Log:
PR libstdc++/60966
* include/std/future (__future_base::_State_baseV2::_M_set_result):
Signal condition variable after call_once returns.
(__future_base::_State_baseV2::_M_do_set): Do not signal here.
(promise::set_value, promise::set_exception): Increment the reference
count on the shared state until the function returns.
* testsuite/30_threads/promise/60966.cc: New.

Added:
branches/gcc-4_9-branch/libstdc++-v3/testsuite/30_threads/promise/60966.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/std/future


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

2014-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.4
  Known to fail||4.8.2, 4.9.0

--- Comment #29 from Jonathan Wakely  ---
Fixed on trunk and 4.9 branch so far.


[Bug c++/61213] [4.7/4.8/4.9/4.10 Regression] std::forward_as_tuple and std::tuple and any rvalue loose data

2014-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61213

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-05-17
  Known to work||4.6.4
Summary|std::forward_as_tuple and   |[4.7/4.8/4.9/4.10
   |std::tuple and any |Regression]
   |rvalue loose data   |std::forward_as_tuple and
   ||std::tuple and any
   ||rvalue loose data
 Ever confirmed|0   |1
  Known to fail||4.10.0, 4.7.3, 4.8.2, 4.9.0

--- Comment #1 from Jonathan Wakely  ---
4.6 gave the right answer

Using -fno-indirect-inlining gives the correct result

Also reproducable with -O1 -findirect-inlining -finline-small-functions


[Bug c++/61213] [4.7/4.8/4.9/4.10 Regression] std::forward_as_tuple and std::tuple and any rvalue loose data

2014-05-17 Thread tower120 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61213

--- Comment #2 from tower120  ---
(In reply to Jonathan Wakely from comment #1)
> Using -fno-indirect-inlining gives the correct result

I not see this with
-std=c++11 -O2 -fno-indirect-inlining -Wall -pedantic -pthread

http://coliru.stacked-crooked.com/a/e7c9408daef01448


[Bug c++/61213] [4.7/4.8/4.9/4.10 Regression] std::forward_as_tuple and std::tuple and any rvalue loose data

2014-05-17 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61213

--- Comment #3 from Marc Glisse  ---
Are you sure the code is valid? It doesn't seem so to me.

gcc's optimizers have become good enough to recycle the space from dead
temporaries.


[Bug c++/61213] [4.7/4.8/4.9/4.10 Regression] std::forward_as_tuple and std::tuple and any rvalue loose data

2014-05-17 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61213

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #3)
> Are you sure the code is valid? It doesn't seem so to me.

Good point, the Widget temporary goes out of scope at the end of the expression
and the tuple holds a dangling reference.


[Bug c++/52875] ADL failure + ICE in decltype

2014-05-17 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52875

--- Comment #2 from Paolo Carlini  ---
This is fixed in 4.8.3, 4.9.0 and trunk. I'm adding the testcase and closing
the bug.


[Bug c++/52875] ADL failure + ICE in decltype

2014-05-17 Thread paolo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52875

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat May 17 20:22:30 2014
New Revision: 210562

URL: http://gcc.gnu.org/viewcvs?rev=210562&root=gcc&view=rev
Log:
2014-05-17  Paolo Carlini  

PR c++/52875
* g++.dg/cpp0x/decltype58.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/decltype58.C
Modified:
trunk/gcc/testsuite/ChangeLog


[Bug c++/52875] ADL failure + ICE in decltype

2014-05-17 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52875

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||4.10.0, 4.9.0
 Resolution|--- |FIXED

--- Comment #4 from Paolo Carlini  ---
This is fixed in 4.8.3, 4.9.0 and trunk. I'm adding the testcase and closing
the bug.


[Bug ipa/60854] [4.9 Regression] inline constructor of extern template

2014-05-17 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854

--- Comment #6 from Jan Hubicka  ---
Author: hubicka
Date: Sat May 17 22:18:25 2014
New Revision: 210563

URL: http://gcc.gnu.org/viewcvs?rev=210563&root=gcc&view=rev
Log:

PR ipa/60854
* ipa.c (symtab_remove_unreachable_nodes): Mark targets of
external aliases alive, too.
* g++.dg/torture/pr60854.C: New testcase.

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


[Bug target/61208] armhf: generated asm code produces "branch out of range" error in gas with -Os

2014-05-17 Thread mh+gcc at glandium dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208

--- Comment #2 from Mike Hommey  ---
This doesn't happen with gcc 4.9.


[Bug c++/58664] [c++11] ICE initializing array of incomplete type within union

2014-05-17 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58664

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2014-05-18
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

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


[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

2014-05-17 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #27 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun May 18 02:29:27 2014
New Revision: 210574

URL: http://gcc.gnu.org/viewcvs?rev=210574&root=gcc&view=rev
Log:
2014-05-17  Jerry DeLisle  

PR libfortran/52539
* io/io.h (gfc_unit): New function pointers *next_char_fn_ptr
and *push_char_fn_ptr.
*io/list_read.c (next_char): Create macro with this name to call
the new function pointer. Split the original next_char function
into three new functions. (next_char_default, next_char_internal,
next_char_utf8): New functions. (push_char): Create macro with
this name to call new function pointer. Split the original
push_char into three new functions. (push_char_default,
push_char_internal, push_char4): New functions. (set_workers):
New function to initilize the function pointers depending on the
type of IO to be performed. (list_formatted_read_scalar): Use
set_workers function. (finish_list_read): Likewise.
(namelist_read): Likewise.
(nml_get_obj_data): Use push_char_default.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/list_read.c


[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

2014-05-17 Thread jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #28 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun May 18 02:34:02 2014
New Revision: 210575

URL: http://gcc.gnu.org/viewcvs?rev=210575&root=gcc&view=rev
Log:
2014-05-17  Jerry DeLisle  

PR libfortran/52539
* gfortran.dg/namelist_utf8.f90: New test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_utf8.f90


[Bug c++/61214] New: [4.9 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization

2014-05-17 Thread delr...@dolphin-emu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214

Bug ID: 61214
   Summary: [4.9 regression] Weird interaction between
-fvisibility-inlines-hidden, inline virtuals and
devirtualization
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: delr...@dolphin-emu.org

Created attachment 32814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32814&action=edit
Small test case reproducing this issue

A shared library (libtest.so) is compiled using -fvisibility=hidden
-fvisibility-inlines-hidden. This library exports (visibility=default) a class
hierarchy with virtual inline methods:

struct VISIBILITY_DEFAULT Base { virtual Base* clone() { return new Base(); }};
struct VISIBILITY_DEFAULT Foo { virtual Base* clone() { return new Foo(); }};
// + at least one method that is defined in a compilation unit, along with the
vtable, typeinfo, etc.

The code that uses libtest.so looks like this:
Base* obj = new Foo();
obj->clone();

When this is compiled to libtest.so, Base::clone and Foo::clone are not present
among the exported symbols. This did not cause issues before g++4.9 because g++
was not smart enough to determine that "obj" is always a Foo. It always issued
a call through the vtable, which *is* exported by libtest.so (and contains a
valid entry for Foo::clone).

Now, with g++4.9 and (better) devirtualization, g++ tries to generate a direct
call to Foo::clone. But instead of instantiating the inline function, it
assumes the inline function is already instantiated. This fails at link time
because no definition of Foo::clone can be found.

Small test case attached (with Makefile, reproduces the bug on g++4.9 on Linux
x86_64). In practice, s/libtest/wxWidgets/,
s/Foo::clone/wxCommandEvent::Clone/. Whether this is a bug of wxWidgets that
should not be using -fvisibility-inlines-hidden or a bug of g++4.9 that should
be instantiating the inline function, is something you will have to debate :)

[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup

2014-05-17 Thread sandra at codesourcery dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758

Sandra Loosemore  changed:

   What|Removed |Added

 CC||sandra at codesourcery dot com

--- Comment #5 from Sandra Loosemore  ---
The patch committed as r210215 is broken for -mthumb on arm-none-eabi:

libtool: compile: 
/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/./gcc/xgcc
-shared-libgcc
-B/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/./gcc
-nostdinc++
-L/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/src
-L/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/src/.libs
-L/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/libsupc++/.libs
-B/scratch/sandra/arm-fsf/install/arm-none-eabi/bin/
-B/scratch/sandra/arm-fsf/install/arm-none-eabi/lib/ -isystem
/scratch/sandra/arm-fsf/install/arm-none-eabi/include -isystem
/scratch/sandra/arm-fsf/install/arm-none-eabi/sys-include -mthumb
-I/scratch/sandra/arm-fsf/src/gcc-mainline/libstdc++-v3/../libgcc
-I/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/include/arm-none-eabi
-I/scratch/sandra/arm-fsf/obj/gcc-mainline-0-arm-none-eabi-i686-pc-linux-gnu/arm-none-eabi/thumb/libstdc++-v3/include
-I/scratch/sandra/arm-fsf/src/gcc-mainline/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=eh_arm.lo -g -O2 -mthumb -c
/scratch/sandra/arm-fsf/src/gcc-mainline/libstdc++-v3/libsupc++/eh_arm.cc -o
eh_arm.o
/tmp/cchJLQxH.s: Assembler messages:
/tmp/cchJLQxH.s:26: Error: invalid register list to push/pop instruction --
`pop {r1,r2,r3,lr}'

It looks to me like lr is valid in the reglist for PUSH but not POP on Thumb.

Since this breaks builds, please either fix ASAP or revert the broken patch.


[Bug tree-optimization/61140] [4.10 Regression] wrong code at -O1 and above on x86_64-linux-gnu

2014-05-17 Thread su at cs dot ucdavis.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61140

--- Comment #5 from Zhendong Su  ---
(In reply to Marc Glisse from comment #4)
> Thanks a lot for the PR, getting a nice short testcase so soon after the
> commit, while the patch was still fresh in my mind, was very useful.

You're welcome Marc. Thanks for the fix!


[Bug c++/21802] Two-stage name lookup fails for operators

2014-05-17 Thread richard-gccbugzilla at metafoo dot co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21802

--- Comment #4 from Richard Smith  ---
EDG accepts this (which I believe is the correct answer). Clang and GCC reject
(in Clang's case, the callee is resolved in the template definition, but then
ADL is accidentally performed during template instantiation; I've not looked
into where this goes wrong for GCC). The bug seems valid to me.