[Bug target/64348] New: Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348 Bug ID: 64348 Summary: Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amker at gcc dot gnu.org Case scal-to-vec1.c failed because of ICE on arm-linux-gnueabi with -fPIC. The compilation command line is: ./arm-none-linux-gnueabi-gcc scal-to-vec1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -S -fPIC -o ./scal-to-vec1.S -mcpu=cortex-a8/a9 -marm Thumb mode is fine, processors like cortex-a7/a15 are fine. The ICE info is like below: /home/binche01/work/oban-work/src/gcc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c: In function ‘main’: /home/binche01/work/oban-work/src/gcc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:86:1: internal compiler error: in split_reg, at lra-constraints.c:4879 0xbad893 split_reg /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:4879 0xbade33 split_if_necessary /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:4983 0xbafb13 inherit_in_ebb /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:5478 0xbb04fc lra_inheritance() /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:5639 0xb9914b lra(_IO_FILE*) /home/binche01/work/oban-work/src/gcc/gcc/lra.c:2303 0xb48738 do_reload /home/binche01/work/oban-work/src/gcc/gcc/ira.c:5402 0xb48b0e execute /home/binche01/work/oban-work/src/gcc/gcc/ira.c:5573 Gcc is configured as below: --target=arm-none-linux-gnueabi --prefix=... --with-sysroot=... --disable-libssp --disable-libmudflap --enable-checking=yes --enable-languages=c,c++ --with-gmp=... --with-mpfr=... --with-mpc=... --with-isl=... --with-cloog=... --disable-libgomp --with-arch=armv7-a It is from thread https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01448.html File this PR for tracking.
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to Ondřej Čertík from comment #14) I tested it and it seems to be working! The code compiled with non_overridable on. Great. Thanks for checking. There are run-time segfaults and array bounds mismatches in our code, that don't happen with ifort, so I will be slowly isolating those and reporting them. That would be very helpful (please use separate PRs for those).
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 34297
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34297action=edit
gcc5-pr64344.patch
Untested fix, but this is getting way too ugly. Furthermore, e.g.
void
bar (void)
{
static const int a = 0.5;
static const int b = 1e234;
}
still fails with C. Wonder what was the reason to instrument it so early,
supposedly to not miss conversions optimized away during folding, right?
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #34297|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-18 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34298 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34298action=edit gcc5-pr64344.patch Better patch.
[Bug c++/59383] typedef propagation with template base class using the same name is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59383
naup at sfr dot fr changed:
What|Removed |Added
CC||naup at sfr dot fr
--- Comment #1 from naup at sfr dot fr ---
This is the same behaviour as in invalid bug 50418.
Alas, no diagnostic is required, says the standard, and gcc interpretes
**differently** the typedef type wheither the base is template or not.
NON TEMPLATE BASE
struct A
{
typedef A this_type;
};
template class T struct B : public A
{
typedef this_type parent; // this_type is taken as **A** (current context)
typedef B this_type; // the two lines make B ill-formed
};
TEMPLATE BASE
template class T struct A
{
typedef A this_type;
};
template class T struct B : public AT
{
typedef this_type parent; // this_type is taken as **B** (after-next-line
context)
typedef B this_type; // the two lines make B ill-formed
};
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Note that we should update the documentation about this change (and throw away all option handling of optimize/target attribute handled options from lto-wrapper, or rather move all of that handling to lto1).
[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ra CC||vmakarov at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Case scal-to-vec1.c failed |[5 Regression] Case |on arm-linux-gnueabi with |scal-to-vec1.c failed on |-fPIC |arm-linux-gnueabi with ||-fPIC
[Bug bootstrap/64349] New: [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349 Bug ID: 64349 Summary: [5 Regression] Bootstrapping Ada fails on darwin(9|10). Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr
[Bug bootstrap/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 CC||iains at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Bootstrapping Ada fails on darwin(9|10) with ld: warning: can't add line info to anonymous symbol __const@0 from s-arit64.o This can be fixed with the following patch from Iain Sandoe --- ../_clean/gcc/ada/gcc-interface/Makefile.in2014-11-26 10:44:12.0 +0100 +++ gcc/ada/gcc-interface/Makefile.in2014-11-26 10:55:45.0 +0100 @@ -2884,6 +2884,7 @@ gnatlib-shared-darwin: -o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \ $(SO_OPTS) \ +-Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(MISCLIB) cd $(RTSDIR); `echo $(GCC_FOR_TARGET) \ @@ -2891,6 +2892,7 @@ gnatlib-shared-darwin: -o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(GNATRTL_TASKING_OBJS) \ $(SO_OPTS) \ +-Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(THREADSLIB) -Wl,libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) cd $(RTSDIR); $(LN_S) libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
[Bug bootstrap/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349 --- Comment #2 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 34299 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34299action=edit proper fix. So, the rules on Darwin say that it's OK to access _environ directly from the main executable, but it is NOT OK to access it from a shared libaray. Instead, one should use the _NSGetEnviron() API). === My initial patch works because it allows the symbol to be satisfied at load time by dynamic lookup (it will be found from the exe, I assume). === The patch attached above uses the correct API - and works AFAICT on powerpc-darwin9 and x86_64-darwin12.
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 --- Comment #7 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Thu Dec 18 12:02:22 2014 New Revision: 218860 URL: https://gcc.gnu.org/viewcvs?rev=218860root=gccview=rev Log: Fix for PR ipa/64146 PR ipa/64146 * ipa-icf.c (sem_function::merge): Check for decl_binds_to_current_def_p is newly added to merge operation. * g++.dg/ipa/pr64146.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr64146.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 --- Comment #29 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Thu Dec 18 12:06:34 2014 New Revision: 218861 URL: https://gcc.gnu.org/viewcvs?rev=218861root=gccview=rev Log: Fix for PR bootstrap/63573. PR bootstrap/63573 * tree-inline.c (remap_gimple_stmt): Handle gimple_call_from_thunk_p predicate. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- This bug is caused in retrieve_specialization by not checking for innermost template arguments if argument-count is bigger then template-argument-count. This is mine.
[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||zreed1 at gmail dot com --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- *** Bug 60767 has been marked as a duplicate of this bug. ***
[Bug c++/60767] use of using inside template causes failure in retreive_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60767 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- Duplicate *** This bug has been marked as a duplicate of bug 61198 ***
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com, ||vmakarov at redhat dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com --- avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues. I asked Kirill to look at them. Others are not stability but more performance issues - generated code is less effective than it should be - in one case for some reasons compiler uses callee-saved ebx in PIC mode instead of edx in non-PIC mode and in xmm case compiler uses stack in PIC mode instead of xmm register in non-PIC mode I see that differencies between PIC and non-PIC modes start on reload pass so I'd like Vlad to look at these cases
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #10 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Thu Dec 18 13:32:18 2014 New Revision: 218864 URL: https://gcc.gnu.org/viewcvs?rev=218864root=gccview=rev Log: Fix for PR64330. PR tree-optimization/64330 * ipa-icf.c (sem_variable::parse): Add checking for externally visible symbols and do not introduce an alias for an external declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #11 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Reduced further:
class base
{
protected:
typedef int type;
};
template typename T
class derive: public base
{
public:
void foo()
{
struct f_t {
f_t(base::type a) {}
};
}
};
int main()
{
derivechar d;
d.foo();
}
[Bug c++/63889] [5 Regression] Ice with redundant static in class scope constexpr variable template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63889 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Issue is that we don't check for static function for template-parameter-count. So for this sample tmpl has 2 arguments, but in fact it has just 1. Not sure where we add this additional argument. We see for the template-decl 'template class T template class' ... By allowing args being less then expected template arguments, issue is fixed. But in fact we should check template-params - (is_static ? 1 : 0) ... or something like this.
[Bug sanitizer/64350] New: TSAN fails after stress-testing for a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350 Bug ID: 64350 Summary: TSAN fails after stress-testing for a while Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de 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 Hello, I see this fatal error from the thread sanitizer, after a while of stress-testing. As far as I can tell the application should not hold 64 locks at that time. Any ideas what that could be wrong here? Thanks, Bernd. FATAL: ThreadSanitizer CHECK failed: ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:65 ((n_all_locks_)) (((sizeof(all_locks_with_contexts_)/sizeof((all_locks_with_contexts_)[0] (0x40, 0x40) #0 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_rtl_report.cc:42 (libtsan.so.0+0x00071793) #1 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_rtl_report.cc:42 (libtsan.so.0+0x0007179b) #2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_common.cc:72 (libtsan.so.0+0x000761b3) #3 __sanitizer::DeadlockDetectorTLS__sanitizer::TwoLevelBitVector1ul, __sanitizer::BasicBitVectorunsigned long ::addLock(unsigned long, unsigned long, unsigned int) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:65 (libtsan.so.0+0x00079eed) #4 __sanitizer::DeadlockDetector__sanitizer::TwoLevelBitVector1ul, __sanitizer::BasicBitVectorunsigned long ::onLockAfter(__sanitizer::DeadlockDetectorTLS__sanitizer::TwoLevelBitVector1ul, __sanitizer::BasicBitVectorunsigned long *, unsigned long, unsigned int) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:214 (libtsan.so.0+0x00079eed) #5 __sanitizer::DD::MutexAfterLock(__sanitizer::DDCallback*, __sanitizer::DDMutex*, bool, bool) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector1.cc:162 (libtsan.so.0+0x00079eed) #6 __tsan::MutexLock(__tsan::ThreadState*, unsigned long, unsigned long, int, bool) ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_rtl_mutex.cc:177 (libtsan.so.0+0x0006e1e5) #7 pthread_mutex_lock ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2993 (libtsan.so.0+0x000354c7) #8 interlockedSet(long*, long) /home/ed/OPCToolboxV5/Source/Core/TBUtil/Platforms.cpp:55 (CPPTestClient+0x00ee1f06) #9 TB5Util::Sync::lock() include/Sync.h:218 (CPPTestClient+0x00810842) [...] #19 pthread_start platforms/linux/opcua_p_thread.c:63 (CPPTestClient+0x00fb7403) #20 __tsan_thread_start_func ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_interceptors.cc:885 (libtsan.so.0+0x00023a69) #21 start_thread null (libpthread.so.0+0x7e99) #22 __clone null (libc.so.6+0x000f42ec)
[Bug sanitizer/64350] TSAN fails after stress-testing for a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #1 from Dmitry Vyukov dvyukov at google dot com --- I've fixed a bunch of bugs in deadlock detector just few hours ago. Please re-test with these fixes: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_deadlock_detector.h?r1=224518r2=224517pathrev=224518 http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_deadlock_detector.h?r1=224519r2=224518pathrev=224519 I've also added a random stress test, and I think I saw your crash during testing. It does not happen for me with the fixes.
[Bug libstdc++/64351] New: std::uniform_real_distributionfloat(0, 1) returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64351
Bug ID: 64351
Summary: std::uniform_real_distributionfloat(0, 1) returns 1
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: info at jmeng dot de
I'm seeing std::uniform_real_distributionfloat(0, 1) return 1 even though the
standard seems to say it shouldn't:
A uniform_real_distribution random number distribution produces random numbers
x, a ≤ x b
(I looked at the draft available here: http://www.open-std.org/JTC1/SC22/WG21/
or specifically here:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3242.pdf)
There is a relatively minimal working example you can try here:
http://coliru.stacked-crooked.com/a/4ca5b4ac05e990ff
Or, if you prefer to see the code directly:
// This program outputs 1, but uniform_real_distribution is supposed
// to return values in [0, 1) (the half open interval).
#include random
#include cstdint
#include iostream
int main()
{
std::mt19937 rng(8890);
std::uniform_real_distributionfloat dist;
uint64_t num_1 = 0;
for (uint64_t i = 0; i 39975715; ++i)
{
if (dist(rng) == 1.f)
++num_1;
}
std::cout num_1 std::endl;
return 0;
}
Note that there is a related note in this bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43660#c2
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- The bug is new rematerialization sub-pass in LRA. I'll be working on it.
[Bug c++/64352] New: [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352
Bug ID: 64352
Summary: [5.0 regression] No SFINAE with deleted function
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Created attachment 34300
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34300action=edit
Minimal testcase
Using:
g++-trunk (GCC) 5.0.0 20141218 (experimental)
Testcase:
templatebool B struct bool_type
{ static constexpr bool value = B; };
using true_type = bool_typetrue;
using false_type = bool_typefalse;
templatetypename T T declval();
templatetypename... struct void_ { using type = void; };
templatetypename... I using void_t = typename void_I...::type;
templatetypename _Tp, typename = void
struct _Has_addressof_free: false_type { };
templatetypename _Tp
struct _Has_addressof_free
_Tp, void_tdecltype( operator(declvalconst _Tp()) )
: true_type { };
struct foo {};
void operator(foo) = delete;
int main()
{
static_assert( !_Has_addressof_freeint::value, );
// error: use of deleted function 'void operator(foo)'
static_assert( _Has_addressof_freefoo::value, );
}
This produces the following:
$ g++-trunk -std=c++11 main.cpp
main.cpp: In function 'int main()':
main.cpp:17:33: error: use of deleted function 'void operator(foo)'
_Tp, void_tdecltype( operator(declvalconst _Tp()) )
^
main.cpp:21:6: note: declared here
void operator(foo) = delete;
^
main.cpp:27:5: error: static assertion failed:
static_assert( _Has_addressof_freefoo::value, );
^
I'm not entirely sure this is a regression, e.g. libstdc++'s
testsuite/experimental/optional/observers/2.cc is very similar
but passes. I'm working on experimental/optional however and
I ended up tripping over this, and I didn't touch the
_Has_addressof_* stuff. It is copied (almost) verbatim here,
but not the declval/true_type/false_type/[__]void[_t] bits,
in case that's of any help.
Changing the deleted definition with e.g. a dummy definition
('{}') makes the program compiles as expected.
[Bug c++/64251] [5 Regression] Chromium build error only with --enable-checking=yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64251 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-18 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851
--- Comment #11 from Martin Liška marxin at gcc dot gnu.org ---
Hello.
The problem is caused by missing static-chain in newly created GIMPLE_CALL in
expand_thunk:
fpi (struct array7_integer(kind=4) xx1, struct array7_t yy1)
{
bb 2:
fpa (xx1_2(D), yy1_3(D)); [tail call]
return;
}
where:
main (integer(kind=4) argc, character(kind=1) * * argv)
{
...
fpa (desc.2, desc.3); [static-chain: FRAME.7]
fpi (desc.4, desc.5); [static-chain: FRAME.7]
...
}
I've been testing following patch that stops ICF for such kind of situations:
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index b193200..7faaf56 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -685,6 +685,14 @@ sem_function::merge (sem_item *alias_item)
return 0;
}
+ if (DECL_STATIC_CHAIN (alias-decl))
+{
+ if (dump_file)
+ fprintf (dump_file, Thunk creation is risky for static-chain
functions.\n\n);
+
+ return 0;
+}
+
alias-icf_merged = true;
ipa_merge_profiles (local_original, alias);
alias-create_wrapper (local_original);
Thanks,
Martin
[Bug c++/63889] [5 Regression] Ice with redundant static in class scope constexpr variable template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63889 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Kai Tietz from comment #4) is_ok has two levels of template parameters: its own and those for A. An instantiation needs to provide both levels of args as well. It seems that we're missing a call to add_outermost_template_args for variable templates.
[Bug target/64011] Fail to compile pr48335-2.c on big-endian where bit insert instruction supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011 --- Comment #2 from Jiong Wang jiwang at gcc dot gnu.org --- the problem is we do overflow checking at the start of store_bit_field_1, but that only check the situation where the field lies completely outside the register, while there do have situation where the field lies partialy in the register, we need to adjust bitsize for this partial overflow situation in store_bit_field_using_insv. will send out patch after testing ok
[Bug c++/64353] New: ICE: in execute_todo, at passes.c:1986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353
Bug ID: 64353
Summary: ICE: in execute_todo, at passes.c:1986
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at os dot inf.tu-dresden.de
The following code generates an ICE:
class C
{
int y, x;
void i();
bool __attribute__((const)) xx() { return x; }
};
void C::i()
{
if (xx())
x = 1;
}
$ g++ -c -O2 t.i
t.i: In member function ‘void C::i()’:
t.i:12:1: internal compiler error: in execute_todo, at passes.c:1986
}
^
0xbc7b28 execute_todo
../../gcc/gcc/passes.c:1986
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.
$ g++ --version
g++ (GCC) 5.0.0 20141218 (experimental)
Admittedly the attribute((const)) should not be there. Also, removing 'y' will
also not emit an ICE.
[Bug sanitizer/64354] New: no preprocessor symbol __SANITIZE_THREAD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354 Bug ID: 64354 Summary: no preprocessor symbol __SANITIZE_THREAD__ Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: rrh at newrelic 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 compiling gcc -fsanitize=thread does not pre-define preprocessor symbol __SANITIZE_THREAD__ (bad) however, compiling gcc -fsanitize=address does pre-define preprocessor symbol __SANITIZE_ADDRESS__ (good) The situations should be symmetric. I would suggest adding __SANITIZE_THREAD__ rather than deleting __SANITIZE_ADDRESS__.
[Bug c++/64352] [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-18 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/61402] -Wsequence-point doesn't notice unsequenced lambda init and function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61402 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|[5 Regression][C++1y] |-Wsequence-point doesn't |Init-capture with side |notice unsequenced lambda |effect not working for some |init and function argument |types | --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Updating summary.
[Bug c++/60955] [4.9/5 Regression] Erroneous warning about taking address of register with std=c++1y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60955 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Dec 18 17:53:55 2014 New Revision: 218871 URL: https://gcc.gnu.org/viewcvs?rev=218871root=gccview=rev Log: /cp 2014-12-18 Paolo Carlini paolo.carl...@oracle.com PR c++/60955 * pt.c (struct warning_sentinel): Move it... * cp-tree.h: ... here. * semantics.c (force_paren_expr): Use it. /testsuite 2014-12-18 Paolo Carlini paolo.carl...@oracle.com PR c++/60955 * g++.dg/warn/register-parm-1.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/register-parm-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #8 from Dmitry Vyukov dvyukov at google dot com --- Is there any progress on this? Is it fixed? I've hit this issue in ThreadSanitizer. It intercepts __tls_get_addr and then code that uses MOVDQA [rbp] crashes. I remember that I hit it previously in some other context as well.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org Summary|[OOP] copy class(*) |[OOP] runtime segfault with |component from type with a |CLASS(*), INTENT(OUT) dummy |subroutine |argument --- Comment #2 from janus at gcc dot gnu.org --- I could boil it down to this much simpler case: PROGRAM main IMPLICIT NONE INTEGER :: x, y x = 5 CALL copy(x,y) PRINT *,y contains SUBROUTINE copy(a,b) integer, INTENT(IN) :: a CLASS(*), INTENT(OUT) :: b SELECT TYPE(b); TYPE IS(integer) b = a END SELECT END SUBROUTINE END Segfaults with 4.8, 4.9 and trunk. Earlier versions don't support unlimited polymorphism. Had a quick look over the dump, but could not directly see where things go wrong.
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz --- Yep, I am slowly working on that: still need to finish upatin ipa passes for per-function flags (ipa-reference/ipa-icf are two remaining) and we need to figure out what to do with flags that arenot marked Optimization but still affects codegen. Honza https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Note that we should update the documentation about this change (and throw away all option handling of optimize/target attribute handled options from lto-wrapper, or rather move all of that handling to lto1). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #56 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Thu Dec 18 20:12:44 2014 New Revision: 218873 URL: https://gcc.gnu.org/viewcvs?rev=218873root=gccview=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/darwin-c.c branches/gcc-4_8-branch/gcc/config/darwin-driver.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
[Bug fortran/64355] New: ICE (segfault) in gfc_zero_size_array with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64355 Bug ID: 64355 Summary: ICE (segfault) in gfc_zero_size_array with -fcoarray=single Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following program ICEs (segfaults) in 0x607cbb gfc_zero_size_array ../../gcc/fortran/arith.c:1637 when compiled with gfortran -fcoarray=single module m type t integer, allocatable :: a(:) end type t end module m program main use m type(t), save :: caf[*] interface subroutine sub1(x) import :: t type(t) :: x[*] end subroutine sub1 end interface call sub1(caf) end program main subroutine sub1(x) use m type(t) :: x[*] end subroutine sub1
[Bug fortran/64355] [4.9/5 Regression] ICE (segfault) in gfc_zero_size_array with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64355 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 Known to work||4.8.4 Summary|ICE (segfault) in |[4.9/5 Regression] ICE |gfc_zero_size_array with|(segfault) in |-fcoarray=single|gfc_zero_size_array with ||-fcoarray=single Ever confirmed|0 |1 Known to fail||4.9.3, 5.0 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.9.3 and trunk (5.0). 4.8.4 compiles the code without error.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Dec 18 20:49:44 2014 New Revision: 218874 URL: https://gcc.gnu.org/viewcvs?rev=218874root=gccview=rev Log: 2014-12-18 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/64291 * lra-remat.c (bad_for_rematerialization_p): Add UNPSEC_VLOATILE. (create_cands): Process only output reload insn with potential cands. 2014-12-18 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/64291 * testsuite/gcc.target/i386/pr64291-[12].c: New tests. Added: trunk/gcc/testsuite/gcc.target/i386/pr64291-1.c trunk/gcc/testsuite/gcc.target/i386/pr64291-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-remat.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209
--- Comment #3 from janus at gcc dot gnu.org ---
-fdump-tree-original shows the following dump of the copy function (with
gfortran 4.8):
copy (integer(kind=4) restrict a, struct __class__STAR restrict b)
{
{
integer(kind=4) * __tmp_INTEGER_4;
(void) __builtin_memcpy (b-_data, (void *) b-_vptr-_def_init, (unsigned
long) b-_vptr-_size);
switch (b-_vptr-_hash)
{
case 177599:;
__tmp_INTEGER_4 = (integer(kind=4) *) b-_data;
*__tmp_INTEGER_4 = *a;
L.5:;
goto L.3;
}
L.3:;
L.2:;
L.1:;
}
}
With 4.9 and trunk additional code is initialized for calling a finalizer, but
since the failure occurs already with 4.8, the problem must be in here already.
Now, the error goes away if one removes the INTENT(OUT). The only thing that
changes in the dump is that the __builtin_memcpy call is removed, which means
that this line must be the cuplrit.
After staring at it for a while, I concluded that the call to __builtin_memcpy
itself looks fine. The problem is that the _def_init component is NULL in the
case at hand (which can be seen the full dump, not shown here).
So I guess all were missing is a line like
if (b-_vptr-_def_init != NULL)
before the __builtin_memcpy.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- Thanks!
[Bug fortran/64355] [4.9/5 Regression] ICE (segfault) in gfc_zero_size_array with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64355
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
The problem arises in interface.c at 1210.
if (s1-as-type == AS_EXPLICIT)
for (i = 0; i s1-as-rank + s1-as-corank; i++)
{
shape1 = gfc_subtract (gfc_copy_expr (s1-as-upper[i]),
gfc_copy_expr (s1-as-lower[i]));
shape2 = gfc_subtract (gfc_copy_expr (s2-as-upper[i]),
gfc_copy_expr (s2-as-lower[i]));
(gdb) print *s1-as
$4 = {rank = 0, corank = 1, type = AS_EXPLICIT, cotype = AS_EXPLICIT,
lower = {0x20348b240, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, upper = {0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0}, cray_pointee = false, cp_was_assumed = false}
(gdb) print *s2-as
$5 = {rank = 0, corank = 1, type = AS_EXPLICIT, cotype = AS_EXPLICIT,
lower = {0x20348b540, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, upper = {0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0}, cray_pointee = false, cp_was_assumed = false}
Both s1-as-upper[0] and s2-as-upper[0] are NULL. gfc_copy_expr()
returns NULL, so the code is gfc_subtract(NULL, 0x20348b240). Well,
gfc_subtract isn't expecting a NULL.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- The following patch is sufficient to make the reduced test case in comment 2 work: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(Revision 218874) +++ gcc/fortran/trans-expr.c(Arbeitskopie) @@ -980,6 +980,9 @@ gfc_trans_class_init_assign (gfc_code *code) src.expr = gfc_build_addr_expr (NULL_TREE, src.expr); tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz.expr); + + tmp = build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp), +src.expr, tmp, build_empty_stmt (input_location)); } if (code-expr1-symtree-n.sym-attr.optional However, the original test case in comment 0 still segfaults, so there seems to be yet another problem.
[Bug c++/64251] [5 Regression] Chromium build error only with --enable-checking=yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64251 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 18 22:22:36 2014 New Revision: 218876 URL: https://gcc.gnu.org/viewcvs?rev=218876root=gccview=rev Log: PR c++/64251 * decl2.c (mark_used): Don't mark if in_template_function. Added: trunk/gcc/testsuite/g++.dg/template/non-dependent14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug c++/64352] [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 18 22:22:42 2014 New Revision: 218877 URL: https://gcc.gnu.org/viewcvs?rev=218877root=gccview=rev Log: PR c++/64352 * pt.c (tsubst_copy_and_build): Pass complain to mark_used. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #12 from howarth at bromo dot med.uc.edu --- I can confirm that the proposed patch from comment 11 along with the one from comment 5 eliminates all of the fortran testsuite regressions on x86_64-apple-darwin14 at r218871.
[Bug c++/54442] [4.8/4.9 Regression] Const overloads resolution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54442 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.2.0, 4.3.0, 4.4.0 Keywords||ice-on-valid-code Last reconfirmed||2014-12-18 CC||reichelt at gcc dot gnu.org Ever confirmed|0 |1 Summary|Const overloads resolution |[4.8/4.9 Regression] Const |failure |overloads resolution ||failure Target Milestone|--- |4.8.4 Known to fail||4.5.0, 4.6.0, 4.7.0, 4.8.0 --- Comment #5 from Volker Reichelt reichelt at gcc dot gnu.org --- Marc's testcase from comment#2 demonstrates a regression that was introduced in GCC 4.5.0.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
The following patch is sufficient to make the reduced test case in comment 2
work:
... but unfortunately it caused a number of testsuite regressions. The
following variant is clean:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 218874)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -943,7 +943,7 @@ tree
gfc_trans_class_init_assign (gfc_code *code)
{
stmtblock_t block;
- tree tmp;
+ tree tmp, cond;
gfc_se dst,src,memsz;
gfc_expr *lhs, *rhs, *sz;
@@ -980,6 +980,12 @@ gfc_trans_class_init_assign (gfc_code *code)
src.expr = gfc_build_addr_expr (NULL_TREE, src.expr);
tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz.expr);
+
+ cond = fold_build2_loc (input_location, NE_EXPR, boolean_type_node,
+ src.expr, fold_convert (TREE_TYPE (src.expr),
+ null_pointer_node));
+ tmp = build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp), cond, tmp,
+build_empty_stmt (input_location));
}
if (code-expr1-symtree-n.sym-attr.optional
Still, it does not cure the segfault in comment 0.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 --- Comment #6 from janus at gcc dot gnu.org --- Here is a reduced test case for the remaining segfault: PROGRAM main IMPLICIT NONE INTEGER :: copy_x(3) CALL copy(1,copy_x) PRINT *, copy_x CONTAINS SUBROUTINE copy(x,a) integer, INTENT(IN) :: x CLASS(*), INTENT(OUT) :: a(:) SELECT TYPE(a); TYPE IS(integer) a(:) = x END SELECT END SUBROUTINE END PROGRAM It's a very similar scheme as in comment #2, only this time we have an array-valued CLASS(*), INTENT(OUT) argument. I think the problem is with _def_init being NULL again. For the array case here the dump shown a line like: a-_vptr-_copy (a-_vptr-_def_init, a-_data); Again we need a conditional check for _def_init being non-NULL.
[Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This works in mainline. I'm adding the testcase and closing the bug.
[Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Dec 18 23:43:46 2014 New Revision: 218878 URL: https://gcc.gnu.org/viewcvs?rev=218878root=gccview=rev Log: 2014-12-18 Paolo Carlini paolo.carl...@oracle.com PR c++/59204 * g++.dg/cpp0x/sfinae53.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae53.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done. Note: in r217250 Jason implemented the resolution of Core/1558.
[Bug c++/64105] [4.9/5 Regression] ICE: in strip_typedefs, at cp/tree.c:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64105 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Dec 18 23:53:15 2014 New Revision: 218879 URL: https://gcc.gnu.org/viewcvs?rev=218879root=gccview=rev Log: PR c++/64105 * parser.c (cp_parser_simple_type_specifier): Make auto parameter before -std=c++14 an error. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 Ever confirmed|0 |1 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- This isn't a regression, thus for the time being I'm going to simply add a testcase. If you want to argue for a backport, please figure out the commit which fixed the bug and send a message to gcc-patches.
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Dec 19 00:02:05 2014 New Revision: 218880 URL: https://gcc.gnu.org/viewcvs?rev=218880root=gccview=rev Log: 2014-12-18 Paolo Carlini paolo.carl...@oracle.com PR c++/63723 * g++.dg/cpp0x/sfinae54.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae54.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug target/60563] FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #10 from howarth at bromo dot med.uc.edu --- (In reply to Iain Sandoe from comment #9) sadly, this seems to be a ld64 bug - present when using uncompressed EH (which is the default for GCC on darwin). Have you opened a radar upstream for this ld64 bug?
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- I can confirm that the proposed patch from comment 11 along with the one from comment 5 eliminates all of the fortran test suite regressions on x86_64-apple-darwin14 at r218871. Confirmed. Apparently the patch in comment 11 also fixes the cats failures (pr63852), see https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02352.html. Thanks for the fix.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to thopre01 from comment #12)
That's good, it means the pattern is recognized. Is there an optab defined
for bswap16?
Nope. Just this:
(define_insn rotlhi3_8
[(set (match_operand:HI 0 arith_reg_dest =r)
(rotate:HI (match_operand:HI 1 arith_reg_operand r)
(const_int 8)))]
TARGET_SH1
swap.b%1,%0
[(set_attr type arith)])
If I remember correctly, there was something that would check whether it can
use the rotate pattern instead of a bswaphi2. After adding the following
pattern:
(define_expand bswaphi2
[(set (match_operand:HI 0 arith_reg_dest)
(bswap:HI (match_operand:HI 1 arith_reg_operand)))]
TARGET_SH1
{
if (!can_create_pseudo_p ())
FAIL;
else
{
emit_insn (gen_rotlhi3_8 (operands[0], operands[1]));
DONE;
}
})
it looks much better. The cases above work, except for the signed short. On
SH the bswap:HI HW insn actually doesn't modify the upper 16 bit of the 32 bit
register. What it does is:
unsigned int test_0999 (unsigned int a, unsigned int b)
{
return (a 0x) | ((a 0xFF00) 8) | ((a 0xFF) 8);
}
I was afraid that using a bswap:HI will result in unnecessary code around it:
mov.l.L6,r0 ! r0 = 0x
andr4,r0
extu.wr4,r4
swap.br4,r4
rts
orr4,r0
In my case, combine is looking for the pattern:
Failed to match this instruction:
(set (reg:SI 172 [ D.1356 ])
(ior:SI (ior:SI (and:SI (ashift:SI (reg/v:SI 170 [ a ])
(const_int 8 [0x8]))
(const_int 65280 [0xff00]))
(zero_extract:SI (reg/v:SI 170 [ a ])
(const_int 8 [0x8])
(const_int 8 [0x8])))
(and:SI (reg/v:SI 170 [ a ])
(const_int -65536 [0x]
Which should then work.
Same as the other pattern, can you try to print n-n in hex with this new
limit? My guess is that the pattern is now recognized but fails later for
the same reason as above.
With increased limit, the number is/was the same. The bswap:HI expander was
missing. Thanks!
[Bug c++/64356] New: Some constexpr expressions not recognized as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64356
Bug ID: 64356
Summary: Some constexpr expressions not recognized as constexpr
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
Consider the following snippet:
templatesize_t N
constexpr uint64_t f(const char (x)[N]) {
uint64_t s = 0;
#if defined(FAILS)
for(uint64_t c : x)
s += c;
#else
for(size_t i = 0; i N; ++i)
s += x[i];
#endif
return s;
}
templatesize_t N
constexpr uint64_t g(const char (x)[N]) {
char y[N] = {0};
for(size_t i = 0; i N; ++i)
y[i] = x[i];
#if defined(FAILS)
return f(y);
#else
return f(x);
#endif
}
constexpr auto x = g(__DATE__);
When FAILS is defined, GCC (trunk, 20141219) refuses to recognize x as a
constant expression, while with FAILS undefined it works as expected. Clang
accepts both variants.
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
--- Comment #8 from Tavian Barnes tavianator at gmail dot com ---
Actually it is a regression: according to http://gcc.godbolt.org/, GCC 4.6.4
compiled it correctly with -std=c++0x and
typedef decltype(helperFrom, To(0)) type;
instead of
using type = decltype(helperFrom, To(0));
while still allowing
int x{1.0};
[Bug tree-optimization/64357] New: ICE at -Os on x86_64-linux-gnu in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64357
Bug ID: 64357
Summary: ICE at -Os on x86_64-linux-gnu in
check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:579
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-Os on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20141218 (experimental) [trunk revision 218871] (GCC)
$
$ gcc-trunk -O1 -c small.c
$ gcc-trunk -O2 -c small.c
$ gcc-4.9 -Os -c small.c
$
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn3’:
small.c:25:1: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:579
fn3 ()
^
0xbb7c5f check_loop_closed_ssa_use
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:579
0xbb97da verify_loop_closed_ssa(bool)
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:624
0x9a8026 execute_function_todo
../../gcc-trunk/gcc/passes.c:1955
0x9a88b3 execute_todo
../../gcc-trunk/gcc/passes.c:1997
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.
$
---
int a, b, c, d, e, f;
long long
fn1 (int p)
{
return p ? p : 1;
}
static int
fn2 ()
{
lbl:
for (; f;)
return 0;
for (;;)
{
for (b = 0; b; ++b)
if (d)
goto lbl;
c = e;
}
}
void
fn3 ()
{
for (; a; a = fn1 (a))
{
fn2 ();
e = 0;
}
}
