[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66464
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-06-09
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Leo Carreon from comment #0)
I just noticed that codecvt_utf16char32_t::max_length() is returning 3.
This appears to be the wrong value because a surrogate pair is composed of 4
bytes therefore max_length() should at least be returning 4.
Agreed, I think that's just a mistake.
I wrote this comment in the code:
int
codecvtchar16_t, char, mbstate_t::do_max_length() const throw()
{
// Any valid UTF-8 sequence of 3 bytes fits in a single 16-bit code unit,
// whereas 4 byte sequences require two 16-bit code units.
return 3;
}
But that reasoning (even if it's correct!) doesn't apply to
codecvt_utf16char32_t.
I'm also wondering whether the BOM should be taken into account. If it so
happens that at the beginning of a UTF-16 string which has a BOM and it so
happens to start with a surrogate pair, 6 bytes have to be consumed to
generate a single UCS-4 character.
Should the same thing be considered with
codecvt_utf8char32_t::max_length() which currently returns 4. Taking into
account the BOM and the longest UTF-8 character below 0x10, shouldn't
max_length() return 7.
I'm not really sure if the BOM should be taken into account because the
standard's definition for do_max_length() simply says the maximum number of
input characters that needs to be consumed to generate a single output
character.
That's a very good question.
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45780 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- I think -Wbool-arith makes sense as a separate option. While -Wc90-c99-compat warns about any use of bool (in a declaration, cast, ...), -Wbool-arith would only warn about suspicious uses of boolean vars.
[Bug c++/57709] -Wshadow is too strict / has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709
Gael Guennebaud gael.guennebaud at gmail dot com changed:
What|Removed |Added
CC||gael.guennebaud at gmail dot
com
--- Comment #15 from Gael Guennebaud gael.guennebaud at gmail dot com ---
-Wshadow still trigger false positive when a base member functions is imported
with the using keyword, as in the following example (tested with gcc 5.1):
templatetypename T struct BaseClass {
BaseClass(int size) : m_size(size) {}
int size() { return m_size; }
int m_size;
};
templatetypename T struct Foo : BaseClassT {
typedef BaseClassT Base;
Foo(int size) : Base(size) {}
using Base::size;
};
$ g++-mp-5 gcc_shadow.cpp -c -Wshadow
gcc_shadow.cpp: In constructor 'FooT::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'FooT' [-Wshadow]
Foo(int size) : Base(size) {}
^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
using Base::size;
Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported size symbol is a function and not a
variable.
[Bug c++/57709] -Wshadow is too strict / has false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709 --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Gael Guennebaud from comment #15) -Wshadow still trigger false positive when a base member functions is imported with the using keyword, as in the following example (tested with gcc 5.1): Please open a new PR. This one is fixed. Note that clang does not warn in this case, so it should be possible to figure out that in this case, the imported size symbol is a function and not a variable. Sure, probably TREE_CODE (member) != FUNCTION_DECL but there must be a way to check that it does represent a function_decl (or member-function). Run gcc under gdb in your testcase and break at the call to warning_at and use p debug_tree(member) to understand what member is in your testcase.
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35724 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35724action=edit gcc6-pr66470.patch Untested fix.
[Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 9 07:51:24 2015 New Revision: 224266 URL: https://gcc.gnu.org/viewcvs?rev=224266root=gccview=rev Log: 2015-06-09 Richard Biener rguent...@suse.de PR tree-optimization/66396 * graphite-isl-ast-to-gimple.c (graphite_regenerate_ast_isl): Rename virtual operands. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-isl-ast-to-gimple.c
[Bug tree-optimization/66413] [6 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66413 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 9 08:06:17 2015 New Revision: 224267 URL: https://gcc.gnu.org/viewcvs?rev=224267root=gccview=rev Log: 2015-06-09 Richard Biener rguent...@suse.de PR middle-end/66413 * tree-inline.c (insert_init_debug_bind): Unshare value. * gcc.dg/torture/pr66413.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr66413.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66419 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Created attachment 35718
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35718action=edit
Tentative patch for issue #3
The patch does not fix the
../../work/gcc/ipa-pure-const.c:1636:1: error:
'{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)' defined
but not used [-Werror=unused-function]
issue.
[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jun 9 08:50:00 2015 New Revision: 224273 URL: https://gcc.gnu.org/viewcvs?rev=224273root=gccview=rev Log: PR libstdc++/66030 * config/abi/pre/gnu.ver: Export codecvt_byname and codecvt symbols for mingw32. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug target/66470] New: [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470
Bug ID: 66470
Summary: [4.8/4.9/5/6 Regression] TLS ICE due to
ix86_split_long_move
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
extern __thread unsigned long long a[10];
unsigned long long foo (int b) { return a[b]; }
or
extern __thread struct S { int a, b; } a[10];
struct S foo (int b) { return a[b]; }
ICE on x86_64-linux/i686-linux with -m32, all optimization levels. This worked
in GCC 3.3.6.
The bug is in ix86_split_long_move, when trying to split:
(insn 7 15 13 2 (set (reg:DI 0 ax [92])
(mem:DI (plus:SI (plus:SI (mult:SI (reg/v:SI 1 dx [orig:89 b ] [89])
(const_int 8 [0x8]))
(unspec:SI [
(const_int 0 [0])
] UNSPEC_TP))
(reg:SI 0 ax [91])) [1 a S8 A64])) rh1212265.i:2 85
{*movdi_internal}
(nil))
which, while offsettable, has collisions == 2 (the MEM uses both dx and ax in
the addressing and loads the ax:dx pair). The splitter assumes it can just use
a lea, but lea can't support %gs: (UNSPEC_TP). So, either it has to load from
%gs:0 first, then do lea, or better yet just move UNSPEC_TP part to the
individual memory loads.
[Bug c++/66467] [6 Regression] ICE: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66467 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think this is a dup of PR65882. A patch for that one was posted: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01558.html.
[Bug c++/66467] [6 Regression] ICE: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66467 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) I think this is a dup of PR65882. A patch for that one was posted: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01558.html. Thanks. The patch fixes the issue. *** This bug has been marked as a duplicate of bug 65882 ***
[Bug c++/65882] [5/6 Regression] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 66467 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/66419] [6 regression] FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution, -O3 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66419 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 9 08:22:20 2015 New Revision: 224271 URL: https://gcc.gnu.org/viewcvs?rev=224271root=gccview=rev Log: 2015-06-09 Richard Biener rguent...@suse.de PR tree-optimization/66419 * tree-vect-slp.c (vect_supported_load_permutation_p): Properly consider GROUP_GAP when detecting a perfect subchain. * gcc.dg/vect/bb-slp-37.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/bb-slp-37.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/48052] loop not vectorized if index is unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 Bug 48052 depends on bug 66396, which changed state. Bug 66396 Summary: [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/66422] [5 Regression] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66422 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Summary|[5/6 Regression]|[5 Regression] |-Warray-bounds false|-Warray-bounds false |positive with -O3 |positive with -O3 Known to fail||5.1.0 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 --- Comment #3 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #2) The testcase is invalid: markus@x4 testc % g++ -r -nostdlib a.ii c.ii e.ii -g -O2 -flto a.ii:21:8: warning: ‘Run’ violates the C++ One Definition Rule [-Wodr] void Run (Point ) const; ^ e.ii:25:1: note: return value type mismatch Optimizer::Run (Point ) const ^ e.ii:25:1: note: type ‘float’ should match type ‘void’ e.ii:25:1: note: ‘Run’ was previously declared here e.ii: In member function ‘__base_dtor ’: e.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712 } ^ You are right. However, I guess we should not ICE? Martin
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-06-09
Ever confirmed|0 |1
--- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Yeah. It is also easily fixed:
markus@x4 testc % cat 1.ii
namespace std
{
template typename class allocator;
template typename _Tp, typename = allocator_Tp class vector
{
public:
~vector () {}
};
vectorunsigned b;
}
template typename _Tp class A
{
public:
typedef _Tp reference;
};
template typename _Tp, typename _Alloc = A_Tp class B
{
public:
typename _Alloc::reference operator[](int);
};
namespace MosesTuning
{
class Point
{
};
class Optimizer
{
public:
float Run (Point ) const;
};
}
using namespace MosesTuning;
class C
{
public:
C (Point) { m_optimizer.Run (m_point); }
Optimizer m_optimizer;
Point m_point;
};
main ()
{
BPoint a;
(C (a[0]));
}
markus@x4 testc % cat 2.ii
namespace std
{
template typename class allocator;
struct _Vector_base
{
~_Vector_base ();
};
template typename _Tp, typename = allocator_Tp class vector : _Vector_base
{
};
}
namespace MosesTuning
{
class Point;
class Optimizer
{
float Run (Point ) const;
};
}
using namespace std;
namespace MosesTuning
{
float
Optimizer::Run (Point ) const
{
vectorunsigned a;
}
}
markus@x4 testc % /var/tmp/gcc_test/usr/local/bin/g++ -r -nostdlib 1.ii 2.ii -g
-O2 -flto
2.ii: In member function ‘__base_dtor ’:
2.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712
[Bug target/66469] New: config/rl78/rl78.c:679: possible bad array index ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469 Bug ID: 66469 Summary: config/rl78/rl78.c:679: possible bad array index ? Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- [trunk/gcc/config/rl78/rl78.c:679]: (style) Array index 'regno' is used before limits check. if (!crtl-is_leaf call_used_regs[regno] regno 22) Possible minor tidy up to put the sanity check before the use.
[Bug target/61074] internal compiler error: in extract_insn, at recog.c:2109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61074 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Feedback not coming.
[Bug tree-optimization/66413] [4.8/4.9/5 Regression] ICE at -Os and above with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66413 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||6.0 Target Milestone|6.0 |4.8.5 Summary|[6 Regression] ICE at -Os |[4.8/4.9/5 Regression] ICE |and above with -g enabled |at -Os and above with -g |on x86_64-linux-gnu |enabled on x86_64-linux-gnu --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk - I'm going to schedule this for a backport as such issues can cause strange GC related issues. It should be latent everywhere.
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- The testcase is invalid: markus@x4 testc % g++ -r -nostdlib a.ii c.ii e.ii -g -O2 -flto a.ii:21:8: warning: ‘Run’ violates the C++ One Definition Rule [-Wodr] void Run (Point ) const; ^ e.ii:25:1: note: return value type mismatch Optimizer::Run (Point ) const ^ e.ii:25:1: note: type ‘float’ should match type ‘void’ e.ii:25:1: note: ‘Run’ was previously declared here e.ii: In member function ‘__base_dtor ’: e.ii:28:1: internal compiler error: in check_die, at dwarf2out.c:5712 } ^
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #10 from Aldy Hernandez aldyh at redhat dot com ---
It's not supposed to. It's for issue three as stated.
On Jun 9, 2015 4:36 AM, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org
wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Created attachment 35718
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35718action=edit
Tentative patch for issue #3
The patch does not fix the
../../work/gcc/ipa-pure-const.c:1636:1: error:
'{anonymous}::pass_ipa_pure_const::pass_ipa_pure_const(gcc::context*)'
defined
but not used [-Werror=unused-function]
issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 --- Comment #11 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Aldy Hernandez from comment #10) It's not supposed to. It's for issue three as stated. indeed; state as of now is that (with both proposed patches in place and --disable-werror), the multiple DWARF entity ld64 warnings are gone from my bootstrap log. The test suite is running - was going to wait to report until that's done …
[Bug c++/33661] template methods forget explicit local reg vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33661 --- Comment #13 from Andreas Krebbel krebbel at gcc dot gnu.org --- Created attachment 35723 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35723action=edit Experimental fix The attached patch fixes the problem for me. There appear to be two problems: 1. When parsing a template function cp_finish_decl returns before the asmspec is set in a var decl. 2. When expanding the template function the assembler_name is zeroed out.
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #37 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
The patch severely breaks on SPARC though:
int foo (char c)
{
return (int) c;
}
eric@polaris:~/build/gcc/sparc-sun-solaris2.10 gcc/xgcc -Bgcc -S -O t.c
t.c: In function 'foo':
t.c:1:5: internal compiler error: in assign_parm_setup_reg, at function.c:3120
int foo (char c)
^
0xa335d0 assign_parm_setup_reg
/home/eric/svn/gcc/gcc/function.c:3120
0xa3660f assign_parms
/home/eric/svn/gcc/gcc/function.c:3778
0xa3a9fd expand_function_start(tree_node*)
/home/eric/svn/gcc/gcc/function.c:5215
0x838716 execute
/home/eric/svn/gcc/gcc/cfgexpand.c:6127
Please submit a full bug report,
[Bug target/66470] [4.8/4.9/5/6 Regression] TLS ICE due to ix86_split_long_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66470 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.5
[Bug bootstrap/66471] New: BITMAP is a reserved keyword on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66471
Bug ID: 66471
Summary: BITMAP is a reserved keyword on MinGW
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ismail at donmez dot ws
Target Milestone: ---
gcc/mem-stats-traits.h has:
/* Memory allocation origin. */
enum mem_alloc_origin
{
HASH_TABLE,
HASH_MAP,
HASH_SET,
VEC,
BITMAP,
GGC,
ALLOC_POOL,
MEM_ALLOC_ORIGIN_LENGTH
};
and this fails to compile on mingw-w64 with:
In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71:0,
from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/wingdi.h:467:5: error: 'typedef
struct tagBITMAP BITMAP' redeclared as different kind of symbol
} BITMAP,*PBITMAP,*NPBITMAP,*LPBITMAP;
^
In file included from ../../combined-6.0.0/gcc/hash-table.h:204:0,
from ../../combined-6.0.0/gcc/coretypes.h:310,
from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:22:
../../combined-6.0.0/gcc/mem-stats-traits.h:11:3: note: previous declaration
'mem_alloc_origin BITMAP'
BITMAP,
^
In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71:0,
from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/wingdi.h:2688:55: error:
'BITMAP' does not name a type
WINGDIAPI HBITMAP WINAPI CreateBitmapIndirect(CONST BITMAP *pbm);
^
In file included from
/usr/x86_64-w64-mingw32/sys-root/mingw/include/windows.h:71:0,
from ../../combined-6.0.0/gcc/config/i386/host-mingw32.c:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/wingdi.h:3218:5: error: 'BITMAP'
does not name a type
BITMAP dsBm;
^
../../combined-6.0.0/gcc/config/i386/x-mingw32:30: recipe for target
'host-mingw32.o' failed
Renaming BITMAP enum should ne enough.
[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66471 --- Comment #1 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35725 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35725action=edit Patch May I ask you for testing the patch? Thanks, Martin
[Bug c++/66472] New: -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
Bug ID: 66472
Summary: -Wshadow gets confused by using statements in template
classes
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gael.guennebaud at gmail dot com
Target Milestone: ---
This is a followup to bug 57709 that disabled shadow warnings between variables
and class functions. However, -Wshadow still trigger false positive when a base
member functions is imported with the using keyword, as in the following
example (tested with gcc 5.1):
templatetypename T struct BaseClass {
BaseClass(int size) : m_size(size) {}
int size() { return m_size; }
int m_size;
};
templatetypename T struct Foo : BaseClassT {
typedef BaseClassT Base;
Foo(int size) : Base(size) {}
using Base::size;
};
$ g++-mp-5 gcc_shadow.cpp -c -Wshadow
gcc_shadow.cpp: In constructor 'FooT::Foo(int)':
gcc_shadow.cpp:9:17: warning: declaration of 'size' shadows a member of
'FooT' [-Wshadow]
Foo(int size) : Base(size) {}
^
gcc_shadow.cpp:10:15: note: shadowed declaration is here
using Base::size;
Note that clang does not warn in this case, so it should be possible to figure
out that in this case, the imported size symbol is a function and not a
variable.
As suggested there https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57709#c16, I
tried to break at the call to warning_at to give you more input, but with no
luck, as if warning_at was not called at all. (I also tried to break at any
*warning* symbol with same result).
[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66471 --- Comment #2 from İsmail Dönmez ismail at donmez dot ws --- (In reply to Martin Liška from comment #1) Created attachment 35725 [details] Patch May I ask you for testing the patch? Fixes the bootstrap for me, thanks.
[Bug bootstrap/66471] BITMAP is a reserved keyword on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66471 --- Comment #3 from Martin Liška marxin at gcc dot gnu.org --- (In reply to İsmail Dönmez from comment #2) (In reply to Martin Liška from comment #1) Created attachment 35725 [details] Patch May I ask you for testing the patch? Fixes the bootstrap for me, thanks. Thanks for testing, I am going to re-spin my regression tests and I'm going to send the patch to ML. Martin
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #11) (In reply to Aldy Hernandez from comment #10) It's not supposed to. It's for issue three as stated. The test suite is running - was going to wait to report until that's done … NOTE: I have bootstrapped and tested c,c++,objc,objc++,fortran,ada,lto - but NOT Java. So .. things are *very* much improved, thanks! (at least no reports during bootstrap), but there's still quite a bit of fallout in the testsuite (many more failing tests than listed below, these are just examples): FAIL: gcc.c-torture/execute/20020412-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/20040308-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/20070919-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr8081.c -O3 -g (test for excess errors) etc (usually several) instances of: warning: invalid DWARF generated by the compiler: DIE 0x018b has multiple AT_decl_file attributes in '/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccSyKR0x.o'. warning: invalid DWARF generated by the compiler: DIE 0x015d has multiple AT_decl_line attributes in '/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//kVUY.o'. FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c -g (test for excess errors) FAIL: c-c++-common/cilk-plus/CK/cilk-fors.c -g (test for excess errors) FAIL: c-c++-common/cilk-plus/CK/cilk_for_grain.c -g (test for excess errors) FAIL: c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c -g (test for excess errors) FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c -g (test for excess errors) etc also plugin tests. (many) instances of: warning: invalid DWARF generated by the compiler: DIE 0x0176 has multiple AT_artificial attributes in '/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccNJ6qak.o'. === looks like c++ only has fails of the form: has multiple AT_artificial attributes = no errors of this kind recorded in acats = gnat has all three forms = fortran seems to have only: AT_artificial attributes == target lib tests seem dominated by has multiple AT_artificial attributes (I didn't see any other cases in a quick grep)
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 --- Comment #1 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35722 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35722action=edit Build script
[Bug debug/66468] New: [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 Bug ID: 66468 Summary: [6 Regression] ICE in in check_die, at dwarf2out.c:5719 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 35721 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35721action=edit Source files Hello. Starting from Aldy's merge of debug-early branch (r224161) I see following ICE: c.ii:12:5: internal compiler error: in check_die, at dwarf2out.c:5719 } ^ 0x809612 check_die ../../gcc/dwarf2out.c:5715 0x82bcc0 dwarf2out_decl ../../gcc/dwarf2out.c:21886 0x82bcdd dwarf2out_function_decl ../../gcc/dwarf2out.c:21894 0x89df28 rest_of_handle_final ../../gcc/final.c:4505 0x89e094 execute ../../gcc/final.c:4547 Reproduction: ./build.sh Thanks, Martin
[Bug c++/66467] New: [6 Regression] ICE: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66467
Bug ID: 66467
Summary: [6 Regression] ICE: Error reporting routines
re-entered.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 tools % cat test.ii
template bool struct A { typedef int type; };
struct B {
static const int value = 0;
};
template class struct C { typedef int type; };
template class struct F : B {};
class D {
template class Expr
typename AFtypename CExpr::type::value || B::value::type
operator=(Expr);
};
void fn1() {
D opt;
opt = 0;
}
trippels@gcc2-power8 tools % g++ -c test.ii
‘
Internal compiler error: Error reporting routines re-entered.
0x10438cbf warn_logical_operator(unsigned int, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*)
../../gcc/gcc/c-family/c-common.c:1848
0x1018967f build_new_op_1
../../gcc/gcc/cp/call.c:5669
0x1018a58f build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/gcc/cp/call.c:5738
0x1030af83 build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
../../gcc/gcc/cp/typeck.c:3811
0x10218eef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14776
0x101f667b tsubst_expr
../../gcc/gcc/cp/pt.c:14398
0x1020b22f tsubst_template_arg
../../gcc/gcc/cp/pt.c:9684
0x10204cbb tsubst_template_args
../../gcc/gcc/cp/pt.c:10246
0x1020e423 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10443
0x1020826b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12412
0x10298287 dump_template_bindings
../../gcc/gcc/cp/error.c:353
0x10298287 dump_substitution
../../gcc/gcc/cp/error.c:1432
0x102a911b decl_to_string
../../gcc/gcc/cp/error.c:2894
0x102a911b cp_printer
../../gcc/gcc/cp/error.c:3475
0x111a3393 pp_format(pretty_printer*, text_info*)
../../gcc/gcc/pretty-print.c:613
0x1119fa13 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/gcc/diagnostic.c:916
0x111a051f error(char const*, ...)
../../gcc/gcc/diagnostic.c:1187
0x1016d07f enforce_access(tree_node*, tree_node*, tree_node*, int)
../../gcc/gcc/cp/call.c:6049
0x10365b03 perform_or_defer_access_check(tree_node*, tree_node*, tree_node*,
int)
../../gcc/gcc/cp/semantics.c:343
0x10173bcf build_over_call
../../gcc/gcc/cp/call.c:7139
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.
[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200 --- Comment #4 from Sharad Singhai singhai at gcc dot gnu.org --- Author: singhai Date: Tue Jun 9 06:45:43 2015 New Revision: 224265 URL: https://gcc.gnu.org/viewcvs?rev=224265root=gccview=rev Log: Backport r224118 from trunk for Google ref b/20542176 and b/20766120. Remove TARGET_RELAXED_ORDERING and optimize for weak memory models. This patch removes the special casing for targets with relaxed memory ordering and handles guard accesses with equivalent atomic load acquire operations. In this process we change the algorithm to load the guard variable with an atomic load that has ACQUIRE semantics. This then means that on targets which have weak memory models, the fast path is inlined and can directly use a load-acquire instruction where available (and yay! one more hook gone). 2015-06-04 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR c++/66192 PR target/66200 * doc/tm.texi: Regenerate. * doc/tm.texi.in (TARGET_RELAXED_ORDERING): Delete. * target.def (TARGET_RELAXED_ORDERING): Likewise. * config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise. * config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise. * config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise. * config/sparc/linux.h (SPARC_RELAXED_ORDERING): Likewise. * config/sparc/linux64.h (SPARC_RELAXED_ORDERING): Likewise. * config/sparc/sparc.c (TARGET_RELAXED_ORDERING): Likewise. * config/sparc/sparc.h (SPARC_RELAXED_ORDERING): Likewise. * system.h (TARGET_RELAXED_ORDERING): Poison. 2015-06-04 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR c++/66192 PR target/66200 * cp-tree.h (get_guard_cond): Adjust declaration * decl.c (expand_static_init): Use atomic load acquire and adjust call to get_guard_cond. * decl2.c (build_atomic_load_byte): New function. (get_guard_cond): Handle thread_safety. (one_static_initialization_or_destruction): Adjust call to get_guard_cond. Modified: branches/google/gcc-4_9/gcc/config/alpha/alpha.c branches/google/gcc-4_9/gcc/config/ia64/ia64.c branches/google/gcc-4_9/gcc/config/rs6000/rs6000.c branches/google/gcc-4_9/gcc/config/sparc/linux.h branches/google/gcc-4_9/gcc/config/sparc/linux64.h branches/google/gcc-4_9/gcc/config/sparc/sparc.c branches/google/gcc-4_9/gcc/config/sparc/sparc.h branches/google/gcc-4_9/gcc/cp/cp-tree.h branches/google/gcc-4_9/gcc/cp/decl.c branches/google/gcc-4_9/gcc/cp/decl2.c branches/google/gcc-4_9/gcc/doc/tm.texi branches/google/gcc-4_9/gcc/doc/tm.texi.in branches/google/gcc-4_9/gcc/system.h branches/google/gcc-4_9/gcc/target.def
[Bug c++/66192] C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192 --- Comment #3 from Sharad Singhai singhai at gcc dot gnu.org --- Author: singhai Date: Tue Jun 9 06:45:43 2015 New Revision: 224265 URL: https://gcc.gnu.org/viewcvs?rev=224265root=gccview=rev Log: Backport r224118 from trunk for Google ref b/20542176 and b/20766120. Remove TARGET_RELAXED_ORDERING and optimize for weak memory models. This patch removes the special casing for targets with relaxed memory ordering and handles guard accesses with equivalent atomic load acquire operations. In this process we change the algorithm to load the guard variable with an atomic load that has ACQUIRE semantics. This then means that on targets which have weak memory models, the fast path is inlined and can directly use a load-acquire instruction where available (and yay! one more hook gone). 2015-06-04 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR c++/66192 PR target/66200 * doc/tm.texi: Regenerate. * doc/tm.texi.in (TARGET_RELAXED_ORDERING): Delete. * target.def (TARGET_RELAXED_ORDERING): Likewise. * config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise. * config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise. * config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise. * config/sparc/linux.h (SPARC_RELAXED_ORDERING): Likewise. * config/sparc/linux64.h (SPARC_RELAXED_ORDERING): Likewise. * config/sparc/sparc.c (TARGET_RELAXED_ORDERING): Likewise. * config/sparc/sparc.h (SPARC_RELAXED_ORDERING): Likewise. * system.h (TARGET_RELAXED_ORDERING): Poison. 2015-06-04 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR c++/66192 PR target/66200 * cp-tree.h (get_guard_cond): Adjust declaration * decl.c (expand_static_init): Use atomic load acquire and adjust call to get_guard_cond. * decl2.c (build_atomic_load_byte): New function. (get_guard_cond): Handle thread_safety. (one_static_initialization_or_destruction): Adjust call to get_guard_cond. Modified: branches/google/gcc-4_9/gcc/config/alpha/alpha.c branches/google/gcc-4_9/gcc/config/ia64/ia64.c branches/google/gcc-4_9/gcc/config/rs6000/rs6000.c branches/google/gcc-4_9/gcc/config/sparc/linux.h branches/google/gcc-4_9/gcc/config/sparc/linux64.h branches/google/gcc-4_9/gcc/config/sparc/sparc.c branches/google/gcc-4_9/gcc/config/sparc/sparc.h branches/google/gcc-4_9/gcc/cp/cp-tree.h branches/google/gcc-4_9/gcc/cp/decl.c branches/google/gcc-4_9/gcc/cp/decl2.c branches/google/gcc-4_9/gcc/doc/tm.texi branches/google/gcc-4_9/gcc/doc/tm.texi.in branches/google/gcc-4_9/gcc/system.h branches/google/gcc-4_9/gcc/target.def
[Bug debug/66468] [6 Regression] ICE in in check_die, at dwarf2out.c:5719
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66468 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org --- Jason, this behavior exists prior to the debug-early work. For the 1.ii/2.ii testcase in comment 4 we are generating a DIE for a __base_dtor. First we retrofit the declaration with force_decl_die, and use this DIE as the basis for a DW_AT_specification variant. Eventually dwarf2out_abstract_function() gets called on this DW_AT_specification variant and we annotate it with DW_AT_inline. This DW_AT_specification variant, already has location info which is why we fail the assert. It was my understanding that DW_AT_inline cannot appear in conjunction with location info. I added the check_die() code to a branch of mainline immediately before my work, and it ICEs similarly to current mainline with a problematic DIE of: DIE0: DW_TAG_subprogram (0x703885a0) abbrev id: 0 offset: 0 mark: 0 DW_AT_specification: die - 0 (0x703884b0) DW_AT_low_pc: label: *.LFB0 DW_AT_high_pc: label: *.LFE0 DW_AT_frame_base: location descriptor: (0x703885f0) DW_OP_call_frame_cfa 0, 0 DW_AT_GNU_all_call_sites: 1 DW_AT_inline: 2 Could you please take a look at this, since it is broken behavior prior to early debug? Perhaps it is expected behavior and we can remove the DW_AT_inline + location check?
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #14 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Attached some prepared test files. Added more test cases for integer and real. Added new test case for logical : subroutine s2 logical(8), parameter :: z1(2) = .true. .or. [ logical(8) :: [ logical(4) :: ], .false., .false. ] logical(8) :: z2(2) = .true. .or. [ logical(8) :: [ logical(4) :: ], .false., .false. ] logical(8) :: z3(2) z3 = .true. .or. [ logical(8) :: [ logical(4) :: ], .false., .false. ] if ( (.not. z1(1)) .and. (.not. z1(2)) ) call abort if ( (.not. z2(1)) .and. (.not. z2(2)) ) call abort if ( (.not. z3(1)) .and. (.not. z3(2)) ) call abort end subroutine s2
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 9 15:27:01 2015 New Revision: 224287 URL: https://gcc.gnu.org/viewcvs?rev=224287root=gccview=rev Log: PR c++/66387 * semantics.c (process_outer_var_ref): Make sure the value is actually constant before returning it. * typeck.c (cp_build_array_ref): Allow subscripting non-lvalue array. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c
[Bug c++/65966] [5/6 Regression] [C++14] sorry, unimplemented: unexpected AST of kind try_block when initializing a 2D array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65966 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 CC||jason at gcc dot gnu.org Target Milestone|--- |5.2 Summary|sorry, unimplemented: |[5/6 Regression] [C++14] |unexpected AST of kind |sorry, unimplemented: |try_block when |unexpected AST of kind |initializing a 2D array |try_block when ||initializing a 2D array Ever confirmed|0 |1
[Bug tree-optimization/66299] more optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66299 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Jun 9 14:24:04 2015 New Revision: 224283 URL: https://gcc.gnu.org/viewcvs?rev=224283root=gccview=rev Log: PR tree-optimization/66299 * match.pd ((CST1 A) == CST2 - A == ctz (CST2) - ctz (CST1) ((CST1 A) != CST2 - A != ctz (CST2) - ctz (CST1)): New patterns. * gcc.dg/pr66299-1.c: New test. * gcc.dg/pr66299-2.c: New test. * gcc.dg/pr66299-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr66299-1.c trunk/gcc/testsuite/gcc.dg/pr66299-2.c trunk/gcc/testsuite/gcc.dg/pr66299-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #13 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35728 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35728action=edit test case pr66193_3_diverse.f90
[Bug c++/65815] brace elision doesn't work in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 65815, which changed state. Bug 65815 Summary: brace elision doesn't work in NSDMI https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 9 14:51:30 2015 New Revision: 224285 URL: https://gcc.gnu.org/viewcvs?rev=224285root=gccview=rev Log: PR bootstrap/66448 * toplev.c (check_global_declaration): Don't warn about a clone. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-function1.C Modified: trunk/gcc/ChangeLog trunk/gcc/toplev.c
[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504 --- Comment #6 from Andrey Vihrov andrey.vihrov at gmail dot com --- Thanks for your reply. You have a point: using -fwhole-program introduces more effects than needed, as evidenced by this bug report, so an anonymous namespace is safer and cleaner. In any case, in this bug report we have a program that produces unexpected results with GCC. If this usage is supported, then it is a bug. If this usage is unsupported, then it would be nice to explicitly document cases when -fwhole-program can be used in GCC. For example, GCC documentation might say something like Note: -fwhole-program can be specified for programs that link only to the standard C/C++ library (or link to nothing at all), and do not use any template class or function from the standard C++ library.
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #12 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35727 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35727action=edit test case pr66193_2_integer.f90
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 --- Comment #11 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Created attachment 35726 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35726action=edit test case pr66193_1_real.f90
[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66383 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 9 14:13:22 2015 New Revision: 224282 URL: https://gcc.gnu.org/viewcvs?rev=224282root=gccview=rev Log: PR c++/66383 * tree.c (replace_placeholders_r): Handle placeholders for an outer object. * typeck2.c (store_init_value): Only replace_placeholders for objects of class type. Added: trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/cp/typeck2.c
[Bug tree-optimization/66299] more optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66299 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- This one should be done.
[Bug c++/65815] brace elision doesn't work in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65815 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Jun 9 14:59:08 2015 New Revision: 224286 URL: https://gcc.gnu.org/viewcvs?rev=224286root=gccview=rev Log: /cp 2015-06-09 Paolo Carlini paolo.carl...@oracle.com PR c++/65815 * typeck2.c (digest_nsdmi_init): On aggregates use reshape_init. * init.c (expand_default_init): Likewise. /testsuite 2015-06-09 Paolo Carlini paolo.carl...@oracle.com PR c++/65815 * g++.dg/cpp0x/nsdmi-aggr1.C: New. * g++.dg/cpp0x/mem-init-aggr1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/mem-init-aggr1.C trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-aggr1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug target/66474] Document the use of %x in powerpc asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66474 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-09 CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||munroesj at us dot ibm.com Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/66475] Access checking in templates circumvented with 'using' (C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66475 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 Blocks||59002 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 [Bug 59002] [meta-bug] Access checking in templates
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- Ops, Kirill is already looking at this. Kirill, you have much better facilities for testing, do you want to take the proposed patch from here?
[Bug c++/66476] New: Erroneous initializer_list lifetime extension from temporary initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66476
Bug ID: 66476
Summary: Erroneous initializer_list lifetime extension from
temporary initializer_list
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot co.uk
Target Milestone: ---
#include stdio.h
#include initializer_list
struct S { S(int) { puts(S(int)); } ~S() { puts(~S()); } };
int main() {
std::initializer_listS ss({42}); // note extra parentheses
puts(main);
}
Expected output (clang 3.7, MSVC 18.00.21005.1):
S(int)
~S()
main
Observed output (gcc 5.1.0):
S(int)
main
~S()
The same behaviour is observed when the temporary initializer_list is made
explicit:
std::initializer_listS ss = std::initializer_listS{42};
Again, gcc lifetime-extends the backing array; MSVC and clang do not.
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 9 16:56:12 2015 New Revision: 224289 URL: https://gcc.gnu.org/viewcvs?rev=224289root=gccview=rev Log: DR 1467 PR c++/51747 * typeck2.c (digest_init_r): Replace previous change with gcc_unreachable. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c
[Bug target/66474] New: Document the use of %x in powerpc asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66474 Bug ID: 66474 Summary: Document the use of %x in powerpc asm statements Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu A user that was trying to use PowerPC VSX instructions reported that we never documented that you need to use %xn in PowerPC asm statements if the register could be a VSX register (as opposed to traditional FPR or Altivec register).
[Bug c++/66476] Erroneous initializer_list lifetime extension from temporary initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66476 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 Ever confirmed|0 |1
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|NEW |ASSIGNED CC||ubizjak at gmail dot com
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 35729 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35729action=edit Proposed patch Patch that fixes the failure.
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 Target Milestone|--- |5.2 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed. I have a patch.
[Bug rtl-optimization/66306] ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66306 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-09 Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org --- Created attachment 35730 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35730action=edit Experimental fix When preparing the operands for using an alternative with swapped operands reload does not swap the information about match_dups in recog_data.
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #38 from David Edelsohn dje at gcc dot gnu.org --- It also broke ARM and PowerPC. This patch should have been tested on all of the config-list.mk targets.
[Bug c++/66475] New: Access checking in templates circumvented with 'using' (C++11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66475
Bug ID: 66475
Summary: Access checking in templates circumvented with 'using'
(C++11)
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zerolo at gmail dot com
Target Milestone: ---
Created attachment 35731
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35731action=edit
repo that compiles with g++-4.9.2 -std=c++11
This is a variant of the various access checking problems when using templates,
but I don't think it's a duplicate of any of the existing ones in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 , as this one is only
triggered with the `using` directive in C++11 mode, but not when employing the
supposedly identical typedef.
Code that accesses a type that should be private compiles, even though it
shouldn't be able to. When either a) the using directive using Base = FooT
is replaced by the equivalent typedef, or b) later no other type from Base is
publicized, then access is correctly prohibited and the example fails to
compile.
// g++-4.9.2 -std=c++11 t.cpp
templateclass T
struct Foo
{
using type = T;
};
templateclass T
class Bar : public FooT
{
using Base = FooT; // the combination of this and the public export of a
type from Base below, causes this example to compile even though it shouldn't
// typedef FooT Base; // when using typedef instead of using, it correctly
fails to compile
public:
// without this public export, Base is correctly recognized as private, maybe
it erroneously make Base itself public?
// whether written as 'typedef' or 'using' doesn't matter
using type = typename Base::type;
};
Barint::Base x; // shouldn't compile, Base is private
int main()
{
return 0;
}
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz --- Great, do you have patch? Honza
[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- I agree the docs should be clear on what's supported.
[Bug c++/66383] [5/6 Regression] ICE in gimplify_expr on this passed in inline initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66383 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 9 17:19:12 2015 New Revision: 224291 URL: https://gcc.gnu.org/viewcvs?rev=224291root=gccview=rev Log: PR c++/66383 * tree.c (replace_placeholders_r): Handle placeholders for an outer object. * typeck2.c (store_init_value): Only replace_placeholders for objects of class type. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr3.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/tree.c branches/gcc-5-branch/gcc/cp/typeck2.c
[Bug c++/66387] [5/6 Regression] ICE in make_decl_rtl with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66387 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 9 17:19:18 2015 New Revision: 224292 URL: https://gcc.gnu.org/viewcvs?rev=224292root=gccview=rev Log: PR c++/66387 * semantics.c (process_outer_var_ref): Make sure the value is actually constant before returning it. * typeck.c (cp_build_array_ref): Allow subscripting non-lvalue array. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const5.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/semantics.c branches/gcc-5-branch/gcc/cp/typeck.c
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 15350, which changed state. Bug 15350 Summary: [tree-ssa] Convert if ((1 a) 1) into if (a == 0). https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15350 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/66474] Document the use of %x in powerpc asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66474 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 35732 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35732action=edit Proposed patch to fix the problem
[Bug tree-optimization/15350] [tree-ssa] Convert if ((1 a) 1) into if (a == 0).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15350 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||5.1.0 Resolution|--- |FIXED Known to fail||4.9.2 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- This was fixed in gcc-5.
[Bug tree-optimization/66163] [6 Regression] Not working Firefox built with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66163 --- Comment #14 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #13) Great, do you have patch? Honza Yes, I've suggested a patch here: https://bugzilla.mozilla.org/show_bug.cgi?id=1167119 Let's see if it will be accepted by Mozilla folks. Anyway, the GCC revision where you made VRP more aggressive works, but there's a different revision that causes a segfault. I will bisect it. Martin
[Bug c++/66478] New: [constexpr] accepts-invalid with read of non-constant variable as discarded value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66478
Bug ID: 66478
Summary: [constexpr] accepts-invalid with read of non-constant
variable as discarded value
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC accepts this ill-formed code:
void f(int n) { static_assert((+n, true), ); }
This is invalid because it reads the variable 'n', whose value is not known
within the constant expression.
[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66473 --- Comment #4 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Sure, I'll report tomorrow.
[Bug c++/66477] New: [constexpr] accepts-invalid with constexpr member call on non-constant reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66477
Bug ID: 66477
Summary: [constexpr] accepts-invalid with constexpr member call
on non-constant reference
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
GCC accepts this invalid code:
struct a { constexpr int size() const { return 3; } };
void f(a r) { static_assert(r.size() == 3, error); }
The static_assert condition is non-constant because it mentions the reference
'r' whose referent is not known within that constant expression.
[Bug c++/58074] [C++11] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #3 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- This bug results in GCC failing to follow the Itanium C++ ABI when passing such types to/from functions; see llvm.org/PR23764 for a user complaint of cross-vendor ABI incompatibility.
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Tue Jun 9 21:14:46 2015 New Revision: 224303 URL: https://gcc.gnu.org/viewcvs?rev=224303root=gccview=rev Log: Mark offloaded functions as parallelized 2015-06-09 Tom de Vries t...@codesourcery.com PR tree-optimization/65460 * omp-low.c (expand_omp_target): Set parallelized_function on cgraph_node for child_fn. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c
[Bug middle-end/66479] New: -fstack-check doesn't prevent stack allocation with size -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479
Bug ID: 66479
Summary: -fstack-check doesn't prevent stack allocation with
size -1
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jann at thejh dot net
Target Milestone: ---
[I hope I filed this in the correct place? Sorry, I'm not very familiar with
gcc internals.]
It looks like -fstack-check doesn't prevent stack allocations with size
(unsigned long)-1 and values close to that. Repro code:
$ cat stackalloc.c
#include stdio.h
#include bsd/string.h
int main(void) {
unsigned long size = -1;
char buf2[] = hello world;
char buf[size];
strlcpy(buf, asdfasdf1234, size);
puts(buf2);
return 0;
}
$ gcc -o stackalloc stackalloc.c -fstack-check -lbsd -m32 -ggdb -Wall -Wextra
$ ./stackalloc
1234
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jann/tmp/gccroot/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/home/jann/tmp/gccroot
--disable-bootstrap
Thread model: posix
gcc version 5.1.0 (GCC)
This might be a security problem if an application decides to perform stack
allocations with completely attacker-controlled sizes.
[Bug tree-optimization/65460] parloops transforms offloaded functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65460 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from vries at gcc dot gnu.org --- patch committed to trunk, marking resolved fixed.
[Bug fortran/66480] New: FPE calling cpu_time() with -ffpe-trap=inexact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66480 Bug ID: 66480 Summary: FPE calling cpu_time() with -ffpe-trap=inexact Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nicolasbock at gmail dot com Target Milestone: --- Created attachment 35733 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35733action=edit The test program The attached code, compiled with $ gfortran -ffpe-trap=inexact test.F90 results in a SIGFPE: $ ./a.out Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: #0 0x7FA644B29757 #1 0x7FA644B29D5E #2 0x7FA644059EEF #3 0x7FA644BF8D82 #4 0x4008A8 in MAIN__ at test.F90:? Floating point exception
[Bug fortran/66480] FPE calling cpu_time() with -ffpe-trap=inexact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66480 --- Comment #1 from Nicolas Bock nicolasbock at gmail dot com --- gcc-4.7.4 fails just the same.
[Bug bootstrap/66448] [6 Regression] Bootstrap fails on darwin after r224161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66448
--- Comment #14 from Aldy Hernandez aldyh at gcc dot gnu.org ---
Created attachment 35734
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35734action=edit
Patch to ICE on other duplicate DW_AT_ attributes
On 06/09/2015 08:00 AM, iains at gcc dot gnu.org wrote:
So .. things are *very* much improved, thanks!
Awesome!
(at least no reports during bootstrap),
but there's still quite a bit of fallout in the testsuite (many more failing
tests than listed below, these are just examples):
FAIL: gcc.c-torture/execute/20020412-1.c -O3 -g (test for excess errors)
FAIL: gcc.c-torture/execute/20040308-1.c -O3 -g (test for excess errors)
FAIL: gcc.c-torture/execute/20070919-1.c -O3 -g (test for excess errors)
FAIL: gcc.dg/torture/pr8081.c -O3 -g (test for excess errors)
etc
(usually several) instances of:
warning: invalid DWARF generated by the compiler: DIE 0x018b has multiple
AT_decl_file attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccSyKR0x.o'.
I can't reproduce any of these with a cross compiler. I'm building a cross
with:
--enable-languages=c,c++ --disable-bootstrap --disable-multilib
--target=i686-darwin
...but I still can't get cc1plus to trigger any ICE with the attached patch.
warning: invalid DWARF generated by the compiler: DIE 0x015d has multiple
AT_decl_line attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//kVUY.o'.
FAIL: c-c++-common/cilk-plus/CK/cilk-for-2.c -g (test for excess errors)
FAIL: c-c++-common/cilk-plus/CK/cilk-fors.c -g (test for excess errors)
FAIL: c-c++-common/cilk-plus/CK/cilk_for_grain.c -g (test for excess errors)
FAIL: c-c++-common/cilk-plus/CK/cilk_for_ptr_iter.c -g (test for excess
errors)
FAIL: c-c++-common/cilk-plus/CK/nested_cilk_for.c -g (test for excess
errors)
etc
also plugin tests.
(many) instances of:
warning: invalid DWARF generated by the compiler: DIE 0x0176 has multiple
AT_artificial attributes in
'/var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccNJ6qak.o'.
Similarly here.
The attached patch adds ICEs for duplicate
DW_AT_{artificial,decl_line,decl_file} tags. Since I'm flying blind here,
would you mind finding for which files we trigger ICEs and attach the
preprocessed files so I can reproduce with a cc1/cc1plus? I assume just one of
each type will do.
Thanks.
[Bug fortran/66480] FPE calling cpu_time() with -ffpe-trap=inexact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66480 --- Comment #2 from Nicolas Bock nicolasbock at gmail dot com --- gcc-4.9.2 fails as well.
[Bug libstdc++/66417] std::codecvt_utf16char32_t, 0x10FFFF, std::codecvt_mode::generate_header generates incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66417 --- Comment #5 from Leo Carreon lcarreon at bigpond dot net.au --- Is this fix going to be applied to Fedora 22?
[Bug tree-optimization/60656] [4.8 regression] x86 vectorization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Bernhard Kaindl bernhard.kaindl at thalesgroup dot com changed: What|Removed |Added CC||bernhard.kaindl@thalesgroup ||.com --- Comment #15 from Bernhard Kaindl bernhard.kaindl at thalesgroup dot com --- Confirmed: * Fixed in: gcc-4.9.2 (release) * NOT Fixed in: gcc-4.8.4 (release) It seems indeed only i386, x32 and x86_64 (-m32, -mx32 and -m64) are affected. -fopt-info-vec-note show that e.g. powerpc powerpc64 don't vectorize the loop. The mainline fix from Comment #8 apples without fuzz and fixes this wrong code issue in gcc-4.8.4. Apply it for 4.8.5?
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Summary|[4.9/5 Regression] one more |[4.9/5/6 Regression] one |stack slot used due to one |more stack slot used due to |less inlining level |one less inlining level --- Comment #39 from Alexandre Oliva aoliva at gcc dot gnu.org --- At least the sparc regression was caused by the change richi requested to disregard the underlying decl in promote_ssa_mode. I didn't realize this could cause a mismatch between the mode of the partition created for the QImode parm default def and the promoted mode for the parm decl expected by the parm-assignment code in function.c. This will likely take some time to sort out, so I'm reverting the patch for now.
[Bug libstdc++/66464] codecvt_utf16 max_length returning incorrect value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66464 --- Comment #2 from Leo Carreon lcarreon at bigpond dot net.au --- Just clarifying that my comments are to do with codecvt_utf16char32_t and codecvt_utf8char32_t. The way I understand it, codecvt_utf16char32_t should be converting between UTF-16 and UCS-4. UTF-16 uses 2 bytes for characters in the BMP (characters in the range 0x to 0x) and 4 bytes (surrogate pairs) for characters above the BMP (0x01 to 0x10). UCS-4 uses 4 byte values. Therefore, codecvt_utf16char32_t::max_length() should be returning 4 if the BOM is not taken into account. codecvt_utf8char32_t converts between UTF-8 and UCS-4. UTF-8 can use up to 4 bytes for characters up to the range 0x10. Therefore, codecvt_utf8char32_t::max_length() should be returning 4 if the BOM is not taken into account. As I said in my previous post, I'm not sure if the BOM should be accounted for in max_length(). If I'm not mistaken, the purpose of this function is to allow a user to estimate how many bytes are required to fit a UCS-4 string when converted to either UTF-16 or UTF-8. And my guess, the BOM can be taken into account separately when doing the estimation. For example, when wstring_convert estimates the length of the std::string to be generated by wstring_convert::to_bytes(). It should be the number of UCS-4 characters multiplied by max_length() and then add the size of the BOM if required. The resulting std::string can be resized after the conversion to eliminate the unused bytes. Note that the comment you mentioned in your reply probably only applies to codecvt_utf8_utf16 which converts between UTF-8 and UTF-16 directly without going thru the UCS-4 conversion.
[Bug libstdc++/66441] wstring_convert not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66441 --- Comment #5 from Leo Carreon lcarreon at bigpond dot net.au --- Is this fix going to be applied to Fedora 22?
[Bug middle-end/66375] [4.8/4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66375 Bernhard Kaindl bernhard.kaindl at thalesgroup dot com changed: What|Removed |Added CC||bernhard.kaindl@thalesgroup ||.com --- Comment #11 from Bernhard Kaindl bernhard.kaindl at thalesgroup dot com --- Created attachment 35735 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35735action=edit Backport to gcc-4_9-branch/gcc-4.9.2: PR tree-optimization/66375 (wrong code fix!) Backport from mainline to gcc-4_9-branch (also applies to gcc-4.9.2): Note: Fixes wrong code for x86 and x86_64 targets (other targets apparently not affected) URL: this attachment Log: 2015-06-10 Bernhard Kaindl bernhard.kai...@thalesgroup.com Backport from mainline 2015-06-03 Richard Biener rguent...@suse.de PR tree-optimization/66375 * tree-scalar-evolution.c (follow_ssa_edge_binary): First add to the evolution before following SSA edges. Added: trunk/gcc/testsuite/gcc.dg/torture/pr66375.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c The context of the ChangeLogs is removed, so it applies using patch -p1 without ever causing a conflict (other changes may be merged before this, the ChangeLogs are automatically added on top without context matching), but it won't apply with git apply this way.
[Bug middle-end/66479] -fstack-check doesn't prevent stack allocation with size -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Then this probably wraps around, including the stack allocation.
[Bug middle-end/66479] -fstack-check doesn't prevent stack allocation with size -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-09 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- What's your 'ulimit -s' setting?
[Bug middle-end/66479] -fstack-check doesn't prevent stack allocation with size -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66479 --- Comment #2 from Jann Horn jann at thejh dot net --- $ ulimit -s 8192
[Bug c++/66472] -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
Christoph Hertzberg chtz at informatik dot uni-bremen.de changed:
What|Removed |Added
CC||chtz at informatik dot
uni-bremen.
||de
--- Comment #1 from Christoph Hertzberg chtz at informatik dot uni-bremen.de
---
Wouldn't this actually be a valid warning if BaseClass had a constructor taking
a function pointer/member function pointer?
struct BaseClass {
BaseClass(int) { std::cout int\n; }
BaseClass(int () ) { std::cout int()\n; }
BaseClass(int (BaseClass::*)()) {std::cout int (BaseClass::*)()\n; }
static int size() { return 0;}
int size2() { return 0; }
};
struct Foo : public BaseClass {
using BaseClass::size;
using BaseClass::size2;
// size shadows BaseClass::size!
Foo(int size) : BaseClass(size) {}
Foo() : BaseClass(size) {} // uses BaseClass::size
Foo(char) : BaseClass(size2) {} // uses BaseClass::size2
};
[Bug c++/66472] -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-09 Ever confirmed|0 |1
