[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #11 from rguenther at suse dot de --- On Mon, 15 Jan 2018, olegendo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 > > --- Comment #9 from Oleg Endo --- > This is weird. If I remove empty lines, or rename the paths in the # line > markers in the .ii file, the error sometimes disappears... Smells odd indeed. Can you try building with --enable-valgrind-annotations and run valgrind on the thing? My theory would still be a wild write somewhere... But to be honest the compression code is a mess ...
[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #10 from rguenther at suse dot de --- On Mon, 15 Jan 2018, olegendo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 > > --- Comment #8 from Oleg Endo --- > (In reply to rguent...@suse.de from comment #7) > > > > If you can produce a testcase and attach that that would be nice. > > I'm trying. But it's gonna take ages. Have to hand-strip the .ii file line > by > line ... or else the error disappears. > > I'm using system's zlib (version 1.2.8, stock ubuntu 16.04). Could that be a > problem? I don't think so.
[Bug libstdc++/83853] conditional_variable induces data_race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83853 --- Comment #4 from rene.r...@fu-berlin.de --- (In reply to Jonathan Wakely from comment #3) > (In reply to rene.rahn from comment #2) > > It basically says, that while T2 is currently destroying the condition > > variable, T1 is still accessing it by calling notify on it??? > > Yes. > > > Note that if the condition variable is put before the while loop and reset > > in every iteration, it performs without warnings on unix, but still dead > > locks on mac. > > If I put the notify of T1 inside of the lock_guard it will also run without > > data race warnings and does not dead lock on mac. > > That seems like the correct fix. The publisher can destroy the condition > variable as soon as Job::wait() returns, which can happen before the > notify_all() call begins. That's a logic error in your program. Calling > notify_all() while the mutex is still locked prevents that. Alright, I am truly sorry. I kind of mist out the last paragraph in the documentation of http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one, which is literally the behaviour I am modelling. So that is definitely a bug in the user code and not in the library. So the same will fix the OSX problem. > > > So there is a little error that might happen in the following situation. > > After T1 updates the shared bool, it leaves the lock. > > So here it could potentially happen, that T1 is preempted and T2 has a > > spurious wakeup but now acquiring the lock, as the predicate returns true > > now. In this case T2 can continue in the loop and destroy the lock, and T1 > > will call notify on it while T2 already destroys it. > > Yes, that is one explanation. Even if it didn't happen often, your code > allows it to happen sometimes, which is a bug. I again would totally agree, and yet > > > Having said that, this seems unlikely to happen so often, does it. I mean I > > am not very confident about how often something like a spurious wake really > > happens, especially as between wait and notify there are only a few cycles. > > It can still happen without a spurious wake up. The call to > pthread_cond_broadcast isn't an atomic operation, it can wake the waiting > thread (which then destroys the pthread_cond_t) and then perform further > reads from the variable before returning. > > > I would really like to know, it is in general forbidden, that the waiting > > thread owns the condition variable as his stack memory might get > > inaccessible when it is put into wait. I couldn't find any information > > regarding this. > > I'm not sure I understand what you're asking, because your code doesn't > destroy the condition variable until after the wait returns. The object > isn't invalidated when "put into wait" only after the wait returns. > > It's not generally forbidden for the waiting thread to own the condition > variable, you just need to ensure no other thread is calling a function on > an object being destroyed (which is generally true for any object, although > std::condition_variable does allow destruction before all waiters have > returned, as long as they've been notified, see > http://en.cppreference.com/w/cpp/thread/condition_variable/ > ~condition_variable -- i.e. std::condition_variable relaxes the usual rules > about accessing an object being destroyed). > > > > Or is there a general user error on my site, which I might not see (because > > it is not a trivial case). I am truly sorry if that would be the case. > > Or is it possible that there is kind of a bug in the condition variable > > implementation, such that the signalling is not broadcasted correctly? > > I think that is very unlikely. Especially if you're seeing the bug on > GNU/Linux and OS X, because they have different implementations of > pthread_cond_t (and libstdc++ just uses that). > > Also you didn't state which standard library you're using with clang, if > it's not libstdc++ then it's even more unlikely that you're seeing the same > bug with two entirely different implementations of std::condition_variable > and pthread_cond_t. > > I don't see any evidence of a bug here. Yes, me neither!!! Sorry, again for bothering, but I am glad for the very competent answers. Helped a lot.
[Bug other/83826] Fixinclude creates redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83826 --- Comment #2 from coypu --- Created attachment 43145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43145&action=edit fixed sys/types.h --- Comment #3 from coypu --- Created attachment 43146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43146&action=edit Normal sys/types.h
[Bug other/83826] Fixinclude creates redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83826 --- Comment #2 from coypu --- Created attachment 43145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43145&action=edit fixed sys/types.h
[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 Joshua Kinard changed: What|Removed |Added Version|7.1.0 |7.2.0 Version|7.1.0 |7.2.0 --- Comment #4 from Joshua Kinard --- After a week of bisecting, it looks like PR59461 is what causes this regression. Indeed, looking at the comments on #59461, Matthew Fortune thought that N64 could have been broken, and I am assuming that was fixed in PR78660? This issue I am seeing under N32 might be something different. Here is the git bisect history I followed: start: bad da8dff89fa93 (HEAD) good 45dd06cef49f (gcc-6_4_0-release) 1. a050099a416f (good) 2. 873a9b6435c7 (bad) 3. eedf6f96c360 (good) 4. 8139561f6fe6 (bad) 5. c02417adbaf1 (good) 6. 63c8aefc8cbf (bad) 7. 48baf518aeb5 (skip) 7. 36bb9d71a876 (good) 8. 44618e466be5 (bad) 9. 682d2b7ee96c (bad) 10. 4699a580bd1f (bad) 11. 15bd70ad1a73 (good) 12. 9dbb7881f36e (bad) 13. 454decdf75fc (bad) 14. 1998c023a3ed (bad) Which then yields: 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 Author: ebotcazou Date: Fri Nov 11 22:38:33 2016 + PR rtl-optimization/59461 * doc/rtl.texi (paradoxical subregs): Add missing word. * combine.c (reg_nonzero_bits_for_combine): Do not discard results in modes with precision larger than that of last_set_mode. * rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS is set and LOAD_EXTEND_OP is appropriate, propagate results from inner REGs to paradoxical SUBREGs. (num_sign_bit_copies1) : Likewise. Check that the mode is not larger than a word before invoking LOAD_EXTEND_OP on it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 dd706ac97469731dec045095572859552211457b 59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M gcc Note that part of the way through the bisect (~step 8), I had to manually apply the patch from PR78338 to fix a build error. The first attempt at step 7 also had to be skipped one time due to another build error that I couldn't find much on. I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually completes or not and report back. Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA. --- Comment #5 from Joshua Kinard --- After a week of bisecting, it looks like PR59461 is what causes this regression. Indeed, looking at the comments on #59461, Matthew Fortune thought that N64 could have been broken, and I am assuming that was fixed in PR78660? This issue I am seeing under N32 might be something different. Here is the git bisect history I followed: start: bad da8dff89fa93 (HEAD) good 45dd06cef49f (gcc-6_4_0-release) 1. a050099a416f (good) 2. 873a9b6435c7 (bad) 3. eedf6f96c360 (good) 4. 8139561f6fe6 (bad) 5. c02417adbaf1 (good) 6. 63c8aefc8cbf (bad) 7. 48baf518aeb5 (skip) 7. 36bb9d71a876 (good) 8. 44618e466be5 (bad) 9. 682d2b7ee96c (bad) 10. 4699a580bd1f (bad) 11. 15bd70ad1a73 (good) 12. 9dbb7881f36e (bad) 13. 454decdf75fc (bad) 14. 1998c023a3ed (bad) Which then yields: 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 Author: ebotcazou Date: Fri Nov 11 22:38:33 2016 + PR rtl-optimization/59461 * doc/rtl.texi (paradoxical subregs): Add missing word. * combine.c (reg_nonzero_bits_for_combine): Do not discard results in modes with precision larger than that of last_set_mode. * rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS is set and LOAD_EXTEND_OP is appropriate, propagate results from inner REGs to paradoxical SUBREGs. (num_sign_bit_copies1) : Likewise. Check that the mode is not larger than a word before invoking LOAD_EXTEND_OP on it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 dd706ac97469731dec045095572859552211457b 59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M gcc Note that part of the way through the bisect (~step 8), I had to manually apply the patch from PR78338 to fix a build error. The first attempt at step 7 also had to be skipped one time due to another build error that I couldn't find much on. I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually completes or not and report back. Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA.
[Bug middle-end/81443] gcc-7.1.0/MIPS N32: build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 Joshua Kinard changed: What|Removed |Added Version|7.1.0 |7.2.0 Version|7.1.0 |7.2.0 --- Comment #4 from Joshua Kinard --- After a week of bisecting, it looks like PR59461 is what causes this regression. Indeed, looking at the comments on #59461, Matthew Fortune thought that N64 could have been broken, and I am assuming that was fixed in PR78660? This issue I am seeing under N32 might be something different. Here is the git bisect history I followed: start: bad da8dff89fa93 (HEAD) good 45dd06cef49f (gcc-6_4_0-release) 1. a050099a416f (good) 2. 873a9b6435c7 (bad) 3. eedf6f96c360 (good) 4. 8139561f6fe6 (bad) 5. c02417adbaf1 (good) 6. 63c8aefc8cbf (bad) 7. 48baf518aeb5 (skip) 7. 36bb9d71a876 (good) 8. 44618e466be5 (bad) 9. 682d2b7ee96c (bad) 10. 4699a580bd1f (bad) 11. 15bd70ad1a73 (good) 12. 9dbb7881f36e (bad) 13. 454decdf75fc (bad) 14. 1998c023a3ed (bad) Which then yields: 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 Author: ebotcazou Date: Fri Nov 11 22:38:33 2016 + PR rtl-optimization/59461 * doc/rtl.texi (paradoxical subregs): Add missing word. * combine.c (reg_nonzero_bits_for_combine): Do not discard results in modes with precision larger than that of last_set_mode. * rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS is set and LOAD_EXTEND_OP is appropriate, propagate results from inner REGs to paradoxical SUBREGs. (num_sign_bit_copies1) : Likewise. Check that the mode is not larger than a word before invoking LOAD_EXTEND_OP on it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 dd706ac97469731dec045095572859552211457b 59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M gcc Note that part of the way through the bisect (~step 8), I had to manually apply the patch from PR78338 to fix a build error. The first attempt at step 7 also had to be skipped one time due to another build error that I couldn't find much on. I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually completes or not and report back. Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA. --- Comment #5 from Joshua Kinard --- After a week of bisecting, it looks like PR59461 is what causes this regression. Indeed, looking at the comments on #59461, Matthew Fortune thought that N64 could have been broken, and I am assuming that was fixed in PR78660? This issue I am seeing under N32 might be something different. Here is the git bisect history I followed: start: bad da8dff89fa93 (HEAD) good 45dd06cef49f (gcc-6_4_0-release) 1. a050099a416f (good) 2. 873a9b6435c7 (bad) 3. eedf6f96c360 (good) 4. 8139561f6fe6 (bad) 5. c02417adbaf1 (good) 6. 63c8aefc8cbf (bad) 7. 48baf518aeb5 (skip) 7. 36bb9d71a876 (good) 8. 44618e466be5 (bad) 9. 682d2b7ee96c (bad) 10. 4699a580bd1f (bad) 11. 15bd70ad1a73 (good) 12. 9dbb7881f36e (bad) 13. 454decdf75fc (bad) 14. 1998c023a3ed (bad) Which then yields: 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 is the first bad commit commit 1998c023a3ed6c59d8f1eea3a34528a9d6a93fe1 Author: ebotcazou Date: Fri Nov 11 22:38:33 2016 + PR rtl-optimization/59461 * doc/rtl.texi (paradoxical subregs): Add missing word. * combine.c (reg_nonzero_bits_for_combine): Do not discard results in modes with precision larger than that of last_set_mode. * rtlanal.c (nonzero_bits1) : If WORD_REGISTER_OPERATIONS is set and LOAD_EXTEND_OP is appropriate, propagate results from inner REGs to paradoxical SUBREGs. (num_sign_bit_copies1) : Likewise. Check that the mode is not larger than a word before invoking LOAD_EXTEND_OP on it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242326 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 dd706ac97469731dec045095572859552211457b 59c5b8ea5e019c4e25f246a1295b244ba2a50c9a M gcc Note that part of the way through the bisect (~step 8), I had to manually apply the patch from PR78338 to fix a build error. The first attempt at step 7 also had to be skipped one time due to another build error that I couldn't find much on. I'll try reverting the patch for PR59461 on gcc-7 HEAD and see if that actually completes or not and report back. Also confirmed this happens on both MIPS-III and MIPS-IV (r12000) ISA.
[Bug testsuite/83462] [8 regression] c-c++-common/Warray-bounds-3.c fails on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83462 Martin Sebor changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #7 from Martin Sebor --- *** Bug 83880 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83880] FAIL: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for warnings, line 67)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83880 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- The failure on line 67 is a duplicate of bug 83462, and its root cause is bug 83543 (as per pr83462 comment 4). *** This bug has been marked as a duplicate of bug 83462 ***
[Bug rtl-optimization/83771] [8 Regression] ICE: verify_flow_info failed (error: non-cold basic block 3 reachable only by paths crossing the cold partition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83771 --- Comment #2 from Arseny Solokha --- I cannot reproduce it anymore on the current trunk (r256677).
[Bug tree-optimization/83887] New: [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 3 should be 21, not 18)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83887
Bug ID: 83887
Summary: [8 Regression] [graphite] ICE in verify_dominators, at
dominance.c:1184 (error: dominator of 3 should be 21,
not 18)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180114 snapshot (r256677) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast) -floop-nest-optimize -fno-tree-loop-im:
int z4, g7;
void
x3 (int my)
{
while (my < 2)
{
for (z4 = 0; z4 < 2; ++z4)
{
}
if (my != 0)
for (g7 = 0; g7 < 2; ++g7)
{
}
++my;
}
}
% gcc-8.0.0-alpha20180114 -O1 -floop-nest-optimize -fno-tree-loop-im -c
oiutipaf.c
oiutipaf.c: In function 'x3':
oiutipaf.c:4:1: error: dominator of 3 should be 21, not 18
x3 (int my)
^~
during GIMPLE pass: graphite
oiutipaf.c:4:1: internal compiler error: in verify_dominators, at
dominance.c:1184
0x5dbe5d verify_dominators(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/dominance.c:1184
0x8f5495 checking_verify_dominators
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/dominance.h:76
0x8f5495 calculate_dominance_info(cdi_direction)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/dominance.c:746
0xd231b6 update_ssa(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-into-ssa.c:3332
0x1445a70 graphite_transform_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/graphite.c:425
0x1446e10 graphite_transforms
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/graphite.c:475
0x1446e10 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/graphite.c:552
[Bug c++/83588] [6/7 Regression] struct with two flexible arrays causes an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83588 Martin Sebor changed: What|Removed |Added Keywords||patch Summary|[6/7/8 Regression] struct |[6/7 Regression] struct |with two flexible arrays|with two flexible arrays |causes an internal compiler |causes an internal compiler |error |error --- Comment #4 from Martin Sebor --- Fixed for GCC 8.0 via r256721.
[Bug c++/83588] [6/7/8 Regression] struct with two flexible arrays causes an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83588 --- Comment #3 from Martin Sebor --- Author: msebor Date: Tue Jan 16 03:02:34 2018 New Revision: 256721 URL: https://gcc.gnu.org/viewcvs?rev=256721&root=gcc&view=rev Log: PR c++/83588 - struct with two flexible arrays causes an internal compiler error gcc/cp/ChangeLog: PR c++/83588 * class.c (find_flexarrays): Make a record of multiple flexible array members. gcc/testsuite/ChangeLog: PR c++/83588 * g++.dg/ext/flexary28.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/flexary28.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/83886] New: [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83886
Bug ID: 83886
Summary: [8 Regression] ICE in
cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4433
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180114 snapshot (r256677) ICEs when compiling the following
snippet w/ -O2 -floop-parallelize-all -fmodulo-sched -fno-tree-forwprop
-fno-tree-loop-im:
int ga, as;
void
xj (int sm, int vs)
{
if (0)
for (;;)
while (sm < 1)
for (as = 0; as < 1; ++as)
{
o3:
;
}
while (vs < 1)
{
for (ga = 0; ga < 9; ++ga)
{
}
++vs;
}
goto o3;
}
% gcc-8.0.0-alpha20180114 -O2 -floop-parallelize-all -fmodulo-sched
-fno-tree-forwprop -fno-tree-loop-im -c pa4nrhpq.c
during RTL pass: sms
pa4nrhpq.c: In function 'xj':
pa4nrhpq.c:25:1: internal compiler error: in
cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4433
}
^
0x5ce23b cfg_layout_redirect_edge_and_branch
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfgrtl.c:4433
0x8990f8 cfg_layout_redirect_edge_and_branch_force
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfgrtl.c:4443
0x8825b3 redirect_edge_and_branch_force(edge_def*, basic_block_def*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfghooks.c:486
0x882fbd make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void
(*)(basic_block_def*))
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfghooks.c:893
0x88b74b merge_latch_edges
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfgloop.c:780
0x88b74b disambiguate_multiple_latches
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfgloop.c:831
0x88b74b disambiguate_loops_with_multiple_latches()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/cfgloop.c:844
0xb0aec4 apply_loop_flags
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/loop-init.c:54
0xb0b8ec loop_optimizer_init(unsigned int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/loop-init.c:123
0x14ce819 sms_schedule
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/modulo-sched.c:1354
0x14d111f execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/modulo-sched.c:3345
[Bug ada/83885] New: FAIL: gnat.dg/trampoline3.adb scan-assembler-not GNU-stack.*x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83885 Bug ID: 83885 Summary: FAIL: gnat.dg/trampoline3.adb scan-assembler-not GNU-stack.*x Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Executing on host: /home/dave/gnu/gcc/objdir/gcc/gnatmake --GCC=/home/dave/gnu/g cc/objdir/gcc/xgcc --GNATBIND=/home/dave/gnu/gcc/objdir/gcc/gnatbind --GNATLINK= /home/dave/gnu/gcc/objdir/gcc/gnatlink -cargs -B/home/dave/gnu/gcc/objdir/gcc -l args --GCC=/home/dave/gnu/gcc/objdir/gcc/xgcc\ -B/home/dave/gnu/gcc/objdir/gcc\ -margs --RTS=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada -q -f /home/dave /gnu/gcc/gcc/gcc/testsuite/gnat.dg/trampoline3.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -gnatws -c -u -ffat-lto-objects -S -o trampoline3.s (timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/gnatmake --GCC=/home/dave/gnu /gcc/objdir/gcc/xgcc --GNATBIND=/home/dave/gnu/gcc/objdir/gcc/gnatbind --GNATLIN K=/home/dave/gnu/gcc/objdir/gcc/gnatlink -cargs -B/home/dave/gnu/gcc/objdir/gcc -largs --GCC=/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc -margs --RTS=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada -q -f /home/dave /gnu/gcc/gcc/gcc/testsuite/gnat.dg/trampoline3.adb -fno-diagnostics-show-caret - fdiagnostics-color=never -gnatws -c -u -ffat-lto-objects -S -o trampoline3.s Executing on host: /home/dave/gnu/gcc/objdir/gcc/gnatclean -c -q -n trampoline3 (timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/gnatclean -c -q -n trampoline 3 ./trampoline3.ali ./trampoline3.s PASS: gnat.dg/trampoline3.adb (test for excess errors) FAIL: gnat.dg/trampoline3.adb scan-assembler-not GNU-stack.*x I'm not sure that this is correct given the documentation for TARGET_CUSTOM_FUNCTION_DESCRIPTORS but defining it to 1 fixes the fail on linux. Haven't tested on hpux.
[Bug ada/83884] New: FAIL: gnat.dg/check_displace_generation.adb (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83884 Bug ID: 83884 Summary: FAIL: gnat.dg/check_displace_generation.adb (test for excess errors) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/gnatmake --GCC=/home/dave/gnu /gcc/objdir/gcc/xgcc --GNATBIND=/home/dave/gnu/gcc/objdir/gcc/gnatbind --GNATLIN K=/home/dave/gnu/gcc/objdir/gcc/gnatlink -cargs -B/home/dave/gnu/gcc/objdir/gcc -largs --GCC=/home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc -margs --RTS=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada -q -f /home/dave /gnu/gcc/gcc/gcc/testsuite/gnat.dg/check_displace_generation.adb -fno-diagnostic s-show-caret -fdiagnostics-color=never -lm -o ./check_displace_generation.exe +===GNAT BUG DETECTED==+ | 8.0.0 20180114 (experimental) [trunk revision 256677] (hppa-linux-gnu) GCC err or:| | in tree_to_poly_uint64, at tree.h:4284 | | Error detected around /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/check_displ ace_generation.adb:40:4| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/system.ads /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/check_displace_generation.adb /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/a-tags.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/ada.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-stoele.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-exctab.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-stalib.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/a-unccon.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/a-stream.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-soflin.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/a-except.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-parame.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-traent.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-secsta.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-stache.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-addima.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-conca2.ads /home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libada/adainclude/s-stoele.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407 gnatmake: "/home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/check_displace_generation.adb" compilation error compiler exited with status 1 Executing on host: /home/dave/gnu/gcc/objdir/gcc/gnatclean -c -q -n ./check_displace_generation (timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/gnatclean -c -q -n ./check_displace_generation ./check_displace_generation.ali FAIL: gnat.dg/check_displace_generation.adb 3 blank line(s) in output FAIL: gnat.dg/check_displace_generation.adb (test for excess errors) Excess errors: +===GNAT BUG DETECTED==+ | 8.0.0 20180114 (experimental) [trunk revision 256677] (hppa-linux-gnu) GCC error:| | in tree_to_poly_uint64, at tree.h:4284 | | Error detected around /home/dave/gnu/gcc/gcc/gcc/testsuite/gnat.dg/check_displace_generation.adb:40:4| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Similar fails: FAIL: gnat.dg/generic_dispatch.adb 3 blank line(s) in output
[Bug tree-optimization/83883] New: FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store" 2 (found 4 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83883 Bug ID: 83883 Summary: FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store" 2 (found 4 times) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-dse1-details -fno-short-enums -S -o ssa-dse-26.s(timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-dse1-details -fno-short-enums -S -o ssa-dse-26.s PASS: gcc.dg/tree-ssa/ssa-dse-26.c (test for excess errors) FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store" 2 (found 4 times)
[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789 --- Comment #1 from Kaushikp --- Just some additional info on this issue, The powerpc-elf-gcc did not have any issues compiling this testcase with identical options on gcc-7.2.0; powerpc-linux-gcc generated segmentation fault; powerpc64-linux-gcc passed without errors or warnings.
[Bug tree-optimization/83882] New: FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83882 Bug ID: 83882 Summary: FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/pr81715.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -Wframe-larger-than=16384 -S -o pr81715.s(timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/home/dave/gnu/gcc/objdir/gcc/testsuite/g++/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/pr81715.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -Wframe-larger-than=16384 -S -o pr81715.s /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/pr81715.C: In function 'void bar(int, int, int, S, int, int)': /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/pr81715.C:36:1: warning: the frame size of 85740 bytes is larger than 16384 bytes [-Wframe-larger-than=] FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/opt/pr81715.C:36:1: warning: the frame size of 85740 bytes is larger than 16384 bytes [-Wframe-larger-than=]
[Bug c/83881] New: FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83881 Bug ID: 83881 Summary: FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu FAIL: c-c++-common/Wrestrict.c -std=gnu++98 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:683:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Wrestrict.c:761:3: warning: 'void* __builtin_memcpy(void*, const void*, unsigned int)' writing 4 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
[Bug tree-optimization/83880] New: FAIL: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for warnings, line 67)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83880 Bug ID: 83880 Summary: FAIL: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for warnings, line 67) Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/g++1/../../xg++ -B/home/dave/gnu/gcc/objdir/gcc/testsuite/g++1/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -Warray-bounds=2 -Wno-stringop-overflow -ftrack-macro-expansion=0 -S -o Warray-bounds-4.s(timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/testsuite/g++1/../../xg++ -B/home/dave/gnu/gcc/objdir/gcc/testsuite/g++1/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/home/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -Warray-bounds=2 -Wno-stringop-overflow -ftrack-macro-expansion=0 -S -o Warray-bounds-4.s /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c: In function 'void test_memcpy_bounds_memarray_range()': /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c:47:3: warning: 'void* memcpy(void*, const void*, size_t)' offset [6, 8] from the object at 'ma' is out of the bounds of referenced subobject 'MA::a5' with type 'char [5]' at offset 0 [-Warray-bounds] /home/dave/gnu/gcc/gcc/gcc/testsuite/c-c++-common/Warray-bounds-4.c:48:3: warning: 'void* memcpy(void*, const void*, size_t)' offset [6, 10] from the object at 'ma' is out of the bounds of referenced subobject 'MA::a5' with type 'char [5]' at offset 0 [-Warray-bounds] PASS: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for warnings, line 47) PASS: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for warnings, line 48) XFAIL: c-c++-common/Warray-bounds-4.c -std=gnu++98 strcpy (test for warnings, line 66) FAIL: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for warnings, line 67) PASS: c-c++-common/Warray-bounds-4.c -std=gnu++98 (test for excess errors)
[Bug fortran/82257] f951: Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82257 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from lkrupp at gcc dot gnu.org --- Fixed in revision 256720.
[Bug fortran/82257] f951: Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82257 --- Comment #2 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Tue Jan 16 01:09:11 2018 New Revision: 256720 URL: https://gcc.gnu.org/viewcvs?rev=256720&root=gcc&view=rev Log: 2018-01-15 Louis Krupp PR fortran/82257 * interface.c (compare_rank): Don't try to retrieve CLASS_DATA from symbol marked unlimited polymorphic. * resolve.c (resolve_structure_cons): Likewise. * misc.c (gfc_typename): Don't dereference derived->components if it's NULL. 2018-01-15 Louis Krupp PR fortran/82257 * gfortran.dg/unlimited_polymorphic_28.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/misc.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #4 from seurer at gcc dot gnu.org --- One more thing, this only happens on LE and only if the compiler is built --with-cpu=power8 or --with-cpu=power9
[Bug middle-end/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
--- Comment #3 from seurer at gcc dot gnu.org ---
The code below is were the assertion is failing (the line after // WDS test).
I was experimenting a bit and commented out the assertion so I could see what
it was guarding and ... nothing happened, at least I don't think so. The
compiler built and there weren't any unusual failures in the go test cases.
Could it be the assertion isn't really needed?
static inline rtx
vt_expand_var_loc_chain (variable *var, bitmap regs, void *data,
bool *pendrecp)
{
struct expand_loc_callback_data *elcd
= (struct expand_loc_callback_data *) data;
location_chain *loc, *next;
rtx result = NULL;
int first_child, result_first_child, last_child;
bool pending_recursion;
rtx loc_from = NULL;
struct elt_loc_list *cloc = NULL;
expand_depth depth = { 0, 0 }, saved_depth = elcd->depth;
int wanted_entryvals, found_entryvals = 0;
/* Clear all backlinks pointing at this, so that we're not notified
while we're active. */
loc_exp_dep_clear (var);
retry:
if (var->onepart == ONEPART_VALUE)
{
cselib_val *val = CSELIB_VAL_PTR (dv_as_value (var->dv));
// WDS test
// gcc_checking_assert (cselib_preserved_value_p (val));
cloc = val->locs;
}
[Bug gcov-profile/83879] New: __gcov_dump doesn't work with dlopen-ed libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879 Bug ID: 83879 Summary: __gcov_dump doesn't work with dlopen-ed libraries Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: mcastelluccio at mozilla dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 43144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43144&action=edit Archive containing source files to reproduce the bug See the attached example. To reproduce the problem, run the "run.sh" script and see that no func.gcda or func2.gcda are generated. If you remove the "pause()" call in main.c and let the program exit, the func.gcda and func2.gcda files are generated.
[Bug target/83838] Many gcc.target/i386/indirect-thunk*.c tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83838 --- Comment #5 from H.J. Lu --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) > > --- Comment #3 from H.J. Lu --- > > There are > > > > /* Only recent versions of Solaris 11 ld properly support hidden > > .gnu.linkonce > >sections, so don't use them. */ > > #ifndef USE_GLD > > #define USE_HIDDEN_LINKONCE 0 > > #endif > > If I can figure out when full support for .gnu.linkonce started in > Solaris ld, I can make this dynamic in configure.ac ... > > > But GCC generates comdat: > > > > .section > > .text.__x86_indirect_thunk,"axG",@progbits,__x86_indirec > > t_thunk,comdat > > .globl __x86_indirect_thunk > > .hidden __x86_indirect_thunk > > .type __x86_indirect_thunk, @function > > > > Does Solaris ld support comdat? > > ... like this one: complete Solaris ld support for comdat started > sometime in the Solaris 11 timeframe, cf. configure.ac (comdat_group). > Solaris 10 did not (at least not in a way that could cope with > everything gcc might generate). > G++ uses comdat extensively. Without comdat, g++ generates very odd codes. Please double check if libstdc++ object files on Solaris have any comdat sections.
[Bug fortran/83864] ICE in gfc_apply_init, at fortran/expr.c:4271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83864 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-15 Blocks||31237 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 [Bug 31237] [meta-bug] TRANSFER intrinsic
[Bug gcov-profile/83878] New: Line hit counts are sometimes wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83878
Bug ID: 83878
Summary: Line hit counts are sometimes wrong
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: mcastelluccio at mozilla dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 43143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43143&action=edit
Archive with GCNO, GCDA, source file and GCOV output
I'm attaching an archive with gcno, gcda, cpp and gcov files that shows the
problem.
See for example after line 3181:
> -: 3181:static bool
> function
> _ZL24DefineSelfHostedPropertyP9JSContextN2JS6HandleIP8JSObjectEENS2_I4jsidEEPKcS9_j
> called 28803 returned 100% blocks executed 65%
> 28803: 3182:DefineSelfHostedProperty(JSContext* cx, HandleObject obj,
> HandleId id,
> 28803: 3182-block 0
> -: 3183: const char* getterName, const char*
> setterName,
> -: 3184: unsigned attrs)
> -: 3185:{
> 28803: 3186:JSAtom* getterNameAtom = Atomize(cx, getterName,
> strlen(getterName));
> 28803: 3186-block 0
> call0 returned 28803
> 28803: 3187:if (!getterNameAtom)
> branch 0 taken 28803 (fallthrough)
> branch 1 taken 0
> -: 3188:return false;
> 57606: 3189:RootedPropertyName getterNameName(cx,
> getterNameAtom->asPropertyName());
> -: 3190:
Why does line 3189 have a hit count twice as big as previous lines and the
function itself?
The files were generated with GCC 6, we are going to try compiling with a new
version soon. Do you already know of similar problems that have been fixed
between 6 and 8?
[Bug gcov-profile/83877] New: Make gcov accept a path to the gcda and a path to the gcno file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83877 Bug ID: 83877 Summary: Make gcov accept a path to the gcda and a path to the gcno file Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: mcastelluccio at mozilla dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Sometimes they are not close to each other (e.g. if you build on one machine and run tests on other machines). It would be nice if there was a way to specify the paths to both the gcno and the gcda and not be forced to move/copy/symlink the gcno in the directories as siblings to the gcda files.
[Bug other/83876] New: [feature request] flag to force vague linkage for typeinfo and/or disable vtable anchoring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83876 Bug ID: 83876 Summary: [feature request] flag to force vague linkage for typeinfo and/or disable vtable anchoring Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland at rschulz dot eu Target Milestone: --- Vague linking is required for runtime binding [1] and RTTI to work together. If vtable anchoring is possible, then GCC makes use of it, and doesn't use vague linking for typeinfo. This breaks runtime binding [2]. It would be nice if GCC could add a flag which disables vtable anchoring and/or forces vague linking even if vtable anchoring is possible. This would enable to use runtime binding using dlopen even if out-of-line virtual functions exist. 1) https://stackoverflow.com/questions/29524200/how-to-do-runtime-binding-based-on-cpu-capabilities-on-linux 2) https://stackoverflow.com/questions/48246196/virtual-exception-class-causes-dynamic-linker-error
[Bug rtl-optimization/79405] [8 Regression] Infinite loop in fwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405 --- Comment #11 from Aldy Hernandez --- I had a brief interchange with Segher to see if he was still working on this (no). He had this to say (paraphrased with permission): [There are two proposed ways to make this better: 1) Propagate things in an order that does not miss opportunities and always terminates. This requires big code changes. This would try *all* possible propagations until a fixed point is reached (the current code does not try *all* possible propagations). 2) Construct a DAG (or a linearisation even) and only propagate according to that. Also a big code change, but a big simplification. It does however lose opportunities. This is Richi's suggestion in comment 9, which may miss propagations (it cannot propagate around loops). This may not matter much though. Neither is suitable for stage 4 I'd say.] I agree that these do not look like solutions that are stage4 material. Furthermore, I don't see the current stop gap as a problem, given that it only affects a testcase with undefined behavior. Given this, I don't see how this bug can be classified as a P1. Thoughts?
[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Should be fixed now.
[Bug target/83629] [7 Regression] ICE: in decompose_normal_address, at rtlanal.c:6329 with -O2 -fPIC -frename-registers --param=sched-autopref-queue-depth=nnn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Segher Boessenkool --- Fixed on all affected branches. As noted in PR68834, that may be the same problem, but on 6 (it shows differently, 6 doesn't use LRA by default).
[Bug rtl-optimization/80481] Unoptimal additional copy instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481 --- Comment #6 from Vladimir Makarov --- (In reply to Rainer Orth from comment #5) > Created attachment 43121 [details] > i386-pc-solaris2.11 -m64 assembler output Thank you for the code. The patch solves the problem for solaris too. Unfortunately, the code one solaris contains one vmovaps insn in another part of the code for a different reason. I guess the test should be excluded for solaris. I'll sumbit a patch tomorrow.
[Bug c++/83875] New: [feature request] target_clones compatible SIMD capability/length check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83875 Bug ID: 83875 Summary: [feature request] target_clones compatible SIMD capability/length check Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland at rschulz dot eu Target Milestone: --- Currently there are two methods to check for SIMD capabilities (e.g. AVX). The preprocessor defines (e.g. __AVX__) and the builtin __builtin_cpu_supports. The problem is that neither can be used together with target_clones. One happens too early (preprocessor) and one too late (runtime). I suggest to add a builtin function which is constexpr and returns the CPU capabilities of the CPU target and otherwise works like the existing __builtin_cpu_supports. A possible name would be __builtin_target_supports. Even outside of target_clones function, such a builtin would have the advantage that it would allow replacing preprocessor #if with constexpr if. Prior to filing the feature request I asked on gcc-help for a solution: https://gcc.gnu.org/ml/gcc-help/2018-01/msg00057.html . No one had an idea for a solution with current capabilities, and one other developer voiced interest in such a feature.
[Bug target/83629] [7 Regression] ICE: in decompose_normal_address, at rtlanal.c:6329 with -O2 -fPIC -frename-registers --param=sched-autopref-queue-depth=nnn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83629 --- Comment #7 from Segher Boessenkool --- Author: segher Date: Mon Jan 15 22:08:12 2018 New Revision: 256711 URL: https://gcc.gnu.org/viewcvs?rev=256711&root=gcc&view=rev Log: Backport from mainline 2018-01-10 Segher Boessenkool PR target/83629 * config/rs6000/rs6000.md (load_toc_v4_PIC_2, load_toc_v4_PIC_3b, load_toc_v4_PIC_3c): Wrap const term in CONST RTL. gcc/testsuite/ Backport from mainline 2018-01-10 Segher Boessenkool PR target/83629 * gcc.target/powerpc/pr83629.c: New testcase. 2018-01-12 Segher Boessenkool PR target/83629 * gcc.target/powerpc/pr83629.c: Require ilp32. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr83629.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Mon Jan 15 21:47:11 2018 New Revision: 256710 URL: https://gcc.gnu.org/viewcvs?rev=256710&root=gcc&view=rev Log: PR middle-end/83837 * omp-expand.c (expand_omp_atomic_pipeline): Use loaded_val type rather than type addr's type points to. (expand_omp_atomic_mutex): Likewise. (expand_omp_atomic): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-expand.c
[Bug testsuite/83869] [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83869 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- I've xfailed the assertions in r256709.
[Bug c++/74762] [6/7/8 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 --- Comment #10 from Martin Sebor --- Author: msebor Date: Mon Jan 15 21:45:06 2018 New Revision: 256709 URL: https://gcc.gnu.org/viewcvs?rev=256709&root=gcc&view=rev Log: PR testsuite/83869 - c-c++-common/attr-nonstring-3.c fails starting with r256683 testsuite/CHangeLog: * c-c++-common/attr-nonstring-3.c: Work around bug c++/74762. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c
[Bug testsuite/83869] [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83869 --- Comment #3 from Martin Sebor --- Author: msebor Date: Mon Jan 15 21:45:06 2018 New Revision: 256709 URL: https://gcc.gnu.org/viewcvs?rev=256709&root=gcc&view=rev Log: PR testsuite/83869 - c-c++-common/attr-nonstring-3.c fails starting with r256683 testsuite/CHangeLog: * c-c++-common/attr-nonstring-3.c: Work around bug c++/74762. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c
[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83839 --- Comment #7 from Eric Gallager --- (In reply to H.J. Lu from comment #1) > Created attachment 43124 [details] > Try this patch My computer only finished bootstrapping with this version of the patch now, but it worked. Thanks!
[Bug c++/74762] [6/7/8 Regression] missing uninitialized warning (C++, parenthesized expr, TREE_NO_WARNING)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #9 from Martin Sebor --- *** Bug 82609 has been marked as a duplicate of this bug. ***
[Bug c++/82609] missing -Warrray-bounds on an argument in parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82609
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #2 from Martin Sebor ---
The problem is caused by the finish_parenthesized_expr() function in
cp/semantics.c setting the TREE_NO_WARNING bit, as mentioned in bug 74762,
comment 1 (see the snippet from that file copied below). So this is indeed a
dupe of that bug.
/* Finish a parenthesized expression EXPR. */
cp_expr
finish_parenthesized_expr (cp_expr expr)
{
if (EXPR_P (expr))
/* This inhibits warnings in c_common_truthvalue_conversion. */
TREE_NO_WARNING (expr) = 1;
*** This bug has been marked as a duplicate of bug 74762 ***
[Bug testsuite/83869] [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83869 Bug 83869 depends on bug 82609, which changed state. Bug 82609 Summary: missing -Warrray-bounds on an argument in parentheses https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82609 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 82609, which changed state. Bug 82609 Summary: missing -Warrray-bounds on an argument in parentheses https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82609 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug testsuite/83869] [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83869
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Depends on||82609
--- Comment #2 from Martin Sebor ---
The failing test cases are these two:
$ cat -n gcc/testsuite/c-c++-common/attr-nonstring-3.c | grep
"[[:space:]]25[07][[:space:]]"
250T (stpncpy (arr, str, N + 1)); /* { dg-warning "writing 5
bytes into a region of size 4 overflows " } */
257T (stpncpy (p->arr, p->str, N + 1));/* { dg-warning "writing 5
bytes into a region of size 4 overflows" } */
The following test case demonstrates the problem. The root cause is bug 82609:
the extra set of parentheses around the stpncpy call suppresses the middle-end
warnings in C++ (C is unaffected).
$ cat pr83869.C && gcc -O2 -S -Wstringop-overflow pr83869.C
#include
char a[4], b[4];
void sink (char*);
void warn_overflow (void)
{
sink (stpncpy (a, b, sizeof a + 1)); // -Wstringop-overflow (good)
}
void bug_82609_missing_warn_overflow (void)
{
sink ((stpncpy (a, b, sizeof a + 1))); // missing -Wstringop-overflow
}
pr83869.C: In function ‘void warn_overflow()’:
pr83869.C:9:8: warning: ‘char* stpncpy(char*, const char*, size_t)’ writing 5
bytes into a region of size 4 overflows the destination [-Wstringop-overflow=]
sink (stpncpy (a, b, sizeof a + 1)); // -Wstringop-overflow (good)
~^~
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82609
[Bug 82609] missing -Warrray-bounds on an argument in parentheses
[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83874
--- Comment #1 from Harald Anlauf ---
1719 else if (init->expr_type == EXPR_ARRAY)
1720{
1721 if (init->ts.u.cl)
1722{
1723 const gfc_expr *length =
init->ts.u.cl->length;
1724 if (length->expr_type != EXPR_CONSTANT)
Length is null here, so dereferencing fails.
[Bug fortran/83874] New: [6/7/8 Regression] ICE initializing character array from derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83874
Bug ID: 83874
Summary: [6/7/8 Regression] ICE initializing character array
from derived type
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gmx dot de
Target Milestone: ---
The following works up to 5.0.0, but crashes with 6.0.0 through 8.0-trunk:
program gfcbug146
implicit none
type t
character(len=1) :: name
end type t
type(t), parameter :: z(2)= [ t ('a'), t ('b') ]
! character(len=1), parameter :: names(*) = z% name ! works
character(len=*), parameter :: names(2) = z% name ! ICE
! character(len=*), parameter :: names(*) = z% name ! ICE
end program gfcbug146
% gfc-8 gfcbug146.f90
f951: internal compiler error: Segmentation fault
0x89a4680 crash_signal
../../trunk/gcc/toplev.c:325
0x82ce89a add_init_expr_to_sym
../../trunk/gcc/fortran/decl.c:1724
0x82d996c variable_decl
../../trunk/gcc/fortran/decl.c:2589
0x82d996c gfc_match_data_decl()
../../trunk/gcc/fortran/decl.c:5698
0x833a021 match_word
../../trunk/gcc/fortran/parse.c:65
0x833a021 match_word
../../trunk/gcc/fortran/parse.c:54
0x833cb81 decode_statement
../../trunk/gcc/fortran/parse.c:376
0x833cb81 decode_statement
../../trunk/gcc/fortran/parse.c:295
0x833e34c next_free
../../trunk/gcc/fortran/parse.c:1226
0x833e34c next_statement
../../trunk/gcc/fortran/parse.c:1458
0x833fb9f parse_spec
../../trunk/gcc/fortran/parse.c:3836
0x8341bc3 parse_progunit
../../trunk/gcc/fortran/parse.c:5649
0x8342ecb gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6189
0x838b8ae gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651 --- Comment #16 from Harald Anlauf --- (In reply to Janne Blomqvist from comment #13) > Now, for the G77 intrinsics, we don't need to follow the standard and can do > whatever we want. Though I think the general approach above is good for G77 > intrinsics too, namely have one implementation in the library that uses a > suitable integer type for whatever the intrinsic is doing, then have the > frontend generate temporary variables or whatever if the intrinsic is called > with some other kind. For the particular case of signal, I wonder if it > wouldn't in the end be as easy to just generate a call to libc signal() > directly in the frontend..? Maybe. I was wondering whether the documented behavior https://gcc.gnu.org/onlinedocs/gfortran/SIGNAL.html#SIGNAL needs to be adapted to support both 32- and 64-bit platforms, given that HANDLER makes most sense if it is either a procedure or an integer(c_intptr_t) - I hope I got that right - and status (if present) should be integer(c_intptr_t), so that a saved signal handler could be restored later. I'd expect fun with 32-/64-bits, endianness, target and host dependence.
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651 --- Comment #15 from Harald Anlauf --- (In reply to Janne Blomqvist from comment #13) > Now, for the G77 intrinsics, we don't need to follow the standard and can do > whatever we want. Though I think the general approach above is good for G77 > intrinsics too, namely have one implementation in the library that uses a > suitable integer type for whatever the intrinsic is doing, then have the > frontend generate temporary variables or whatever if the intrinsic is called > with some other kind. For the particular case of signal, I wonder if it > wouldn't in the end be as easy to just generate a call to libc signal() > directly in the frontend..? Maybe. I was wondering whether the documented behavior https://gcc.gnu.org/onlinedocs/gfortran/SIGNAL.html#SIGNAL needs to be adapted to support both 32- and 64-bit platforms, given that HANDLER makes most sense if it is either a procedure or an integer(c_intptr_t) - I hope I got that right - and status (if present) should be integer(c_intptr_t), so that a saved signal handler could be restored later. I'd expect fun with 32-/64-bits, endianness, target and host dependence.
[Bug testsuite/83869] [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83869 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-15 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Created attachment 43142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43142&action=edit Test summary for r256683. Confirmed. I see it in my test results with the patch for bug 83508 (attached). Somehow I missed it.
[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jakub Jelinek --- > Created attachment 43138 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43138&action=edit > gcc8-pr83837.patch > > Untested fix. Worked for me on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. Thanks. Rainer
[Bug libstdc++/83830] has_unique_object_representations_v is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83830 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |7.3 --- Comment #3 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/83833] chi_squared_distribution::param() forgot to change the member gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833 --- Comment #5 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/83833] chi_squared_distribution::param() forgot to change the member gamma_distribution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83833 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Mon Jan 15 19:58:22 2018 New Revision: 256708 URL: https://gcc.gnu.org/viewcvs?rev=256708&root=gcc&view=rev Log: PR libstdc++/83833 fix chi_squared_distribution::param(const param&) PR libstdc++/83833 * include/bits/random.h (chi_squared_distribution::param): Update gamma distribution parameter. * testsuite/26_numerics/random/chi_squared_distribution/83833.cc: New test. Added: trunk/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/83833.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > It looks like the std::c[a-z] pattern only matches one symbol anyway: Typo, I meant std::c[a-g]
[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 --- Comment #5 from Martin Sebor --- Yes,'void f (int[static 2])' does mean that and I had hoped to be able to rely on it. Unfortunately, the VLA specification suffers from a number of limitations that made it impractical. Some of them are discussed in WG14 N2074: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2074.htm. Using an attribute (either explicitly specified by the programmer or implicitly inserted by GCC) would overcome some of these. Another limitation, one that's not discussed in N2074 but that's relevant to GCC, is that the VLA syntax is available only in C and not in C++. I'd like the feature to be usable in both languages. But even in C it's common to use 'void f (int[2])' to mean essentially the same thing as 'void f (int[static 2])'. It would be helpful if GCC could provide a mechanism to help detect bugs when using the former, and I'm hoping to use the attributes to do that.
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
--- Comment #10 from Jonathan Wakely ---
It looks like the std::c[a-z] pattern only matches one symbol anyway:
"std::cerr"
This should fix it:
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -58,9 +58,7 @@ GLIBCXX_3.4 {
# std::basic_stringbuf
# std::basic_stringstream;
std::basic_[t-z]*;
- std::ba[t-z]*;
- std::b[b-z]*;
- std::c[a-g]*;
+ std::cerr;
# std::char_traits;
# std::c[i-z]*;
std::c[i-n]*;
IMHO it's a bad idea to have such greedy patterns in the base GLIBCXX_3.4
version anyway, because we never want them to match new symbols, only the ones
that already exist in GLIBCXX_3.4
If there are no other symbols that match std::c[a-g]* today, then there should
never be symbols that match it in future either, and so we shouldn't have that
pattern there. Similarly for std::ba[t-z]* and std::b[b-z]* (and others, but I
haven't tried to clean the rest up now).
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834 --- Comment #9 from Jonathan Wakely --- There's no "correct" answer, the exact form of the demangled string is somewhat arbitrary, especially for lambdas as there is no way to say that name in C++. The libstdc++ linker script clearly expected the old form, but we can adjust the script if needed.
[Bug c++/83873] New: adjacent digit separators are accepted in the exponent-part of floating-point literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83873 Bug ID: 83873 Summary: adjacent digit separators are accepted in the exponent-part of floating-point literals Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: smw at gcc dot gnu.org Target Milestone: --- GCC diagnoses adjacent digit separators in integral literals and the fractional-constant of floating point literals (as it should, according to the productions in the grammar) but accepts an arbitrary number of adjacent digit separators in the exponent-part of floating-point literals. An example might speak volumes. long double f = 1.0e1'''0; Boom: clean compile.
[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837 Dominique d'Humieres changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #5 from Dominique d'Humieres --- *** Bug 83872 has been marked as a duplicate of this bug. ***
[Bug other/83872] [8 regression] libgomp.fortran/pointer1.f90 and libgomp.fortran/pointer2.f90 ICE starting with r256606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83872 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr83837. Patch posted at https://gcc.gnu.org/bugzilla/attachment.cgi?id=43138&action=edit. *** This bug has been marked as a duplicate of bug 83837 ***
[Bug middle-end/82123] [7/8 regression] spurious -Wformat-overflow warning for converted vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123 --- Comment #6 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #2) > This is the typical case of value range info being more precise during vrp > pass (where we have ASSERT_EXPRs) rather than elsewhere (where we don't have > them and pin_3 here is set before the condition). Supposedly the planed on > demand value range stuff could help there, but I have no idea for ETA on > that. I haven't looked into this deeply, but for the record, the future on-demand range work seems to have enough information to see that the path into the sprintf has pin within the [0,255] range: - BB3 - Ranges on entry : s_2(D) : [0, 255] short unsigned int pin_3 : [0, 255] unsigned int [0.00%] [count: INV]: __builtin_sprintf (&name, "%02X", pin_3);
[Bug tree-optimization/83857] [8 Regression] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83857
--- Comment #5 from rsandifo at gcc dot gnu.org
---
Slightly reduced testcase:
f (double *x, double y)
{
double a = 0;
for (int i = 0; i < 100; ++i)
{
a += y;
x[i * 2] += a;
x[i * 2 + 1] += a;
}
return a - y;
}
The problem is that we need the phi to be treated as an SLP operation
when calculating ncopies.
[Bug other/83872] New: [8 regression] libgomp.fortran/pointer1.f90 and libgomp.fortran/pointer2.f90 ICE starting with r256606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83872 Bug ID: 83872 Summary: [8 regression] libgomp.fortran/pointer1.f90 and libgomp.fortran/pointer2.f90 ICE starting with r256606 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Saw this on both powerpc64le and be > FAIL: libgomp.fortran/pointer1.f90 -O0 (internal compiler error) > FAIL: libgomp.fortran/pointer1.f90 -O0 (test for excess errors) > FAIL: libgomp.fortran/pointer1.f90 -O1 (internal compiler error) > FAIL: libgomp.fortran/pointer1.f90 -O1 (test for excess errors) > FAIL: libgomp.fortran/pointer1.f90 -O2 (internal compiler error) > FAIL: libgomp.fortran/pointer1.f90 -O2 (test for excess errors) > FAIL: libgomp.fortran/pointer1.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (internal compiler error) > FAIL: libgomp.fortran/pointer1.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (test for excess errors) > FAIL: libgomp.fortran/pointer1.f90 -O3 -g (internal compiler error) > FAIL: libgomp.fortran/pointer1.f90 -O3 -g (test for excess errors) > FAIL: libgomp.fortran/pointer1.f90 -Os (internal compiler error) > FAIL: libgomp.fortran/pointer1.f90 -Os (test for excess errors) > FAIL: libgomp.fortran/pointer2.f90 -O0 (internal compiler error) > FAIL: libgomp.fortran/pointer2.f90 -O0 (test for excess errors) > FAIL: libgomp.fortran/pointer2.f90 -O1 (internal compiler error) > FAIL: libgomp.fortran/pointer2.f90 -O1 (test for excess errors) > FAIL: libgomp.fortran/pointer2.f90 -O2 (internal compiler error) > FAIL: libgomp.fortran/pointer2.f90 -O2 (test for excess errors) > FAIL: libgomp.fortran/pointer2.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (internal compiler error) > FAIL: libgomp.fortran/pointer2.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions (test for excess errors) > FAIL: libgomp.fortran/pointer2.f90 -O3 -g (internal compiler error) > FAIL: libgomp.fortran/pointer2.f90 -O3 -g (test for excess errors) > FAIL: libgomp.fortran/pointer2.f90 -Os (internal compiler error) > FAIL: libgomp.fortran/pointer2.f90 -Os (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.fortran/pointer1.f90 -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-trunk/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -O0 -B/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs -fintrinsic-modules-path=/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/.libs -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/../libquadmath/.libs/ -L/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran -foffload=-lgfortran -lm -o ./pointer1.exe during GIMPLE pass: ompexp /home/seurer/gcc/gcc-trunk/libgomp/testsuite/libgomp.fortran/pointer1.f90:32:0: internal compiler error: in tree_to_uhwi, at tree.c:6817 0x10d8d4cb tree_to_uhwi(tree_node const*) /home/seurer/gcc/gcc-trunk/gcc/tree.c:6817 0x108a9587 expand_omp_atomic /home/seurer/gcc/gcc-trunk/gcc/omp-expand.c:6539 0x108a9587 expand_omp /home/seurer/gcc/gcc-trunk/gcc/omp-expand.c:7770 0x108a93fb expand_omp /home/seurer/gcc/gcc-trunk/gcc/omp-expand.c:7716 0x108abadb execute_expand_omp /home/seurer/gcc/gcc-trunk/gcc/omp-expand.c:7954
[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 --- Comment #9 from rguenther at suse dot de --- On January 15, 2018 5:34:58 PM GMT+01:00, aurelien at aurel32 dot net wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 > >--- Comment #8 from Aurelien Jarno --- >(In reply to Richard Biener from comment #7) >> Patch has been applied to our GCC 7 with no issues sofar (but fixing >the >> reported issues). > >Given all is fine with this patch, do you think it can be backported to >the GCC >7 branch? We're using it at suse so I think yes.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 --- Comment #17 from Jakub Jelinek --- Does the kernel boot now with the latest trunk?
[Bug tree-optimization/57503] [6/7/8 Regression] Wrong extension of multiply operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #19 from Marc Glisse --- Looking at the very first testcase in this PR, assuming 16-bit int, 129*255 overflows and is thus undefined behavior. Multiply by 255u if you want the multiplication to happen safely in an unsigned type.
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 Martin Sebor changed: What|Removed |Added Depends on||83871 --- Comment #1 from Martin Sebor --- Strictly speaking the warning is incorrect. But because GCC doesn't distinguish between declarations of the primary template and those of its explicit specializations (see bug 83871), the warning just reflects this. It should clear up once bug 83871 has been fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871 [Bug 83871] wrong code for attribute const and pure on distinct template specializations
[Bug tree-optimization/57503] [6/7/8 Regression] Wrong extension of multiply operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 --- Comment #18 from Marc Glisse --- (In reply to Georg-Johann Lay from comment #17) > Obervation that -fno-wrapv also leads to correct code, hence there is > somewhere a wrong assumption that signed overflow occurs (which doesn't). (you probably meant -fwrapv instead of -fno-wrapv?) Why do you say wrong? unsigned ab = a * b; in C, that means: unsigned ab = (int)a * (int)b; Since a is in [0, 255], so is (int)a. Multiplication may not overflow for a signed type, so (int)a*(int)b must be nonnegative. Converting it to long directly or through unsigned int is thus equivalent.
[Bug c++/83871] New: wrong code for attribute const and pure on distinct template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871
Bug ID: 83871
Summary: wrong code for attribute const and pure on distinct
template specializations
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
I'm sure the root case of this bug is the same as that of pr83503 but the
latter is about a warning and this one is about GCC emitting the wrong code and
so it might be worth tracking each separately (and possibly with different
priorities). Alternatively, they can be merged as long as both test cases end
up in the test suite one the underlying bug is fixed.
Unlike in pr83504 (which was about overloads and ended up being invalid), the
test case below shows that G++ applies attribute const from the primary
template to that of specializations of the template, even though the two are
unrelated functions, and even when the specialization has the pure attribute.
This bug affects all GCC releases. Clang 3.5 and older and ICC behave
correctly. Clang 3.6 and later has the same bug as GCC.
$ cat pr83503.C && gcc -O2 -S -Wall pr83503.C -fdump-tree-optimized=/dev/stdout
extern "C" void abort ();
void* __attribute__ ((const)) f (void*);
template
T __attribute__ ((const)) g (T);
int i;
int __attribute__ ((pure))
f (int); // body could be: { return i; }
template <>
int __attribute__ ((pure))
g (int); // body could be: { return i; }
void call_pure_overload (int x)
{
i = 1;
int i0 = f (x); // call made (good)
i = 2;
int i1 = f (x); // call made (good)
if (i0 == i1) // retained
abort ();
}
void call_pure_specialization (int x)
{
i = 1;
int i0 = g (x); // call eliminated (wrong)
i = 2;
int i1 = g (x); // call eliminated (wrong)
if (i0 == i1) // folded to false (wrong)
abort ();
}
;; Function void call_pure_overload(int) (_Z18call_pure_overloadi,
funcdef_no=0, decl_uid=2267, cgraph_uid=0, symbol_order=1)
void call_pure_overload(int) (int x)
{
int _4;
int _6;
:
i = 1;
_4 = f (x_3(D));
i = 2;
_6 = f (x_3(D));
if (_4 == _6)
goto ;
else
goto ;
:
abort ();
:
return;
}
;; Function void call_pure_specialization(int) (_Z24call_pure_specializationi,
funcdef_no=1, decl_uid=2272, cgraph_uid=1, symbol_order=2) (executed once)
void call_pure_specialization(int) (int x)
{
:
i = 2;
abort ();
}
[Bug c++/83870] New: template parameter pack followed by another template parameter does not error when following parameter can not be deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83870
Bug ID: 83870
Summary: template parameter pack followed by another template
parameter does not error when following parameter can
not be deduced
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: smw at gcc dot gnu.org
Target Milestone: ---
[temp.param]/11 tells us "A template parameter pack of a function template
shall not be followed by another template parameter unless that template
parameter can be deduced from the parameter-type-list of the function template
or has a default argument" and then it goes on to give us a couple of handy
examples.
// U can be neither deduced from the parameter-type-list nor specified
template void f() { } // error
template void g() { } // error
// the above is cut-n-paste from n3690, and for a complete program:
int
main()
{
f();
}
MSVC19 and ICC18 issue diagnostics. GCC8 silently produces an executable.
[Bug target/83740] [8 Regression] ICE in maybe_legitimize_operand, at optabs.c:7140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83740 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Janne Blomqvist --- Ok, thanks for testing. Closing this as fixed, then.
[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC||kargl at gcc dot gnu.org
--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Janne Blomqvist from comment #13)
> From https://gcc.gnu.org/wiki/LibgfortranAbiCleanup :
>
>> For many intrinsics there are multiple implementations for different
>> argument kinds. In many cases these should be replaced by a single
>> implementation and having the frontend convert the arguments. E.g.
>> fseek, isatty etc. Of course intrinsics with floating point arguments
>> or that are otherwise performance sensitive must still be kept separate.
>> Also, it should be noted that the current system with foo_i4 and
>> foo_i8 works for F95 where intrinsics require an integer of default
>> kind, in F2003 this restricitons has been lifted and most intrinsics
>> should now accept integers of any kind the compiler supports. Hence
>> doing intrinsics the old way with separate library functions leads
>> to a combinatorial explosion for those intrinsics with multiple
>> integer arguments.
>
>
> Now, for the G77 intrinsics, we don't need to follow the standard and can do
> whatever we want. Though I think the general approach above is good for G77
> intrinsics too, namely have one implementation in the library that uses a
> suitable integer type for whatever the intrinsic is doing, then have the
> frontend generate temporary variables or whatever if the intrinsic is called
> with some other kind. For the particular case of signal, I wonder if it
> wouldn't in the end be as easy to just generate a call to libc signal()
> directly in the frontend..?
This PR is related PR fortran/30372. We basically need to audit all G77
intrinsic routines. KILL is definitely broken, and I have patch for it.
Currently, for this
integer(1) :: stat1, pid1, sig1
integer(2) :: stat2, pid2, sig2
integer(4) :: stat4, pid4, sig4
integer:: stat, pid, sig
integer(8) :: stat8, pid8, sig8
stat1 = kill(pid1, sig1)
stat2 = kill(pid2, sig2)
stat4 = kill(pid4, sig4)
stat8 = kill(pid8, sig8)
stat = kill(pid, sig)
gfortran gives
stat1 = (integer(kind=1)) _gfortran_kill_i4 (&pid1, &sig1);
stat2 = (integer(kind=2)) _gfortran_kill_i4 (&pid2, &sig2);
stat4 = _gfortran_kill_i4 (&pid4, &sig4);
stat8 = (integer(kind=8)) _gfortran_kill_i4 (&pid8, &sig8);
stat = _gfortran_kill_i4 (&pid, &sig);
Lines 1, 2, and 4 are definitely wrong. My patch does
{
integer(kind=4) D.3682;
integer(kind=4) D.3683;
D.3682 = (integer(kind=4)) pid1;
D.3683 = (integer(kind=4)) sig1;
stat1 = (integer(kind=1)) _gfortran_kill_i4 (&D.3682, &D.3683);
}
{
integer(kind=4) D.3685;
integer(kind=4) D.3686;
D.3685 = (integer(kind=4)) pid2;
D.3686 = (integer(kind=4)) sig2;
stat2 = (integer(kind=2)) _gfortran_kill_i4 (&D.3685, &D.3686);
}
stat4 = _gfortran_kill_i4 (&pid4, &sig4);
stat8 = _gfortran_kill_i8 (&pid8, &sig8);
stat = _gfortran_kill_i4 (&pid, &sig);
Lines 1 and 2 have converted the type specs of pid1,2 and sig1,2
to the current type. Line 4 now calls the correct routine.
Things even more broke with argument keyword use. The documentation
has KILL(C,VALUE) except the keyword that gfortran recognizes is
COUNT. I've actaully changed the keywords to PID and SIG, which
makes for sense (and yes, probably breaks backward compatibility to
g77 except no one has reported a problems with keywords).
[Bug fortran/54613] [F08] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Mon Jan 15 18:35:13 2018 New Revision: 256705 URL: https://gcc.gnu.org/viewcvs?rev=256705&root=gcc&view=rev Log: 2018-01-15 Thomas Koenig PR fortran/54613 * gfortran.h (gfc_check_f): Rename f4ml to f5ml. (gfc_logical_4_kind): New macro * intrinsic.h (gfc_simplify_minloc): Add a gfc_expr *argument. (gfc_simplify_maxloc): Likewise. (gfc_resolve_maxloc): Likewise. (gfc_resolve_minloc): Likewise. * check.c (gfc_check_minloc_maxloc): Add checking for "back" argument; also raise error if it is used (for now). Add it if it isn't present. * intrinsic.c (add_sym_4ml): Rename to (add_sym_5ml), adjust for extra argument. (add_functions): Add "back" constant. Adjust maxloc and minloc for back argument. * iresolve.c (gfc_resolve_maxloc): Add back argument. If back is not of gfc_logical_4_kind, convert. (gfc_resolve_minloc): Likewise. * simplify.c (gfc_simplify_minloc): Add back argument. (gfc_simplify_maxloc): Likewise. * trans-intinsic.c (gfc_conv_intrinsic_minmaxloc): Rename last argument to %VAL to ensure passing by value. (gfc_conv_intrinsic_function): Call gfc_conv_intrinsic_minmaxloc also for library calls. 2018-01-15 Thomas Koenig PR fortran/54613 * m4/iparm.m4: Add back_arg macro if in minloc or maxloc. * m4/iforeach-s.m4: Add optional argument back with back_arg macro. Improve m4 quoting. If HAVE_BACK_ARG is defined, assert that back is non-true. * m4/iforeach.m4: Likewise. * m4/ifunction-s.m4: Likewise. * m4/ifunction.m4: Likewise. * m4/maxloc0.m4: Include assert.h * m4/minloc0.m4: Likewise. * m4/maxloc0s.m4: #define HAVE_BACK_ARG. * m4/minloc0s.m4: Likewise. * m4/maxloc1s.m4: Likewise. * m4/minloc1s.m4: Likewise. * m4/maxloc1.m4: Include assert.h, #define HAVE_BACK_ARG. * m4/minloc1.m4: Likewise. * m4/maxloc2s.m4: Add assert.h, add back_arg, assert that back is non-true. * m4/minloc2s.m4: Likewise. * generated/iall_i1.c: Regenerated. * generated/iall_i16.c: Regenerated. * generated/iall_i2.c: Regenerated. * generated/iall_i4.c: Regenerated. * generated/iall_i8.c: Regenerated. * generated/iany_i1.c: Regenerated. * generated/iany_i16.c: Regenerated. * generated/iany_i2.c: Regenerated. * generated/iany_i4.c: Regenerated. * generated/iany_i8.c: Regenerated. * generated/iparity_i1.c: Regenerated. * generated/iparity_i16.c: Regenerated. * generated/iparity_i2.c: Regenerated. * generated/iparity_i4.c: Regenerated. * generated/iparity_i8.c: Regenerated. * generated/maxloc0_16_i1.c: Regenerated. * generated/maxloc0_16_i16.c: Regenerated. * generated/maxloc0_16_i2.c: Regenerated. * generated/maxloc0_16_i4.c: Regenerated. * generated/maxloc0_16_i8.c: Regenerated. * generated/maxloc0_16_r10.c: Regenerated. * generated/maxloc0_16_r16.c: Regenerated. * generated/maxloc0_16_r4.c: Regenerated. * generated/maxloc0_16_r8.c: Regenerated. * generated/maxloc0_16_s1.c: Regenerated. * generated/maxloc0_16_s4.c: Regenerated. * generated/maxloc0_4_i1.c: Regenerated. * generated/maxloc0_4_i16.c: Regenerated. * generated/maxloc0_4_i2.c: Regenerated. * generated/maxloc0_4_i4.c: Regenerated. * generated/maxloc0_4_i8.c: Regenerated. * generated/maxloc0_4_r10.c: Regenerated. * generated/maxloc0_4_r16.c: Regenerated. * generated/maxloc0_4_r4.c: Regenerated. * generated/maxloc0_4_r8.c: Regenerated. * generated/maxloc0_4_s1.c: Regenerated. * generated/maxloc0_4_s4.c: Regenerated. * generated/maxloc0_8_i1.c: Regenerated. * generated/maxloc0_8_i16.c: Regenerated. * generated/maxloc0_8_i2.c: Regenerated. * generated/maxloc0_8_i4.c: Regenerated. * generated/maxloc0_8_i8.c: Regenerated. * generated/maxloc0_8_r10.c: Regenerated. * generated/maxloc0_8_r16.c: Regenerated. * generated/maxloc0_8_r4.c: Regenerated. * generated/maxloc0_8_r8.c: Regenerated. * generated/maxloc0_8_s1.c: Regenerated. * generated/maxloc0_8_s4.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regener
[Bug tree-optimization/83857] [8 Regression] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83857 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- This testcase started to ICE (segfault) with r248909, cc1plus.252763: internal compiler error: Segmentation fault 0x1192507 crash_signal ../../gcc/toplev.c:341 0xde94b5 handled_component_p ../../gcc/tree.h:4450 0xdf9254 maybe_canonicalize_mem_ref_addr ../../gcc/gimple-fold.c:4306 0xdf9ab5 fold_stmt_1 ../../gcc/gimple-fold.c:4405 0xdfacac fold_stmt(gimple_stmt_iterator*) ../../gcc/gimple-fold.c:4733 starting with r252764 it instead ICEs: pr83857.C:15:1: internal compiler error: in vect_get_num_copies, at tree-vectorizer.h:1088 and finally starting with r256126 it ICEs in exact_div, but in the same spot: pr83857.C:15:1: internal compiler error: in exact_div, at poly-int.h:2139 0x15189bc vect_get_num_copies ../../gcc/tree-vectorizer.h:1120 0x152b901 vectorizable_live_operation(gimple*, gimple_stmt_iterator*, _slp_tree*, int, gimple**) ../../gcc/tree-vect-loop.c:7124 0x151d04d vect_analyze_loop_operations ../../gcc/tree-vect-loop.c:1740
[Bug testsuite/83869] New: [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83869 Bug ID: 83869 Summary: [8 regression] c-c++-common/attr-nonstring-3.c fails starting with r256683 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Looks like there was a change in warning messages and this test case was missed? Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++ -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../ /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -Wattributes -Wstringop-overflow -ftrack-macro-expansion=0 -S -o attr-nonstring-3.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../xg++ -B/home/seurer/gcc/build/gcc-trunk/gcc/testsuite/g++1/../../ /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-trunk/powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O2 -Wattributes -Wstringop-overflow -ftrack-macro-expansion=0 -S -o attr-nonstring-3.s /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In function 'void test_printf(MemArrays*)': /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:71:3: warning: 'int printf(const char*, ...)' argument 1 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6: note: argument 'arr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:74:3: warning: 'int printf(const char*, ...)' argument 1 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7: note: argument 'parr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:77:3: warning: 'int printf(const char*, ...)' argument 1 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:59:15: note: argument 'MemArrays::arr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In function 'void test_puts(MemArrays*)': /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:84:3: warning: 'int puts(const char*)' argument 1 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6: note: argument 'arr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:87:3: warning: 'int puts(const char*)' argument 1 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7: note: argument 'parr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:90:3: warning: 'int puts(const char*)' argument 1 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:59:15: note: argument 'MemArrays::arr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c: In function 'void test_snprintf(char*, size_t, MemArrays*)': /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:97:3: warning: 'int snprintf(char*, size_t, const char*, ...)' argument 3 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:51:6: note: argument 'arr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:100:3: warning: 'int snprintf(char*, size_t, const char*, ...)' argument 3 declared attribute 'nonstring' [-Wstringop-overflow=] /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:54:7: note: argument 'parr' declared here /home/seurer/gcc/gcc-trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c:103:3: warning: '
[Bug tree-optimization/83857] [8 Regression] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83857
--- Comment #3 from Jakub Jelinek ---
Reduced testcase with -Ofast:
template struct C {
typedef int D[N];
static int &foo (D x, int y) { return x[y]; }
};
template struct A {
typedef C H;
typename H::D k;
int &operator[](long x) { return H::foo (k, x); }
};
template void bar (T);
float v;
int
main ()
{
constexpr int n = 1 << 8;
A o;
auto load = [&](int i, float q) { o[i] = q;
for (int j = 1; j < 8; ++j)
o[i + j] = o[i + j - 1]; };
for (float p = v; p;)
for (auto j = 0; j < n; j += 8)
{
p += 4.e7f;
load (j, p);
}
bar (o);
}
[Bug target/83868] i386: Clean up thunk function generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83868 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-15 Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug target/83868] New: i386: Clean up thunk function generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83868 Bug ID: 83868 Summary: i386: Clean up thunk function generation Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz Target Milestone: --- Target: i386 output_indirect_thunk_function and ix86_code_end should be generated the way in which normal thunks are output from middle-end.
[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83839 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from H.J. Lu --- Should be fixed now.
[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83839 --- Comment #5 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Jan 15 18:16:01 2018 New Revision: 256704 URL: https://gcc.gnu.org/viewcvs?rev=256704&root=gcc&view=rev Log: i386: Don't use ASM_OUTPUT_DEF for TARGET_MACHO ASM_OUTPUT_DEF isn't defined for TARGET_MACHO. Use ASM_OUTPUT_LABEL to generate the __x86_return_thunk label, instead of the set directive. Update testcase to remove the __x86_return_thunk label check. Since -fno-pic is ignored on Darwin, update testcases to scan or "push" only on Linux. gcc/ PR target/83839 * config/i386/i386.c (output_indirect_thunk_function): Use ASM_OUTPUT_LABEL, instead of ASM_OUTPUT_DEF, for TARGET_MACHO for __x86_return_thunk. gcc/testsuite/ PR target/83839 * gcc.target/i386/indirect-thunk-1.c: Scan for "push" only on Linux. * gcc.target/i386/indirect-thunk-2.c: Likewise. * gcc.target/i386/indirect-thunk-3.c: Likewise. * gcc.target/i386/indirect-thunk-4.c: Likewise. * gcc.target/i386/indirect-thunk-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-1.c: Likewise. * gcc.target/i386/indirect-thunk-attr-2.c: Likewise. * gcc.target/i386/indirect-thunk-attr-5.c: Likewise. * gcc.target/i386/indirect-thunk-attr-6.c: Likewise. * gcc.target/i386/indirect-thunk-attr-7.c: Likewise. * gcc.target/i386/indirect-thunk-extern-1.c: Likewise. * gcc.target/i386/indirect-thunk-extern-2.c: Likewise. * gcc.target/i386/indirect-thunk-extern-3.c: Likewise. * gcc.target/i386/indirect-thunk-extern-4.c: Likewise. * gcc.target/i386/indirect-thunk-extern-7.c: Likewise. * gcc.target/i386/indirect-thunk-register-1.c: Likewise. * gcc.target/i386/indirect-thunk-register-3.c: Likewise. * gcc.target/i386/indirect-thunk-register-4.c: Likewise. * gcc.target/i386/ret-thunk-10.c: Likewise. * gcc.target/i386/ret-thunk-11.c: Likewise. * gcc.target/i386/ret-thunk-12.c: Likewise. * gcc.target/i386/ret-thunk-13.c: Likewise. * gcc.target/i386/ret-thunk-14.c: Likewise. * gcc.target/i386/ret-thunk-15.c: Likewise. * gcc.target/i386/ret-thunk-9.c: Don't check the __x86_return_thunk label. Scan for "push" only for Linux. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-4.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-5.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-6.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-bnd-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-bnd-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-4.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-7.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-4.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-inline-7.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-10.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-11.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-13.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-14.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-15.c trunk/gcc/testsuite/gcc.target/i386/ret-thunk-9.c
[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 --- Comment #4 from joseph at codesourcery dot com --- On Mon, 15 Jan 2018, msebor at gcc dot gnu.org wrote: > 1) How to annotate constant size buffers. I'd like to be able to express that > a function requires a buffer of at least N elements without making N an > argument to the function. E.g., annotate the declaration 'void f (int[2])' to > let GCC understand that it requires an array of at least 2 ints. "void f (int[static 2])" means that; no GNU-specific syntax is needed.
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
--- Comment #8 from nsz at gcc dot gnu.org ---
ok it's because of 'void f()' vs 'f()'
old:
8133 cxx_sym = bfd_demangle (link_info.output_bfd, sym,
Value returned is $2 = 0x2695a00 "void std::call_once >(std::once_flag&, void
(std::thread::*&&)(),
std::reference_wrapper&&)::{lambda()#2}::_FUN()"
new:
8132 cxx_sym = bfd_demangle (link_info.output_bfd, sym,
Value returned is $2 = 0x2598a70 "std::call_once >(std::once_flag&, void
(std::thread::*&&)(),
std::reference_wrapper&&)::{lambda()#2}::_FUN()"
i still don't know what's the expected behaviour though.
[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83839 --- Comment #4 from Dominique d'Humieres --- > Created attachment 43124 [details] > Try this patch Works for me. Thanks.
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comment #7 from nsz at gcc dot gnu.org ---
the difference between the old and new ld for me is that, with the new ld i
see:
Run till exit from #0 lang_vers_match (head=0x60a6b8, prev=0x0, sym=0x6e9f2f
"_ZZSt9call_onceIMSt6threadFvvEJSt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv")
at ../../ld/ldlang.c:8116
0x0045adbc in bfd_find_version_for_sym (verdefs=,
sym_name=0x6e9f2f
"_ZZSt9call_onceIMSt6threadFvvEJSt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv",
hide=0xde64, hide@entry=0xde74) at ../../bfd/linker.c:3181
3181 while ((d = (*t->match) (&t->globals, d, sym_name)) != NULL)
Value returned is $9 = (struct bfd_elf_version_expr *) 0x602120
(gdb) p *$9
$10 = {next = 0x6020e0, pattern = 0x602100 "std::c[a-g]*", literal = 0, symver
= 0, script = 1, mask = 2}
the old ld here returns NULL.
so the the "std::c[a-g]*" pattern in libstdc++-symbols.ver matches
"_ZZSt9call_onceIMSt6threadFvvEJSt17reference_wrapperIS0_EEEvRSt9once_flagOT_DpOT0_ENUlvE0_4_FUNEv"
in the new ld, but not in the old one.
with c++filt the symbol is:
void std::call_once >(std::once_flag&, void
(std::thread::*&&)(),
std::reference_wrapper&&)::{lambda()#2}::_FUN()
which one is the correct behaviour? should this match or not?
[Bug tree-optimization/83867] New: [8 Regression] ICE: Segmentation fault in nested_in_vect_loop_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83867
Bug ID: 83867
Summary: [8 Regression] ICE: Segmentation fault in
nested_in_vect_loop_p
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180114 snapshot (r256677) ICEs when compiling the following
snippet w/ -O1 -ftree-loop-vectorize -ftrapv:
int
k5 (int u5, int aw)
{
int v6;
while (u5 < 1)
{
while (v6 < 4)
++v6;
v6 = 0;
aw += u5 > 0;
++u5;
}
return aw;
}
% gcc-8.0.0-alpha20180114 -O1 -ftree-loop-vectorize -ftrapv -c cdwkvpqv.c
during GIMPLE pass: vect
cdwkvpqv.c: In function 'k5':
cdwkvpqv.c:2:1: internal compiler error: Segmentation fault
k5 (int u5, int aw)
^~
0xc9910f crash_signal
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/toplev.c:325
0xee1fbe nested_in_vect_loop_p
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vectorizer.h:587
0xee1fbe vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vect-stmts.c:9529
0xef77cb vect_transform_loop(_loop_vec_info*)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vect-loop.c:8835
0xf1442f vectorize_loops()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/tree-vectorizer.c:740
[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Since I have a patch I might as well assign this to myself.
[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-15 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Martin Sebor --- So confirmed.
[Bug c/83861] sscanf %lg conversion bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83861 --- Comment #2 from Albert Chan --- hello Andrew, can you explain what is libc ? is it part of gcc ? where should this sscanf bug be sent ?
[Bug c++/83817] [7/8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 --- Comment #5 from Jakub Jelinek --- Created attachment 43141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43141&action=edit gcc8-pr83817.patch Untested fix.
[Bug c++/83817] [7/8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Seems this is only a checking ICE, CALL_FROM_THUNK_P and AGGR_INIT_FROM_THUNK_P macros are defined the same when not checking.
[Bug tree-optimization/83857] [8 Regression] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83857 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-15 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/83836] [8 regression] gcc.dg/vect/pr79920.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83836 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug fortran/83866] New: [8 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83866 Bug ID: 83866 Summary: [8 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3087 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With a missing comma : $ cat z1.f90 program p type t class(t), pointer :: a end type type extends(t) :: t2 end type end $ gfortran-8-20180114 -c z1.f90 f951: internal compiler error: in gfc_release_symbol, at fortran/symbol.c:3087 0x736ceb gfc_release_symbol(gfc_symbol*) ../../gcc/fortran/symbol.c:3087 0x736e6e gfc_restore_last_undo_checkpoint() ../../gcc/fortran/symbol.c:3696 0x6f3db7 reject_statement ../../gcc/fortran/parse.c:2547 0x6f3ecc match_word_omp_simd ../../gcc/fortran/parse.c:98 0x6f7efb match_word ../../gcc/fortran/parse.c:565 0x6f7efb decode_statement ../../gcc/fortran/parse.c:565 0x6f93d4 next_free ../../gcc/fortran/parse.c:1226 0x6f93d4 next_statement ../../gcc/fortran/parse.c:1458 0x6facbc parse_spec ../../gcc/fortran/parse.c:3836 0x6fd173 parse_progunit ../../gcc/fortran/parse.c:5649 0x6fe754 gfc_parse_file() ../../gcc/fortran/parse.c:6189 0x744e5f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 Using version 7 or older : $ gfortran-7 -c z1.f90 z1.f90:5:3: type extends(t) :: t2 1 Error: Unclassifiable statement at (1) z1.f90:6:6: end type 1 Error: Expecting END PROGRAM statement at (1)
[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #9 from Oleg Endo --- This is weird. If I remove empty lines, or rename the paths in the # line markers in the .ii file, the error sometimes disappears...
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 --- Comment #1 from G. Steinmetz --- A similar pair : ICE with 7/8 for z4.f90, z5.f90 works. $ cat z4.f90 program p associate (x => f()) if ( x(1) /= '' ) call abort end associate contains function f() result(z) character(:), allocatable :: z(:) allocate (z, source=['']) end end $ cat z5.f90 program p associate (x => f()) if ( x(1) /= 'a' ) call abort end associate contains function f() result(z) character(:), allocatable :: z(:) allocate (z, source=['a']) end end $ gfortran-8-20180114 -c z4.f90 z4.f90:8:0: allocate (z, source=['']) internal compiler error: in wide_int_to_tree_1, at tree.c:1567 0xdd23c3 wide_int_to_tree_1 ../../gcc/tree.c:1567 0xdd293b wide_int_to_tree(tree_node*, poly_int<1u, generic_wide_int > > const&) ../../gcc/tree.c:1692 0xdd293b build_int_cst(tree_node*, poly_int<1u, long>) ../../gcc/tree.c:1360 0x7494ae gfc_allocate_allocatable(stmtblock_t*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*, int) ../../gcc/fortran/trans.c:801 0x7b604d gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6268 0x747a27 trans_code ../../gcc/fortran/trans.c:1980 0x76eb79 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6451 0x76e9f7 gfc_generate_contained_functions ../../gcc/fortran/trans-decl.c:5463 0x76e9f7 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6380 0x6fe980 translate_all_program_units ../../gcc/fortran/parse.c:6103 0x6fe980 gfc_parse_file() ../../gcc/fortran/parse.c:6306 0x744e5f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/83865] New: ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 Bug ID: 83865 Summary: ICE in wide_int_to_tree_1, at tree.c:1567 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Gives an ICE with releases 6, 7, 8 : $ cat z1.f90 program p character(:), allocatable :: z(:) allocate (z, source=['']) end $ gfortran-8-20180114 -c z1.f90 z1.f90:3:0: allocate (z, source=['']) internal compiler error: in wide_int_to_tree_1, at tree.c:1567 0xdd23c3 wide_int_to_tree_1 ../../gcc/tree.c:1567 0xdd293b wide_int_to_tree(tree_node*, poly_int<1u, generic_wide_int > > const&) ../../gcc/tree.c:1692 0xdd293b build_int_cst(tree_node*, poly_int<1u, long>) ../../gcc/tree.c:1360 0x7494ae gfc_allocate_allocatable(stmtblock_t*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*, int) ../../gcc/fortran/trans.c:801 0x7b604d gfc_trans_allocate(gfc_code*) ../../gcc/fortran/trans-stmt.c:6268 0x747a27 trans_code ../../gcc/fortran/trans.c:1980 0x76eb79 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6451 0x6fe980 translate_all_program_units ../../gcc/fortran/parse.c:6103 0x6fe980 gfc_parse_file() ../../gcc/fortran/parse.c:6306 0x744e5f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 --- Version 5 gives : $ gfortran-5 -c z1.f90 z1.f90:3:13: allocate (z, source=['']) 1 Error: Array specification required in ALLOCATE statement at (1) --- Works with string length > 0 : $ cat z2.f90 program p character(:), allocatable :: z(:) allocate (z, source=['a']) print *, z end $ gfortran-8-20180114 z2.f90 -static-libgfortran $ a.out a $
[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Created attachment 43140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43140&action=edit Slies from Cauldron 2017 presentation. Thanks for the suggestion. Let me confirm this as a useful enhancement. I have a patch with three such attributes that I was hoping to submit for GCC 8 but I didn't resolve all the design issues with it. The current solution provides four attributes: read_only (ptr-arg, size-arg) write_only (ptr-arg, size-arg) read_write (ptr-arg, size-arg) no_side_effect They let GCC know at the call site not just the size of the array the pointer points to but also how the function accesses the contents of the array. The last one means that a function has no side effects except as annotated by the other attributes (which is a superset of what attributes const and pure do). Together they not only enable all sorts of diagnostics but can also improve the emitted code. Attached are a few slides from my presentation on this project at GNU Tools Cauldron 2017. Some of the open design questions I have with this solution are: 1) How to annotate constant size buffers. I'd like to be able to express that a function requires a buffer of at least N elements without making N an argument to the function. E.g., annotate the declaration 'void f (int[2])' to let GCC understand that it requires an array of at least 2 ints. 2) Can partial writes for attribute write_only functions be handled? I.e., would it be worthwhile to provide an annotation to let GCC know at the call site where to look for the number of elements written into an write_only or read_write buffer. 3) How to annotate strings (i.e., sequences of elements terminated by a sentinel element). E.g., in my_strcpy(char *d, const char *s), what should the attribute syntax look like to tell GCC that d and s are nul-terminated strings. As a separate question, is it worthwhile to also provide annotation to express a relationship between d and s (e.g., that they have to have the same number of elements).
