[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #7 from Oleg Endo ---
Another example:
unsigned int
count_trailing_nonzero_bits (unsigned int v, unsigned int c)
{
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
c += v & 1;
v >>= 1;
return c;
}
ideally should compile to:
mov #0,r1
shlr r4
movt r0
shlr r4
addc r1,r0
shlr r4
addc r1,r0
shlr r4
addc r1,r0
shlr r4
addc r1,r0
shlr r4
addc r1,r0
shlr r4
addc r1,r0
shlr r4
addc r1,r0
[Bug target/65979] [5/6 Regression] [SH] Wrong code is generated with stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979 --- Comment #48 from Oleg Endo --- Can we close this as fixed?
[Bug target/66563] [4.9/5 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #55 from Oleg Endo --- Can we close this as fixed?
[Bug middle-end/67014] New: builtin_tolower is inefficient.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67014
Bug ID: 67014
Summary: builtin_tolower is inefficient.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: neleai at seznam dot cz
Target Milestone: ---
Hi,
When one uses __builtin_tolower it could be much slower to tolower. In this
example builtin_tolower gets just expanded to call. If one uses tolower instead
it gets expanded to getting table with __ctype_tolower_loc and then doing 1000
table lookups instead 1000 calls.
#include
int foo(char *c)
{
int i;
for(i=0;i<1000;i++)
c[i]=__builtin_tolower(c[i]);
}
[Bug c++/67010] Name hiding in the same declarative region fails when done via using-directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67010
--- Comment #1 from Anders Granlund ---
Detailed explanation of how the c++ standard can be applied to the program:
By [namespace.udir]/2 during the unqualified name lookup of x in sizeof (x),
the declaration struct x {}; appears as if it was declared in the declarative
region of the global namespace, so the name lookup will appear to be affected
by the type of name hiding described in [basic.scope.hiding]/2. Because of this
name hiding we should not get any ambiguity in the name lookup.
[Bug c++/67013] Compilation error for well-formed program with empty declaration in the global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013 --- Comment #1 from Andrew Pinski --- Did this change between C++98 and C++14 because GCC has the following in its source: /* A declaration consisting of a single semicolon is invalid. Allow it unless we're being pedantic. */
[Bug c++/67013] New: Compilation error for well-formed program with empty declaration in the global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67013
Bug ID: 67013
Summary: Compilation error for well-formed program with empty
declaration in the global namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
int main() {};
It is well-formed, the extra semi colon is just an empty declaration after the
definition of main.
Compile it with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
The following error message is then given:
prog.cc:1:14: error: extra ';' [-Wpedantic]
int main() {};
^
I expected to get no error messages since the program is well-formed. For
comparison Clang gives no error message.
I have tried it with gcc HEAD 6.0.0 201507 here:
http://melpon.org/wandbox/permlink/gaOys1DxBYMnRWei
[Bug c++/66857] [5/6 Regression] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 --- Comment #6 from Patrick Palka --- Author: ppalka Date: Sat Jul 25 23:15:44 2015 New Revision: 226228 URL: https://gcc.gnu.org/viewcvs?rev=226228&root=gcc&view=rev Log: Fix PR c++/66857 gcc/cp/ChangeLog: PR c++/66857 * cvt.c (ocp_convert): Don't call scalar_constant_value when converting to a class type. gcc/testsuite/ChangeLog: PR c++/66857 * g++.dg/init/pr66857.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/pr66857.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/66968] Incorrect template argument shown in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968 --- Comment #2 from Jonathan Wakely --- Yes maybe a dup of PR99 but it looks like all the examples in that bug involve an overload and using the parameter names from the wrong overload. Here it uses the parameter from a function that never participates in overload resolution.
[Bug c++/67012] New: decltype(auto) with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67012 Bug ID: 67012 Summary: decltype(auto) with trailing return type Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david.godfrey99 at gmail dot com Target Milestone: --- Compiles in GCC but not Clang: decltype(auto) f() -> int; The code is ill-formed because only auto is allowed with a trailing return type.
[Bug libstdc++/67011] New: division by zero in std::exponential_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67011 Bug ID: 67011 Summary: division by zero in std::exponential_distribution Product: gcc Version: 4.8.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Target Milestone: --- After seeing a division-by-zero problem in a C++11 code (compiled with GCC 4.8.4), I traced it down and found that it seems to come from a call to std::exponential_distribution. Looking into the GCC trunk sources, I found two implementations of std::exponential_distribution, in these two files: libstdc++-v3/include/bits/random.h libstdc++-v3/include/tr1/random.h In the first one, operator() is implemented like this: return -std::log(result_type(1) - __aurng()) / __p.lambda(); In the second one like this: return -std::log(__urng()) / _M_lambda; Looking through bugzilla I found PR 55047, which seems to describe exactly the problem I observed (resulting from a log(0) call), but the fix has only been applied to bits/random.h, not to tr1/random.h. I don't actually understand the relationship between those two files (and which implementation is used under which circumstances), but I guess the fix from PR 55047 should also be applied to tr1/random.h?
[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463 --- Comment #2 from Manuel López-Ibáñez --- This is handled before reaching the middle-end, thus it would need to be detected in the FE.
[Bug c++/66996] [6 Regression] defined but not used [-Wunused-function]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66996 --- Comment #2 from Andrew Pinski --- The warning seems correct as Foo::~Foo is not used and the function can be used outside of the current translation unit.
[Bug middle-end/64463] Add warning: returns_nonnull attribute on a function compared against NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64463 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-25 CC||manu at gcc dot gnu.org Blocks||58689 Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- Confirmed. Related to PR17308. This is one of the things requested in PR58689. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58689 [Bug 58689] Enhance returns_nonnull
[Bug middle-end/44081] Incorrect nonnull assumed in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #13 from Manuel López-Ibáñez --- Should we close this?
[Bug middle-end/17308] nonnull attribute not as useful as it could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 Manuel López-Ibáñez changed: What|Removed |Added CC||e...@sf-mail.de --- Comment #10 from Manuel López-Ibáñez --- *** Bug 46936 has been marked as a duplicate of this bug. ***
[Bug c/46936] turn __attribute__ ((nonnull (x))) into assert in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46936 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #5 from Manuel López-Ibáñez --- I think -fsanitize should already detect this at run time, but GCC could indeed warn for those cases that it detects. *** This bug has been marked as a duplicate of bug 17308 ***
[Bug sanitizer/67009] libsanitizer: shift overflow warnings when boot strapping 32 bit library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009 --- Comment #1 from Andrew Pinski --- tsan should not be building for 32bits.
[Bug fortran/65792] allocation of scalar elemental function with structure constructor fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65792 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Mikael Morin --- I think this has been fixed, no need to keep it open.
[Bug libstdc++/60970] Support std::hash with enum types (LWG 2148)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970 --- Comment #3 from Ville Voutilainen --- Patch available: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02162.html
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #19 from Mikael Morin --- (In reply to Mikael Morin from comment #18) > The patches have been committed. I mean the (single) patch has been committed on the two branches.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #11) > > Yes, this fixes the testsuite failure for me. > > For me too. The patches have been committed. I assume the problem is fixed now.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #17 from Mikael Morin --- Author: mikael Date: Sat Jul 25 18:51:23 2015 New Revision: 226224 URL: https://gcc.gnu.org/viewcvs?rev=226224&root=gcc&view=rev Log: Fix gfortran.dg/class_to_type_4.f90 deallocation code misordering failure PR fortran/64986 gcc/fortran/ * trans-expr.c (gfc_trans_assignment_1): Put component deallocation code at the beginning of the block. Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-expr.c
[Bug c++/66968] Incorrect template argument shown in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- A dup of PR99 ?
[Bug c++/67010] New: Name hiding in the same declarative region fails when done via using-directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67010
Bug ID: 67010
Summary: Name hiding in the same declarative region fails when
done via using-directive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following well-formed program:
namespace N { struct x {}; }
using namespace N;
int x;
int main() { sizeof (x); }
Compile it with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
Observe that error messages about name lookup ambiguity are given. I expect to
get no errors when compiling since the program is well-formed.
That the program is well-formed can be seen by applying both [namespace.udir]/2
and [basic.scope.hiding]/2:
http://eel.is/c++draft/dcl.dcl#namespace.udir-2
http://eel.is/c++draft/basic.scope.hiding#2
This seems reasonable also, so I don't think this is a defect of the c++
standard.
I tried it with gcc HEAD 6.0.0 201507 here:
http://melpon.org/wandbox/permlink/GmJgvsbjt5CPdWrA
[Bug sanitizer/67009] New: libsanitizer: shift overflow warnings when boot strapping 32 bit library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67009 Bug ID: 67009 Summary: libsanitizer: shift overflow warnings when boot strapping 32 bit library Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- After a recent update, I noticed the following warnings in the 32-bit build of libsanitizer. /eng/upc/dev/gary/gupc-merge/src/gupc/libsanitizer/tsan/tsan_sync.h:86:35: warning: result of ‘(3 << 30)’ requires 33 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=] /eng/upc/dev/gary/gupc-merge/src/gupc/libsanitizer/tsan/tsan_sync.h:88:35: warning: result of ‘(2 << 30)’ requires 33 bits to represent, but ‘int’ only has 32 bits [-Wshift-overflow=] /eng/upc/dev/gary/gupc-merge/src/gupc/libsanitizer/tsan/tsan_sync.h:86:35: warning: result of ‘(3 << 30)’ requires 33 bits to represent, but ‘int’ only has 32
[Bug c++/67008] Qualified name-lookup in using-declaration fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67008 --- Comment #1 from Anders Granlund --- Forgot the command line: g++ prog.cc -std=c++14 -pedantic-errors
[Bug c++/67008] New: Qualified name-lookup in using-declaration fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67008
Bug ID: 67008
Summary: Qualified name-lookup in using-declaration fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program:
namespace N { int i; }
using namespace N;
using ::i;
int main() {}
Compile it with the following command line:
Observe that the following error message is given:
prog.cc:3:9: error: 'i' not declared
using ::i;
^
The program is well-formed, so this error message is not expected. It seems
that the qualified name-lookup inside the using-declaration fails.
I tried it with gcc HEAD 6.0.0 201507 here:
http://melpon.org/wandbox/permlink/immhNeWFCMcCA800
[Bug c++/67007] New: [c++-concepts] Deduction constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67007
Bug ID: 67007
Summary: [c++-concepts] Deduction constraint
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
r226205 ICEs compiling this program:
template
concept bool A =
requires (U u) { u; };
template
concept bool B =
requires (T t) { { t } -> A; };
void foo(B);
apparently while normalizing the constraints of B:
~/concept-gcc/bin/g++ -std=c++1z foo.cpp -c
foo.cpp:9:11: internal compiler error: in tsubst_constraint, at
cp/constraint.cc:1511
void foo(B);
^
0x8032b1 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:1511
0x65794f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:12798
0x806bf0 tsubst_compound_requirement
../../gcc/cp/constraint.cc:1604
0x806bf0 tsubst_requirement
../../gcc/cp/constraint.cc:1632
0x806bf0 tsubst_requirement_body
../../gcc/cp/constraint.cc:1651
0x806bf0 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:1682
0x65103a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:16429
0x64462e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15092
0x80591f lift_variable_initializer
../../gcc/cp/constraint.cc:440
0x805220 normalize_predicate_constraint
../../gcc/cp/constraint.cc:955
0x805220 normalize_constraint
../../gcc/cp/constraint.cc:993
0x805508 build_constraints(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:1096
0x5af175 grokfndecl
../../gcc/cp/decl.c:7788
0x6208f6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:11202
0x621126 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:4744
0x710580 cp_parser_init_declarator
../../gcc/cp/parser.c:17728
0x71336d cp_parser_simple_declaration
../../gcc/cp/parser.c:11685
0x70c8f4 cp_parser_block_declaration
../../gcc/cp/parser.c:11559
0x718783 cp_parser_declaration
../../gcc/cp/parser.c:11456
0x716f5a cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:11338
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 Uroš Bizjak changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #18 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #17) > (In reply to Mat Cross from comment #14) > > For the record, perhaps it is of interest for me to note that we are running > > into this (cf. PR64230 comment 9) on code like > > > > Program test > > Implicit None > > Type :: t1 > > Integer, Allocatable :: i > > End Type > > Type :: t2 > > Integer, Allocatable :: i > > End Type > > Type, Extends (t1) :: t3 > > Type (t2) :: j > > End Type > > Type, Extends (t3) :: t4 > > Integer, Allocatable :: k > > End Type > > Call s > > Print *, 'ok' > > Contains > > Subroutine s > > Class (t1), Allocatable :: x > > Allocate (t4 :: x) > > End Subroutine > > End Program > > > > Since the crash is in bad compiler-generated finalization code (since 4.9), > > and given that (if I recall correctly) gfortran is using the Fortran 2008 > > semantics for entities declared in a main program being implicitly saved, > > this is why removing the Deallocate (in the comment 12 example) works - the > > finalizer is never called then. > > No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce: [...] I was able to trace dumps down to _.fre2 tree dump, where we have: : # idx_104 = PHI <0(11), idx_122(16)> offset_115 = 0; ptr2_119 = (struct t3 *) offset_115; _120 = &ptr2_119->j; This can't be right, we have a dereference from zero. If the frontend produced correct code, then tree-optimization passes made a mess here. CC Richi.
[Bug c++/66962] [concepts] overloaded function causing memory blow-up and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66962 --- Comment #14 from Andrew Sutton --- Created attachment 36054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36054&action=edit Optimize constraint decomposition by contraction The problem isn't strictly related to decomposition -- it's normalization prior to decomposition that's causing the problems. Whenever you have a disjunction in a low-level concept, that OR can be instantiated into the normalized constraints many, many times. I think I measured 20 times in the reduced example. I think there's actually worst case 2^N growth in the space required to solve the problem. Currently, we might accumulate a term list during decomposition like so: P || Q, P || Q, P, R, P || Q And then recursively decompose each term in that list. Each || turns into a new branch, here, eventually generating 8 different term lists, none of which are semantically different than any other. They're just permutations of terms. The patch helps reduce the space by disallowing duplicate expressions to be added to a term list during decomposition. So instead of generating the term list above, we just have: P || Q, P, R Only one branch required. There is still complexity induced by the use of disjunctions. This manages it a little better. It could be further improved by making the term list into a term set by way of hashing or ordering.
[Bug c++/67006] New: type-specifier const in declaration of anonymous union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67006
Bug ID: 67006
Summary: type-specifier const in declaration of anonymous union
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following program (prog.cc):
const union {};
int main() {}
It is ill-formed by [dcl.type.cv] http://eel.is/c++draft/dcl.dcl#dcl.type.cv-1:
"If a cv-qualifier appears in a decl-specifier-seq, the init-declarator-list of
the declaration shall not be empty."
Compile the program with the following command line:
g++ prog.cc -std=c++14 -pedantic-errors
No error messages are given. I expected to get an error message here since the
program is ill-formed.
I tried this with gcc HEAD 6.0.0 201507, here:
http://melpon.org/wandbox/permlink/lGKyEQQW4BtKube9
[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930 --- Comment #18 from Oleg Endo --- Author: olegendo Date: Sat Jul 25 14:13:48 2015 New Revision: 226219 URL: https://gcc.gnu.org/viewcvs?rev=226219&root=gcc&view=rev Log: gcc/ Backport from mainline 2015-07-25 Oleg Endo PR target/66930 * config/sh/sh.c (sh_split_movrt_negc_to_movt_xor): Add missing T bit register modified_between_p check. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.c
[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930 --- Comment #17 from Oleg Endo --- Author: olegendo Date: Sat Jul 25 14:07:17 2015 New Revision: 226218 URL: https://gcc.gnu.org/viewcvs?rev=226218&root=gcc&view=rev Log: gcc/ PR target/66930 * config/sh/sh.c (sh_split_movrt_negc_to_movt_xor): Add missing T bit register modified_between_p check. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #17 from Uroš Bizjak ---
(In reply to Mat Cross from comment #14)
> For the record, perhaps it is of interest for me to note that we are running
> into this (cf. PR64230 comment 9) on code like
>
> Program test
> Implicit None
> Type :: t1
> Integer, Allocatable :: i
> End Type
> Type :: t2
> Integer, Allocatable :: i
> End Type
> Type, Extends (t1) :: t3
> Type (t2) :: j
> End Type
> Type, Extends (t3) :: t4
> Integer, Allocatable :: k
> End Type
> Call s
> Print *, 'ok'
> Contains
> Subroutine s
> Class (t1), Allocatable :: x
> Allocate (t4 :: x)
> End Subroutine
> End Program
>
> Since the crash is in bad compiler-generated finalization code (since 4.9),
> and given that (if I recall correctly) gfortran is using the Fortran 2008
> semantics for entities declared in a main program being implicitly saved,
> this is why removing the Deallocate (in the comment 12 example) works - the
> finalizer is never called then.
No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce:
--cut here--
test ()
{
integer(kind=8)[0:D.4089] * restrict sizes;
integer(kind=8)[0:D.4068] * restrict sizes;
void * _13;
integer(kind=4) * _63;
integer(kind=4) * _121;
:
_13 = __builtin_malloc (24);
if (_13 == 0B)
goto ;
else
goto ;
:
_gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1 sz: 1});
:
MEM[(c_char * {ref-all})_13] = MEM[(c_char * {ref-all})&__def_init_test_T4];
sizes_22 = __builtin_malloc (8);
MEM[(integer(kind=8)[0:D.3483] *)sizes_22][0] = 1;
_63 = MEM[(struct t4 *)_13].k;
if (_63 == 0B)
goto ;
else
goto ;
:
__builtin_free (_63);
:
sizes_79 = __builtin_malloc (8);
_121 ={v} MEM[(struct t3 *)0B].j.i;
__builtin_trap ();
}
--cut here--
The : part reads from address 0x0+, and if this doesn't crash, trap insn
surely crashes program.
[Bug c/67004] valgrind error in recog_memoized & shorten_branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67004 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Sat Jul 25 11:34:59 2015 New Revision: 226215 URL: https://gcc.gnu.org/viewcvs?rev=226215&root=gcc&view=rev Log: PR target/67004 * config/i386/i386.h (ADJUST_INSN_LENGTH): Use NONDEBUG_INSN_P (INSN) predicate and INSN_CODE (INSN) >= 0 to check for valid instruction. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h
[Bug target/64036] [SH] Evaluate re-enabling scheduling before RA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036
--- Comment #6 from Oleg Endo ---
For this test case
static volatile int* const g_0 = (volatile int*)0x1240;
static volatile int* const g_1 = (volatile int*)0x1244;
static volatile int* const g_2 = (volatile int*)0x1248;
static volatile int* const g_3 = (volatile int*)0x124C;
int fun (void)
{
return *g_0 + *g_1 + *g_2 + *g_3;
}
I'm getting the following with -O2 with AMS (without sched1):
mov.w .L2,r1
mov.l @r1,r0
mov.l @(4,r1),r3
mov.l @(8,r1),r2
mov.l @(12,r1),r1
add r3,r0
add r2,r0
rts
add r1,r0
.align 1
.L2:
.short 4672
And with sched1:
mov.w .L2,r1
mov.w .L3,r2
mov.l @r1+,r0
mov.l @r1,r1
mov.l @r2,r2
add r1,r0
mov.w .L4,r1
add r2,r0
mov.l @r1,r1
rts
add r1,r0
.align 1
.L2:
.short 4672
.L3:
.short 4680
.L4:
.short 4684
This is one of the cases where sched1 makes things worse.
[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930 --- Comment #16 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #14) > (In reply to Kazumoto Kojima from comment #12) > > The toplevel "make -k check" on sh4-unknown-linux-gnu is running. > > I'll report back when it completes. > > I've confirmed that there are no new failures with the patch in c#10. Thanks! I will commit it to trunk and GCC 5 branch. (In reply to Kazumoto Kojima from comment #6) > > BTW, I guess that > > > * Build with -O1 on sh4 (try to work around PR target/66358). > > will open a can of worms :-) Yeah, but it revealed a bug, so it was good in this case :)
[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66648 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Sat Jul 25 09:19:24 2015 New Revision: 226212 URL: https://gcc.gnu.org/viewcvs?rev=226212&root=gcc&view=rev Log: PR target/66648 * config/i386/i386.c (ix86_expand_set_or_movmem): Emit main loop execution guard when min_size is less than size_needed. testsuite/ChangeLog: PR target/66648 * gcc.target/i386/pr66648.c: New test. Added: trunk/gcc/testsuite/gcc.target/pr66648.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/67005] New: ICE: in verify_loop_structure, at cfgloop.c:1647 (loop with header n not in loop tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67005
Bug ID: 67005
Summary: ICE: in verify_loop_structure, at cfgloop.c:1647 (loop
with header n not in loop tree)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Target Milestone: ---
Hello ! Please consider the following testcase which makes a freshly built GCC
6.0 ICE at -O2.
$ cat test.c
int a;
void f(void)
{
if(!a);
else
lbl:
a = a;
if(a)
a = 8;
goto lbl;
}
$ xgcc -w -O2 test.c
test.c: In function ‘f’:
test.c:12:1: error: loop with header 4 not in loop tree
}
^
current.c:12:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1647
0x708a75 verify_loop_structure()
../../srcdir/gcc/cfgloop.c:1647
0xa20955 loop_optimizer_init(unsigned int)
../../srcdir/gcc/loop-init.c:109
0xadc9e2 execute
../../srcdir/gcc/predict.c:3032
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/67004] valgrind error in recog_memoized & shorten_branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67004
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-07-25
CC||mshawcroft at gcc dot gnu.org,
||ubizjak at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ---
Similar issue is reported at [1] with --enable-checking=rtl
I'm testing following patch:
--cut here--
Index: i386.h
===
--- i386.h (revision 226207)
+++ i386.h (working copy)
@@ -2264,7 +2264,7 @@ do {
\
/* Adjust the length of the insn with the length of BND prefix. */
#define ADJUST_INSN_LENGTH(INSN, LENGTH) \
do { \
- if (recog_memoized (INSN) >= 0 \
+ if (INSN_P (INSN) && INSN_CODE (INSN) >= 0 \
&& get_attr_maybe_prefix_bnd (INSN)) \
LENGTH += ix86_bnd_prefixed_insn_p (INSN); \
} while (0)
--cut here--
Please note that this problem will also hit aarch64 (maintainer CC'd).
[1] https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02131.html
[Bug c++/64969] generic functions do not work with placeholder return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 Jason Merrill changed: What|Removed |Added CC||bruno.manga95 at gmail dot com --- Comment #6 from Jason Merrill --- *** Bug 66266 has been marked as a duplicate of this bug. ***
[Bug c++/66266] Abbreviated function template does not behave as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66266 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jason Merrill --- Yes, duplicate. *** This bug has been marked as a duplicate of bug 64969 ***
[Bug c++/64969] generic functions do not work with placeholder return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #5 from Jason Merrill --- Fixed for GCC 6.
[Bug c++/64969] generic functions do not work with placeholder return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 --- Comment #4 from Jason Merrill --- Author: jason Date: Sat Jul 25 07:12:31 2015 New Revision: 226208 URL: https://gcc.gnu.org/viewcvs?rev=226208&root=gcc&view=rev Log: PR c++/64969 * pt.c (splice_late_return_type): Correct deduced return type for abbreviated function template. Modified: trunk/gcc/cp/ChangeLog
[Bug c++/64989] constant-initialization of self-referencing array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64989 --- Comment #2 from Jason Merrill --- (In reply to Jason Merrill from comment #1) > PR c++/64989 > * pt.c (splice_late_return_type): Correct deduced return type for > abbreviated function template. Oops, wrong PR number.
[Bug c/67004] New: valgrind error in recog_memoized & shorten_branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67004 Bug ID: 67004 Summary: valgrind error in recog_memoized & shorten_branches Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Using today's gcc trunk code, I tried another build with valgrind. I got /home/dcb/gcc/working/./gcc/xgcc -B/home/dcb/gcc/working/./gcc/ -B/home/dcb/gcc/results/x86_64-unknown-linux-gnu/bin/ -B/home/dcb/gcc/results/x86_64-unknown-linux-gnu/lib/ -isystem /home/dcb/gcc/results/x86_64-unknown-linux-gnu/include -isystem /home/dcb/gcc/results/x86_64-unknown-linux-gnu/sys-include-g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -I. -I. -I../.././gcc -I../../../src/trunk/libgcc -I../../../src/trunk/libgcc/. -I../../../src/trunk/libgcc/../gcc -I../../../src/trunk/libgcc/../include -I../../../src/trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -Wno-missing-prototypes -Wno-type-limits -o multf3.o -MT multf3.o -MD -MP -MF multf3.dep -c ../../../src/trunk/libgcc/soft-fp/multf3.c -fvisibility=hidden -DHIDE_EXPORTS ==14694== Conditional jump or move depends on uninitialised value(s) ==14694==at 0x7594C5: recog_memoized (recog.h:167) ==14694==by 0x7594C5: shorten_branches(rtx_insn*) (final.c:1203) ==14694==by 0x759BCF: rest_of_handle_shorten_branches (final.c:4541) ==14694==by 0x759BCF: (anonymous namespace)::pass_shorten_branches::execute(function*) (final.c:4570) recog.h:167 is if (INSN_CODE (insn) < 0) Configure line is ../src/trunk/configure --prefix=/home/dcb/gcc/results \ --disable-werror \ --disable-multilib \ --enable-checking=valgrind \ --disable-bootstrap \ --enable-languages=c,c++,fortran
