[Bug c++/29143] address-of overloaded function does not work in function call

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org

--- Comment #8 from Paolo Carlini  ---
Fixed for 4.9.0.

[Bug c++/29143] address-of overloaded function does not work in function call

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Nov 16 09:54:42 2013
New Revision: 204899

URL: http://gcc.gnu.org/viewcvs?rev=204899&root=gcc&view=rev
Log:
/cp
2013-11-16  Paolo Carlini  

PR c++/29143
* semantics.c (finish_call_expr): Ensure that for OVERLOADs too
'(&f)(...)' is the same as '(f)(...)', per 13.3.1.1.

/testsuite
2013-11-16  Paolo Carlini  

PR c++/29143
* g++.dg/overload/addr2.C: New.
* g++.old-deja/g++.other/overload11.C: Adjust.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug c++/29143] address-of overloaded function does not work in function call

[paolo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29143

--- Comment #6 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sat Nov 16 09:54:23 2013
New Revision: 204898

URL: http://gcc.gnu.org/viewcvs?rev=204898&root=gcc&view=rev
Log:
/cp
2013-11-16  Paolo Carlini  

PR c++/29143
* semantics.c (finish_call_expr): Ensure that for OVERLOADs too
'(&f)(...)' is the same as '(f)(...)', per 13.3.1.1.

/testsuite
2013-11-16  Paolo Carlini  

PR c++/29143
* g++.dg/overload/addr2.C: New.
* g++.old-deja/g++.other/overload11.C: Adjust.

Added:
trunk/gcc/testsuite/g++.dg/overload/addr2.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.old-deja/g++.other/overload11.C

[Bug fortran/59143] [OOP] Bogus warning with array-valued type-bound procedure

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59143

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Early draft patch (fixes the test case but is not regtested yet):

Regtests cleanly.

[Bug c++/59151] New: gcc name lookup for friend template finds class outside of

[gafunchal at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59151

Bug ID: 59151
   Summary: gcc name lookup for friend template finds class
outside of
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gafunchal at gmail dot com

template
class Class1;

namespace B {
  template
  class Class2 {
template
friend class Class1;
  private:
int something_private;
  };
}

template
class Class1
{
  void error() {
B::Class2 b;
b.something_private = 42;
  }
};

I orignally thought this to be a clang bug, it seems to actually be a problem
in gcc incorrectly accepting this code.

Richard Smith mentions in http://llvm.org/bugs/show_bug.cgi?id=17950:

--8<--

7.3.1.2/3:

"If the name in a friend declaration is neither qualified nor a template-id and
the declaration is a function or an elaborated-type-specifier, the lookup to
determine whether the entity has been previously declared shall not consider
any scopes outside the innermost enclosing namespace."

Therefore a (not-yet-declared) 'template class B::Class1;' is
befriended, not the global Class1.

-->8--

So gcc should require replacing the friend declaration by:

template
friend class ::Class1;

[Bug middle-end/59134] Infinite loop between store_fixed_bit_field and store_split_bit_field with STRICT_ALIGNMENT

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59134

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
The cited testcase ICEs gcc 4.6/4.7/4.8/4.9 for me on sparc64-linux, another
STRICT_ALIGNMENT target.  gcc 4.5 and older don't ICE.

[Bug c++/59144] weird behavior when dealing with too complicated templates and class hierarchy

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59144

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to tmmikolajczyk from comment #0)
> > The compilation passes (on gcc and clang). It's quite weird that the
> > virtualism of the "X::bar" method has such an impact.
> 
> But that doesn't make it a bug.

The Intel compiler behaves the same.

[Bug middle-end/59152] New: [4.9 Regression] ICE: loop 2's latch does not have an edge to its header with -fopenmp -fipa-pure-const

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59152

Bug ID: 59152
   Summary: [4.9 Regression] ICE: loop 2's latch does not have an
edge to its header with -fopenmp -fipa-pure-const
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 31229
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31229&action=edit
reduced testcase

Compiler output:
$ gcc -fopenmp -fipa-pure-const testcase.c
testcase.c: In function 'foo._omp_fn.0':
testcase.c:10:1: error: loop 2's latch does not have an edge to its header
 }
 ^
testcase.c:10:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1649
0x70b713 verify_loop_structure()
/mnt/svn/gcc-trunk/gcc/cfgloop.c:1649
0x94fc5a loop_optimizer_init(unsigned int)
/mnt/svn/gcc-trunk/gcc/loop-init.c:111
0x12facc3 analyze_function
/mnt/svn/gcc-trunk/gcc/ipa-pure-const.c:781
0x12fb961 pure_const_generate_summary
/mnt/svn/gcc-trunk/gcc/ipa-pure-const.c:924
0x9dd246 execute_ipa_summary_passes(ipa_opt_pass_d*)
/mnt/svn/gcc-trunk/gcc/passes.c:2015
0x730265 ipa_passes
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2014
0x730265 compile()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2121
0x7304b4 finalize_compilation_unit()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2275
0x5e3c63 c_write_global_declarations()
/mnt/svn/gcc-trunk/gcc/c/c-decl.c:10374
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-204897-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-204897-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20131116 (experimental) (GCC) 

Tested revisions:
r204897 - crash
4.8 r204890 - OK

[Bug target/59153] New: ICE: in memory_address_length, at config/i386/i386.c:24617 with -O -flive-range-shrinkage -mdispatch-scheduler -march=bdver1

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59153

Bug ID: 59153
   Summary: ICE: in memory_address_length, at
config/i386/i386.c:24617 with -O
-flive-range-shrinkage -mdispatch-scheduler
-march=bdver1
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz

Created attachment 31230
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31230&action=edit
reduced testcase

Compiler output:
$ gcc -O -flive-range-shrinkage -mdispatch-scheduler -march=bdver1 testcase.c 
testcase.c: In function 'foo':
testcase.c:5:1: internal compiler error: in memory_address_length, at
config/i386/i386.c:24617
 }
 ^
0xd97f06 memory_address_length(rtx_def*, bool)
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:24617
0xdc4943 insn_default_length(rtx_def*)
/mnt/svn/gcc-trunk/gcc/config/i386/i386.md:631
0xd6dc30 min_insn_size
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:36340
0xd6ee2f add_to_dispatch_window
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:43215
0xd6ee2f do_dispatch
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:43381
0x12d1de3 schedule_block(basic_block_def**, void*)
/mnt/svn/gcc-trunk/gcc/haifa-sched.c:6262
0xa734a7 schedule_region
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3057
0xa734a7 schedule_insns
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3393
0xa7389b schedule_insns
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3378
0xa7389b rest_of_handle_live_range_shrinkage
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3587
0xa7389b execute
/mnt/svn/gcc-trunk/gcc/sched-rgn.c:3677
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gcc -v  
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-204897-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-204897-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20131116 (experimental) (GCC) 

Tested revisions:
r204897 - crash
4.8 - doesn't know -flive-range-shrinkage

[Bug c++/56820] elaborated-type-specifier friend incorrectly looked up beyond innermost enclosing namespace

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56820

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed.

namespace outer
{
  template struct B;

  namespace inner
  {
template class A
{
  template friend struct B;

  A() {}
};
  }

  template struct B
  {
B() { inner::A a; }
  };
}

outer::B b;


The friend declaration only matches outer::B when both A and B are class
templates. If either is a non-template then the friend declaration correctly
declares outer::inner::B.

[Bug c++/56820] elaborated-type-specifier friend incorrectly looked up beyond innermost enclosing namespace

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56820

Jonathan Wakely  changed:

   What|Removed |Added

 CC||gafunchal at gmail dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 59151 has been marked as a duplicate of this bug. ***

[Bug c++/59151] gcc name lookup for friend template finds class outside of enclosing namespace

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59151

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
Looks like a dup of PR 56820

*** This bug has been marked as a duplicate of bug 56820 ***

[Bug c++/59144] weird behavior when dealing with too complicated templates and class hierarchy

[tmmikolajczyk at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59144

--- Comment #3 from tmmikolajczyk at gmail dot com ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to tmmikolajczyk from comment #0)
> > The compilation passes (on gcc and clang). It's quite weird that the
> > virtualism of the "X::bar" method has such an impact.
> 
> But that doesn't make it a bug.

Why that's not a bug? No matter if the X::bar method is virtual or not it
should not have any impact on access to it from the derived classes in this
case IMHO.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[rainarchitect at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431

--- Comment #4 from George Galeev  ---
Guys, how to get a look at this bug? I'm tired of reading 100500 warnings from
third-party libraries.

GCC-4.6, GCC-4.7, GCC-4.8, C++11
Gentoo Linux x86-64

[Bug c/59138] [4.8/4.9 Regression] possible packed struct miscompile

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59138

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
Started with r191302, a fix for missed-optimization PR44194 "struct returned by
value generates useless stores".

[Bug lto/59154] New: [4.9 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59154

Bug ID: 59154
   Summary: [4.9 Regression] internal compiler error: tree check:
expected ssa_name, have integer_cst
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: areg.melikadamyan at gmail dot com

454.tonto in SPEC CPU 2006 failed to build with r204862

-O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin   

spacegroup.fppized.f90: In function 'analyse':
spacegroup.fppized.f90:1623:0: internal compiler error: tree check: expected
ssa_name, have integer_cst in simplify_conversion_from_bitmask, at
tree-ssa-forwprop.c:1186
subroutine analyse(self)
 ^
0xac44d4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src-trunk/gcc/tree.c:9168
0x9a510d tree_check
../../src-trunk/gcc/tree.h:2706
0x9a510d simplify_conversion_from_bitmask
../../src-trunk/gcc/tree-ssa-forwprop.c:1186
0x9ae126 ssa_forward_propagate_and_combine
../../src-trunk/gcc/tree-ssa-forwprop.c:3486
0x9ae126 execute
../../src-trunk/gcc/tree-ssa-forwprop.c:3593
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccYNDvfq.ltrans22.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [tonto] Error 1

spacegroup.fppized.f90: In function 'analyse':
spacegroup.fppized.f90:1623:0: internal compiler error: tree check: expected
ssa_name, have integer_cst in simplify_conversion_from_bitmask, at
tree-ssa-forwprop.c:1186
subroutine analyse(self)
 ^
0xac44d4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src-trunk/gcc/tree.c:9168
0x9a510d tree_check
../../src-trunk/gcc/tree.h:2706
0x9a510d simplify_conversion_from_bitmask
../../src-trunk/gcc/tree-ssa-forwprop.c:1186
0x9ae126 ssa_forward_propagate_and_combine
../../src-trunk/gcc/tree-ssa-forwprop.c:3486
0x9ae126 execute
../../src-trunk/gcc/tree-ssa-forwprop.c:3593
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccYNDvfq.ltrans22.ltrans.o] Error 1
lto-wrapper: make returned 2 exit status
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake[3]: *** [tonto] Error 1

[Bug lto/59154] [4.9 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59154

--- Comment #1 from H.J. Lu  ---
It is 465.tonto.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Manuel López-Ibáñez  ---
The C++ parser lexes (and preprocesses) before handling the pragmas, whereas
the C parser processes the pragmas as it sees them.

We must somehow parse these pragmas *also* in cp/parser.c:631. Maybe one can do
something similar to what we do for cp_parser_initial_pragma, but within the
loop and only handling pragma diagnostic. Surely, it will need some trial and
error to get it right. If any of you wants to give it a try and need some help,
just ask here or in the mailing list.

[Bug tree-optimization/59139] [4.7/4.8/4.9 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59139

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson  ---
Started with r173612.

[Bug c++/47347] "pragma GCC diagnostic ignored" has no effect for templates

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47347

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
  Known to work||4.6.0
 Resolution|--- |FIXED
Summary|"pragma GCC diagnostic  |"pragma GCC diagnostic
   |ignored" has no effect  |ignored" has no effect for
   |sometimes   |templates

--- Comment #2 from Manuel López-Ibáñez  ---
It works for me in GCC 4.9.

I think this was fixed when we introduce the push/pop pragmas. Now we store the
ranges forever, so it doesn't matter when the warning is given, only that the
location of the warning is the correct one.

[Bug inline-asm/59155] New: ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155

Bug ID: 59155
   Summary: ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
Target: x86_64-unknown-linux-gnu

double f(double x){
  asm volatile("":"+X"(x));
  return x;
}
double g(double x,double y){
  return f(f(x)+f(y));
}

compiled with -O2:

a.c: In function 'g':
a.c:7:1: internal compiler error: in reg_overlap_mentioned_p, at rtlanal.c:1473
 }
 ^
0x967015 reg_overlap_mentioned_p(rtx_def const*, rtx_def const*)
/data/repos/gcc/pristine/gcc/rtlanal.c:1473
0x7cde02 match_asm_constraints_1
/data/repos/gcc/pristine/gcc/function.c:7164
0x7cdfda rest_of_match_asm_constraints
/data/repos/gcc/pristine/gcc/function.c:7207
0x7cdfda execute
/data/repos/gcc/pristine/gcc/function.c:7239
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/59156] New: code miscompiled with -O2 -fpeel-loops

[mjt+gcc at tls dot msk.ru]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59156

Bug ID: 59156
   Summary: code miscompiled with -O2 -fpeel-loops
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjt+gcc at tls dot msk.ru

Created attachment 31231
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31231&action=edit
code demonstrating the issue

Attached is a code which shows different results when compiled with -O2 (wrong)
or -O1 (right).  Initially it was -O2 -funroll-loops which triggered the issue,
but after reducing the code further I managed to get the same result with -O1
vs -O2 without any additional options.

Tested with debian gcc 4.7.2-5 x86-65 (wheezy), confirmed with 4.8.1-10
(debian/testing, also 64bits).  32bit code is not affected.

The code does not have any preprocessor directives.

I tried to reduce it further but it is a bit fragile - for example, removing a
single call to free() makes the code generated to be correct.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||scottbaldwin at gmail dot com

--- Comment #6 from Manuel López-Ibáñez  ---
*** Bug 57241 has been marked as a duplicate of this bug. ***

[Bug inline-asm/59157] New: "+f" constraint rejected: output constraint 0 must specify a single register

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59157

Bug ID: 59157
   Summary: "+f" constraint rejected: output constraint 0 must
specify a single register
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
Target: x86_64-unknown-linux-gnu

double f(double x){
  asm volatile("":"+f"(x));
  return x;
}

a.c: In function 'f':
a.c:2:3: error: output constraint 0 must specify a single register
   asm volatile("":"+f"(x));
   ^

If I use "+mf", it is accepted with -m64 but still fails with -m32.

[Bug c++/57241] -Wmultichar warnings despite a #pragma diagnostic ignored -Wmultichar directive

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57241

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #4)
> 
> Doesn't CPP diagnostics pass through the pragma classify code in
> diagnostic.c even when tokenizing ahead of time? If so, I don't understand
> why the warning is not suppressed. I don't have time to investigate it
> myself, but I don't see why that would be the problem here.

So answering to myself: No, it doesn't (see PR53431). I think it must.

This affects all the controllable warnings from CPP when using g++.

*** This bug has been marked as a duplicate of bug 53431 ***

[Bug c/59156] code miscompiled with -O2 -fpeel-loops

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59156

--- Comment #1 from Andrew Pinski  ---
-fno-strict-aliasing fixes it.

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-16
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  ---
The C FE normally preprocesses and parses concurrently. But -E (only
preprocessing) is handled by a different function in
c-ppoutput.c(scan_translation_unit), which does not handle pragma diagnostics.
So someone would need to add that handling there. Probably not difficult. I
think one just needs to call c_invoke_pragma handler when a pragma diagnostic
is detected, but someone has to try and flush out the details. If you need help
just ask.

[Bug c++/48914] #pragma GCC diagnostic ignored "-Wc++0x-compat" doesn't work

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914

--- Comment #9 from Manuel López-Ibáñez  ---
If this warning is given by the preprocessor during lexing, then this is a dup
of bug 53431.

[Bug lto/59154] [4.9 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst

[hjl.tools at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59154

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-16
 CC||jakub at redhat dot com
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #2 from H.J. Lu  ---
It is caused by r203979.

[Bug preprocessor/54694] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[valentin.ilie at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

Valentin Ilie  changed:

   What|Removed |Added

 CC||valentin.ilie at gmail dot com

--- Comment #7 from Valentin Ilie  ---
I can reproduce this issue with gcc-4.8

[Bug fortran/58771] [4.7/4.8/4.9 Regression] ICE in transfer_expr, at fortran/trans-io.c:2164

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58771

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Sat Nov 16 21:44:56 2013
New Revision: 204907

URL: http://gcc.gnu.org/viewcvs?rev=204907&root=gcc&view=rev
Log:
2013-11-16  Paul Thomas  

PR fortran/58771
* trans-io.c (transfer_expr): If the backend_decl for a derived
type is missing, build it with gfc_typenode_for_spec.

2013-11-16  Paul Thomas  

PR fortran/58771
* gfortran.dg/derived_external_function_1.f90 : New test

Added:
   
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/derived_external_function_1.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/trans-io.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug inline-asm/59155] ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155

--- Comment #1 from Marc Glisse  ---
By the way, the following:

double f(double x){
  asm volatile("":"+X"(x));
  return x;
}
double g(){
  return f(1.);
}

is rejected with:

c.c: In function 'g':
c.c:2:3: error: inconsistent operand constraints in an 'asm'
   asm volatile("":"+X"(x));
   ^

[Bug target/59142] internal compiler error while compiling OpenCV 2.4.7

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59142

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |4.8.3

--- Comment #2 from Andrew Pinski  ---
Works in 4.7.0.  I notice you are using Ubuntu's compiler you really should
have reported it there.

[Bug target/59137] [4.7/4.8/4.9 Regression] Miscompilation at -O1 on mips/mipsel

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59137

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-11-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I can reproduce it in 4.7.0, though I need to use -march=mips64 as my compiler
defaults to -march=octeon and the scheduling is different.

[Bug rtl-optimization/59137] [4.7/4.8/4.9 Regression] Miscompilation at -O1 on mips/mipsel

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59137

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #2 from Andrew Pinski  ---
The first difference between -march=mips64 and -march=octeon shows up in ce1
(ifcvt.c).

[Bug fortran/58099] [4.8/4.9 Regression] [F03] over-zealous procedure-pointer error checking

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58099

--- Comment #23 from janus at gcc dot gnu.org ---
Author: janus
Date: Sat Nov 16 23:13:31 2013
New Revision: 204908

URL: http://gcc.gnu.org/viewcvs?rev=204908&root=gcc&view=rev
Log:
2013-11-16  Janus Weil  

Backport from mainline
2013-09-20  Janus Weil  

PR fortran/58099
* expr.c (gfc_check_pointer_assign): Remove second call to
'gfc_compare_interfaces' with swapped arguments.
* interface.c (gfc_compare_interfaces): Symmetrize the call to
'check_result_characteristics' by calling it with swapped arguments.


2013-11-16  Janus Weil  

Backport from mainline
2013-09-20  Janus Weil  

PR fortran/58099
* gfortran.dg/proc_ptr_43.f90: New.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/proc_ptr_43.f90
  - copied unchanged from r202766,
trunk/gcc/testsuite/gfortran.dg/proc_ptr_43.f90
Modified:
branches/gcc-4_8-branch/   (props changed)
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/expr.c
branches/gcc-4_8-branch/gcc/fortran/interface.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-4_8-branch/
('svn:mergeinfo' modified)

[Bug target/59142] internal compiler error while compiling OpenCV 2.4.7

[joao.m.santos.silva at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59142

--- Comment #3 from João M. S. Silva  ---
OK, thanks, I will report in Ubuntu's.

The compiler says:

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1

Should I report also in Linaro's? I'm not yet familiarized with Linaro's role
in gcc.

[Bug libffi/34311] libffi.call/nested_struct5.c execution tests fail under darwin9 on powerpc

[green at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34311

--- Comment #3 from Anthony Green  ---
(In reply to Iain Sandoe from comment #2)
> However, there is no guarantee in the Darwin m32 ABI that the stacked
> version of the structs will be appropriately aligned.   So, either the
> testcase is wrong code - or the process for passing structures in the
> closure needs to be refined (significant re-write, since the structs are
> currently passed in-place).

Iain - could you please explain this a little more?  Which are the stacked
structs that aren't aligned, and where do they come from?

Thanks!

AG

[Bug c++/59158] New: stdcall function as template parameter cause assembler error

[741911404 at qq dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59158

Bug ID: 59158
   Summary: stdcall function as template parameter cause assembler
error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 741911404 at qq dot com

a.cpp:
void __attribute((stdcall))f1(){}
void f2(){}
template
void f(F f){f();}
int main(){
f(f1);
f(f2);
}

command:
i686-pc-linux-gnu-g++-4.8.2 -Wall -Wextra a.cpp

result:
/tmp/ccWimXXE.s: Assembler messages:
/tmp/ccWimXXE.s:84: Error: symbol `_Z1fIPFvvEEvT_' is already defined

[Bug target/59158] stdcall function as template parameter cause assembler error

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59158

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c++ |target
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 44282.

*** This bug has been marked as a duplicate of bug 44282 ***

[Bug c++/44282] fastcall is not mangled at all

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44282

Andrew Pinski  changed:

   What|Removed |Added

 CC||741911404 at qq dot com

--- Comment #6 from Andrew Pinski  ---
*** Bug 59158 has been marked as a duplicate of this bug. ***