[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I see the same behavior with 4.9, as well as older (e.g. 4.8 or 4.4). The thing is that __builtin_constant_p is (at -O1 and above) a check whether some expression is constant after optimizations, and here FRE or DOM passes figure out (due to jump threading?) that it is constant. Abusing __builtin_constant_p this way is always going to be risky.
[Bug c/81740] [5/6/7/8 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81740 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-07 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.5 Summary|wrong code at -O3 in both |[5/6/7/8 Regression] wrong |32-bit and 64-bit modes on |code at -O3 in both 32-bit |x86_64-linux-gnu|and 64-bit modes on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r206148.
[Bug fortran/61181] -Wunused-but-set-variable for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61181 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- Certainly it would be very useful to have this!
[Bug fortran/30438] Set but never used variable should raise warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438 janus at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=61181 CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #8 from janus at gcc dot gnu.org --- *** Bug 61181 has been marked as a duplicate of this bug. ***
[Bug fortran/61181] -Wunused-but-set-variable for Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61181 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=30438 Resolution|--- |DUPLICATE --- Comment #3 from janus at gcc dot gnu.org --- I guess this is actually a duplicate of PR 30438. *** This bug has been marked as a duplicate of bug 30438 ***
[Bug middle-end/81734] [7/8 Regression] reference to inline function not emitted with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81734 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- The C99/C11 inlining semantics in this case is that if it is possible and desirable to inline the function, then it is inlined, but the out-of-line copy of the inlined function has to be emitted in some other TU. (In reply to Matthias Klose from comment #2) > but shouldn't these the same with different optimization levels? Of course not. Whether it is desirable to inline something is an optimization decision, at -O0 we don't inline anything (unless it has always_inline attribute), at -Os we inline if the heuristics determines that inlining will likely make the code smaller, at -O2 etc. if it determines that inlining will likely make the code faster. So, for the broken pinfo package, you need to decide what you want. Either you want it to be inlined always, no matter what, then it needs always_inline attribute, or if it is not desirable to inline, you want a static copy of the out of line function in every TU that needs it, then it should be static inline, or you want out of line copy in one TU and not the others, then you use what you have above in all but one TU, and in that last TU add extern void builddircommand(void);, or you want the GNU inline semantics, then you add gnu_inline attribute and again read the rules for it. See https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Inline.html and the C standard for more details.
[Bug rtl-optimization/81747] New: [8 Regression] ICE in operator[], at vec.h:749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81747
Bug ID: 81747
Summary: [8 Regression] ICE in operator[], at vec.h:749
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: ---
Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu*
At least gcc-8.0.0-alpha20170730 and gcc-8.0.0-alpha20170806 snapshots ICE when
compiling the following snippet w/ -O2 (-O3, -Ofast) -funroll-loops:
int
ij (int pu, int x5)
{
int u7 = 3;
unsigned int fa;
for (fa = 533090919; fa < 1; ++fa)
{
pu = 1;
while (pu != 0)
{
ed:
u7 %= 1;
}
}
if (x5 < 1)
{
if (fa != 3062256262 && u7 != 0)
goto ed;
return x5;
}
}
% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20170806 -O2 -funroll-loops -c -w
whfolj7o.c
during RTL pass: cse2
whfolj7o.c: In function 'ij':
whfolj7o.c:23:1: internal compiler error: in operator[], at vec.h:749
}
^
0x135560c vec::operator[](unsigned int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170806/work/gcc-8-20170806/gcc/vec.h:749
0x135560c cse_find_path
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170806/work/gcc-8-20170806/gcc/cse.c:6333
0x135560c cse_main
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170806/work/gcc-8-20170806/gcc/cse.c:6729
0x13557a6 rest_of_handle_cse2
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170806/work/gcc-8-20170806/gcc/cse.c:7632
0x13557a6 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20170806/work/gcc-8-20170806/gcc/cse.c:7685
[Bug middle-end/81695] [5/6/7 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81695 --- Comment #9 from Marek Polacek --- This also requires the fix for PR81737.
[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81744 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #3 from amker at gcc dot gnu.org --- Thanks for reporting, I will investigate the issue.
[Bug c++/81722] [7/8 Regression] memory hog building c++ on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81722
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
It compiles just fine for me with 32-bit i686-linux-gnu cc1plus -g -O{0,1,2}
-std=c++11 -fpie.
top maxed around
virtual resident
3674.1m 3.455g
or so. Of course it is close to the limitations of 32-bit address space,
assuming you can compile all template heavy code out there in 32-bit address
space is just wrong.
[Bug middle-end/81698] expand_case uses wrong edge as default edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81698 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Aug 7 08:29:21 2017 New Revision: 250909 URL: https://gcc.gnu.org/viewcvs?rev=250909&root=gcc&view=rev Log: PR middle-end/81698 * stmt.c (emit_case_dispatch_table): Add DEFAULT_EDGE argument, instead of computing it in the function. Formatting fix. (expand_case): Don't rely on default_edge being the first edge, clear it if removing it, pass default_edge to emit_case_dispatch_table. (expand_sjlj_dispatch_table): Pass NULL as DEFAULT_EDGE, formatting fix. Modified: trunk/gcc/ChangeLog trunk/gcc/stmt.c
[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #63 from Daniel Santos --- Created attachment 41943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41943&action=edit test patch for uncaught exception in generator (In reply to Dominique d'Humieres from comment #62) > Created attachment 41937 [details] > Log file for ms-sysv.exp > > Log file generated with > > make -k check-gcc RUNTESTFLAGS="ms-sysv.exp" Thanks Dominique. I'm still not seeing all of what I want to see because when you ran this test run the code generator gcc/testsuite/gcc/ms-sysv-generate.exe already existed and so was not rebuilt. I'm curious to know the full command line when it was built. Could you apply this patch and run it again? I should probably make sure that we rebuild the generator on each new run anyway. As far as the generator, it's not catching an exception that it should. I had been catching it by value because I always knew the type that was being thrown, but maybe there is some type of weirdness in your particular stdlibc++ implementation, so this patch also changes the catch to by-reference. Thanks, Daniel
[Bug fortran/81748] New: extensible types non-conforming behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81748 Bug ID: 81748 Summary: extensible types non-conforming behaviour Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mexas at bristol dot ac.uk Target Milestone: --- module m implicit none type t1 integer :: age end type t1 type, extends( t1 ) :: t2 real :: height_cm end type t2 type, extends( t2 ) :: t3 real :: mass_kg end type t3 contains subroutine s( man ) class( t1 ) :: man(:) integer :: i do i = 1, size( man ) if ( man(i) % age .gt. 3 ) write (*,*) man(i) % age end do end subroutine s end module m program z use m implicit none type( t3 ) :: person3( 5 ) integer:: i person3 % t2 % age = (/ (i, i=1, size(person3)) /) write (*,*) person3 % age write (*,*) person3 % t1 % age write (*,*) person3 % t2 % age call s( person3 % t1 ) call s( person3 % t2 ) call s( person3 ) end program z The correct output is (e.g. ifort 16 gives it): 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 4 5 4 5 4 5 However, with gfortran8 the output is missing from lines: call s( person3 % t1 ) call s( person3 % t2 )
[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81737 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Mon Aug 7 09:13:02 2017 New Revision: 250912 URL: https://gcc.gnu.org/viewcvs?rev=250912&root=gcc&view=rev Log: PR middle-end/81737 * fold-const.c (fold_indirect_ref_1): Check type_domain. * gcc.dg/pr81737.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr81737.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81737 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/81737] [8 Regression] 164.gzip in SPEC CPU 2000 failed to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81737 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #2 from Tom de Vries --- Reproduced it by mapping the outer loop to gang, and setting num_gangs to 640.
[Bug libstdc++/81749] New: std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 Bug ID: 81749 Summary: std::align: runtime error: negation of 8 cannot be represented in type 'size_t' Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: max at maxbruckner dot de Target Milestone: --- Created attachment 41944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41944&action=edit C++ file to reproduce the error When compiling code with clangs undefined behavior sanitizer (clang++ 4.0.1 -fsanitize=unsigned-integer-overflow) that uses std::align, a runtime error occurs: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/memory:117:54: runtime error: negation of 8 cannot be represented in type 'size_t' (aka 'unsigned long') The issue can be reproduced with the C++ and Makefile from the attachments. The full output of my test: alignof(intmax_t) = 8 alloced = 0x5606f17e7c21 /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/memory:117:54: runtime error: negation of 8 cannot be represented in type 'size_t' (aka 'unsigned long') address = 0x5606f17e7c28 space = 92
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #1 from Max Bruckner --- Created attachment 41945 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41945&action=edit Makefile to reproduce the error
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #2 from Max Bruckner --- This is on x86_64
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #3 from Max Bruckner --- Created attachment 41946 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41946&action=edit Suppression file as a workaround. Add to UBSAN_OPTIONS=supressions=...
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf --- Unsigned integer overflow isn't undefined behavior.
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266
--- Comment #3 from Tom de Vries ---
Minimal example:
...
int
main ()
{
#pragma acc parallel num_gangs(256)
{
#pragma acc loop gang
for (unsigned char j = 0; j < 5; j++)
;
}
return 0;
}
...
We generate an unconditional trap, thanks to pass_isolate_erroneous_paths:
...
.entry main$_omp_fn$0 (.param .u64 %in_ar0)
{
.reg .u64 %ar0;
ld.param.u64 %ar0,[%in_ar0];
.reg .pred %r23;
{
.reg .u32 %x;
mov.u32 %x,%tid.x;
setp.ne.u32 %r23,%x,0;
}
@ %r23 bra $L2;
trap;
$L2:
}
...
AFAICT, the problem is that the logic that distributes the iterations over the
gangs uses signed char, while the number of gangs can be larger than what is
representable.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- Yeah, it is IMHO a very big mistake clang added that, we have conciously added only signed-integer-overflow sanitizer, but not unsigned.
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #4 from Tom de Vries --- F.i., we generate: ... _41 = GOACC_DIM_SIZE (0); _29 = (signed char) _41; ... where _41 is 256. When folding in forwprop2, we fold _29 to '0': ... gimple_simplified to _29 = 0; ...
[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81744 --- Comment #4 from amker at gcc dot gnu.org --- So with below code in prepare_finalizers_chain: tree fini, niters = number_of_latch_executions (loop); //... niters = copy_node (niters); niters = force_gimple_operand (niters, &stmts, true, NULL); Even with copy_node, the old niters (which is loop->nb_iterations is changed by the call to force_gimple_operand. The code expects every time function prepare_finalizers_chain is callsed, the niters/loop->nb_iterations stays in the same. What should I do that? Thanks.
[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81744 --- Comment #5 from Jakub Jelinek --- (In reply to amker from comment #4) > So with below code in prepare_finalizers_chain: > tree fini, niters = number_of_latch_executions (loop); > //... > niters = copy_node (niters); > niters = force_gimple_operand (niters, &stmts, true, NULL); > > Even with copy_node, the old niters (which is loop->nb_iterations is changed > by the call to force_gimple_operand. The code expects every time function > prepare_finalizers_chain is callsed, the niters/loop->nb_iterations stays in > the same. What should I do that? Thanks. copy_node copies only one level. force_gimple_operand, like other entrypoints to the gimplifier, are destructive on the tree you pass in, so if you want to reuse niters after it, you should use niters = unshare_expr (niters).
[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81744 --- Comment #6 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > (In reply to amker from comment #4) > > So with below code in prepare_finalizers_chain: > > tree fini, niters = number_of_latch_executions (loop); > > //... > > niters = copy_node (niters); > > niters = force_gimple_operand (niters, &stmts, true, NULL); > > > > Even with copy_node, the old niters (which is loop->nb_iterations is changed > > by the call to force_gimple_operand. The code expects every time function > > prepare_finalizers_chain is callsed, the niters/loop->nb_iterations stays in > > the same. What should I do that? Thanks. > > copy_node copies only one level. force_gimple_operand, like other > entrypoints to the gimplifier, are destructive on the tree you pass in, so > if you want to reuse niters after it, you should use niters = unshare_expr > (niters). Yes, I will send a patch. Thanks.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #6 from Max Bruckner --- Oh, you're right, unsigned overflow is defined of course. I guess I should report a bug with UBSan then to get a suppression included for libstdc++.
[Bug hsa/81713] BIT_FIELD_REF produced by Brig FE do not pass new verification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81713 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor --- Thank you, this is now fixed.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #7 from Jonathan Wakely --- Strictly speaking, unsigned overflow doesn't even exist. "Integer overflow" is only something that happens for signed integers. Operations on unsigned integers have defined behaviour, they can't "overflow". The C++ standard is clear what happens here: "The negative of an unsigned quantity is computed by subtracting its value from 2^n , where n is the number of bits in the promoted operand. The type of the result is the type of the promoted operand."
[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81743 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Aug 7 11:47:22 2017 New Revision: 250915 URL: https://gcc.gnu.org/viewcvs?rev=250915&root=gcc&view=rev Log: i386: Set priority to P_AES for Westmere The difference between Nehalem and Westmere is AES. We should set priority to P_AES for Westmere, not P_PROC_SSE4_2 which is for Nehalem. Otherwise, we will pick Nehalem implementation on Westmere. Tested on Westmere. PR target/81743 * config/i386/i386.c (get_builtin_code_for_version): Set priority to P_AES for Westmere. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81736 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Mon Aug 7 11:49:10 2017 New Revision: 250916 URL: https://gcc.gnu.org/viewcvs?rev=250916&root=gcc&view=rev Log: i386: Don't use frame pointer without stack access When there is no stack access, there is no need to use frame pointer even if -fno-omit-frame-pointer is used. gcc/ PR target/81736 * config/i386/i386.c (ix86_finalize_stack_realign_flags): Renamed to ... (ix86_finalize_stack_frame_flags): This. Also clear frame_pointer_needed if -fno-omit-frame-pointer is used without stack access. (ix86_expand_prologue): Replace ix86_finalize_stack_realign_flags with ix86_finalize_stack_frame_flags. (ix86_expand_epilogue): Likewise. (ix86_expand_split_stack_prologue): Likewise. gcc/testsuite/ PR target/81736 * gcc.target/i386/pr81736-1.c: New test. * gcc.target/i386/pr81736-2.c: Likewise. * gcc.target/i386/pr81736-3.c: Likewise. * gcc.target/i386/pr81736-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr81736-1.c trunk/gcc/testsuite/gcc.target/i386/pr81736-2.c trunk/gcc/testsuite/gcc.target/i386/pr81736-3.c trunk/gcc/testsuite/gcc.target/i386/pr81736-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/80283] [5/6/7/8 Regression] bad SIMD register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283 --- Comment #15 from Bernd Schmidt --- For reference: patch and discussion here. https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html
[Bug tree-optimization/78972] [5/6/7/8 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #11 from Bernd Schmidt --- For reference: patch and discussion here. https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html
[Bug c++/81668] LTO ODR warnings are not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668 --- Comment #5 from sgunderson at bigfoot dot com --- (In reply to Markus Trippelsdorf from comment #3) > I don't see any bug, all relevant information is in the warnings. My point is that all relevant information _isn't_ in the warnings. In particular: The context of the .h file (which .o/.cc file it was compiled as part of in the two cases) is nowhere to be found. If I had that, it would be a lot easier to preprocess the two files and try to find what the difference is. Seemingly at least one of these was a GCC bug (#81716); with some luck, the others I cannot figure out are, too.
[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81743 H.J. Lu changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/81743] int __attribute__ ((target("arch=westmere"))) is compiled incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81743 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed.
[Bug target/81736] Unnecessary save and restore frame pointer with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81736 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #2 from H.J. Lu --- Fixed.
[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81745 --- Comment #10 from Jonathan Wakely --- (In reply to Vincent Lefèvre from comment #9) > Changed back to INVALID (there's a bug in bugzilla, which changes INVALID to > FIXED after a reload + a new comment). Sounds like something your browser did, bugzilla doesn't do that.
[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 amker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from amker at gcc dot gnu.org --- Fixed.
[Bug target/81414] [6/7 Regression] ICE in fma steering on AArch64/cortex-a57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81414 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from amker at gcc dot gnu.org --- Fixed.
[Bug middle-end/81408] Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from amker at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/81620] [8 Regression] ICE in is_inv_store_elimination_chain, at tree-predcom.c:1651 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81620 amker at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from amker at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/81627] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81627 amker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from amker at gcc dot gnu.org --- Fixed.
[Bug libstdc++/81751] New: __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751
Bug ID: 81751
Summary: __basic_file::sync() may flush _all_ files
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzilla.volker at kabelmail dot de
Target Milestone: ---
When creating a stdio_filebuf from a FILE* the constructor calls
__basic_file::sys_open() which in turn calls __basic_file::sync(). Sync()
unconditionally makes a call to fflush() even if the _M_cfile member is NULL
which then causes _all_ open streams to be sync'd.
This behaviour makes it impossible to use stdio_filebuf in a multithreaded
environment as there may be a buffer that is flushed multiple times.
My proposed solution to file libstdc++-v3/config/io/basic_file_stdio.cc is to
call fflush() in sync() only if _M_cfile is not NULL:
int
__basic_file::sync()
{ return _M_cfile ? fflush(_M_cfile) : 0; }
This change makes sure only the controlled sequence is synchronized.
Alternatively the call to sync in function sys_open (in the same file) may be
made conditional on _M_cfile.
This issue is present in versions back to at least 4.7.2.
[Bug middle-end/46932] Inefficient code sequence to access local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46932 --- Comment #8 from Wilco --- Author: wilco Date: Mon Aug 7 13:56:02 2017 New Revision: 250918 URL: https://gcc.gnu.org/viewcvs?rev=250918&root=gcc&view=rev Log: Fix unresolved in gcc.dg/pr46932.c Build only if pre-increment is supported. Given there is no config test, add a list of targets which have HAVE_PRE_INCREMENT set. testsuite/ PR middle-end/46932 * gcc.dg/pr46932.c: Compile on targets with pre-increment. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr46932.c
[Bug target/81709] __attribute__((interrupt)) should handle SSE registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81709 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from H.J. Lu --- If you want to use SSE registers, you can write the interrupt handler with the new naked attribute in GCC 8.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #8 from Max Bruckner --- I understand how unsigned integers work and that they are defined by the standard to have modular arithmetic. In this case I just didn't add 1 and 1 together I guess. Nevertheless I disagree that there is no "overflow" or "underflow". It's a question of how you define the two words, in a way, but being defined doesn't make less of an underflow/overflow. This is no bug, since std::align exhibits totally defined behavior, but I still think that having a runtime check for unsigned overflow is quite useful, because although it might not be undefined, it might still be unintended behavior in many cases.
[Bug c/69389] bit field incompatible with OpenMP atomic update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69389 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 41947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41947&action=edit gcc8-pr69389.patch Untested fix.
[Bug libgomp/81752] New: num_gangs(65536) converted to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81752
Bug ID: 81752
Summary: num_gangs(65536) converted to 0
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
num_gangs hits a limit at 65536 for nvptx. For this example:
...
int
main ()
{
#pragma acc parallel num_gangs(65536)
;
return 0;
}
...
we get this warning:
...
/tmp/ccjtQtKi.c:47:21: warning: unsigned conversion from 'int' to 'short
unsigned int' changes value from '65536' to '0' [-Woverflow]
{"main$_omp_fn$0", 0x1, 0x1, 0x20}
...
The code triggering the warning in more detail:
...
static const struct nvptx_fn {
const char *name;
unsigned short dim[3];
} func_mappings[] = {
{"main$_omp_fn$0", 0x1, 0x1, 0x20}
};
...
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #9 from Jakub Jelinek --- (In reply to Max Bruckner from comment #8) > Nevertheless I disagree that there is no "overflow" or "underflow". It's a > question of how you define the two words, in a way, but being defined > doesn't make less of an underflow/overflow. > > This is no bug, since std::align exhibits totally defined behavior, but I > still think that having a runtime check for unsigned overflow is quite > useful, because although it might not be undefined, it might still be > unintended behavior in many cases. I don't see how something like that can be ever useful. unsigned integral types don't have negative values, so if you want to sometimes subtract and sometimes add some value, but the condition when that happens is done e.g. in another function, you just use one of the operations and use negated numbers. That triggers this misdesigned sanitizer though of course.
[Bug libstdc++/81749] std::align: runtime error: negation of 8 cannot be represented in type 'size_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81749 --- Comment #10 from Max Bruckner --- (In reply to Jakub Jelinek from comment #9) > (In reply to Max Bruckner from comment #8) > > Nevertheless I disagree that there is no "overflow" or "underflow". It's a > > question of how you define the two words, in a way, but being defined > > doesn't make less of an underflow/overflow. > > > > This is no bug, since std::align exhibits totally defined behavior, but I > > still think that having a runtime check for unsigned overflow is quite > > useful, because although it might not be undefined, it might still be > > unintended behavior in many cases. > > I don't see how something like that can be ever useful. unsigned integral > types don't have negative values, so if you want to sometimes subtract and > sometimes add some value, but the condition when that happens is done e.g. > in another function, you just use one of the operations and use negated > numbers. That triggers this misdesigned sanitizer though of course. First let me define unsigned integer overflow: In my definition, overflow occurs when either an addition or multiplication (maybe left shift as well?) of/with a positive number yields a result that is smaller than the result would be with non-modular math. For example ((size_t)SIZE_MAX) + ((size_t)1U) which is 0, not SIZE_MAX + 1. Simple example: Something like calloc. If you calculate the size of a buffer with a multiplication, you might overflow it (or almost overflow it and later add something that overflows it). When you then go ahead and allocate some space for that buffer without checking, your caller might think that enough space was allocated and start using it, not knowing that it will go out of the bounds of the allocated memory region. This discussion is kind of off-topic, but I just couldn't let the following stand, because I find unsigned overflow detection very useful. > Yeah, it is IMHO a very big mistake clang added that, we have conciously > added only signed-integer-overflow sanitizer, but not unsigned.
[Bug target/81753] New: Building of cross-compiler for powerpc-darwin7 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81753 Bug ID: 81753 Summary: Building of cross-compiler for powerpc-darwin7 is broken Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: powerpc-darwin7 make[2]: Entering directory '/dev/shm/gcc-batch-builds/objs/powerpc-darwin7/gcc' g++ -no-pie -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-array-notation.o c/c-fold.o c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o c-family/c-attribs.o c-family/c-warn.o darwin-c.o rs6000-c.o \ cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -L./../zlib -lz passes.o: In function `gcc::pass_manager::pass_manager(gcc::context*)': passes.c:(.text+0xd709): undefined reference to `make_pass_analyze_swaps(gcc::context*)' insn-emit.o: In function `gen_setmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*)': insn-emit.c:(.text+0x2df83): undefined reference to `expand_block_clear(rtx_def**)' insn-emit.o: In function `gen_movmemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*)': insn-emit.c:(.text+0x2dffc): undefined reference to `expand_block_move(rtx_def**)' insn-output.o: In function `output_456(rtx_def**, rtx_insn*)': insn-output.c:(.text+0x27d9): undefined reference to `rs6000_output_load_multiple(rtx_def**)' insn-output.o: In function `output_457(rtx_def**, rtx_insn*)': insn-output.c:(.text+0x27f7): undefined reference to `rs6000_output_load_multiple(rtx_def**)' insn-output.o: In function `output_458(rtx_def**, rtx_insn*)': insn-output.c:(.text+0x2815): undefined reference to `rs6000_output_load_multiple(rtx_def**)' insn-output.o: In function `output_459(rtx_def**, rtx_insn*)': insn-output.c:(.text+0x2833): undefined reference to `rs6000_output_load_multiple(rtx_def**)' insn-output.o: In function `output_460(rtx_def**, rtx_insn*)': insn-output.c:(.text+0x2851): undefined reference to `rs6000_output_load_multiple(rtx_def**)' insn-output.o:insn-output.c:(.text+0x286f): more undefined references to `rs6000_output_load_multiple(rtx_def**)' follow collect2: error: ld returned 1 exit status
[Bug target/81754] New: Building of cross compiler avr-elf is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81754 Bug ID: 81754 Summary: Building of cross compiler avr-elf is broken Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: avr-elf Hello. After this revision I see: $ ../configure --target=avr-elf --enable-languages=c,c++ --disable-bootstrap $ make ../../gcc/config/avr/avr.c: In function ‘void avr_option_override()’: ../../gcc/config/avr/avr.c:778:29: error: lvalue required as left operand of assignment TARGET_GASISR_PROLOGUES = 0; ^
[Bug fortran/81701] -fstack-arrays hehavior does not match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81701 --- Comment #2 from Thomas Koenig --- Author: tkoenig Date: Mon Aug 7 16:43:05 2017 New Revision: 250923 URL: https://gcc.gnu.org/viewcvs?rev=250923&root=gcc&view=rev Log: 2017-08-07 Thomas Koenig PR fortran/68829 * doc/invoke.texi: Document change in behvaior for -Ofast for Fortran. 2017-08-07 Thomas Koenig PR fortran/68829 PR fortran/81701 * options.c: Make -Ofast honor -fmax-stack-var-size. * invoke.texi: Document change. 2017-08-07 Thomas Koenig PR fortran/68829 PR fortran/81701 * gfortran.dg/o_fast_stacksize.90: New test. Added: trunk/gcc/testsuite/gfortran.dg/o_fast_stacksize.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68829 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Mon Aug 7 16:43:05 2017 New Revision: 250923 URL: https://gcc.gnu.org/viewcvs?rev=250923&root=gcc&view=rev Log: 2017-08-07 Thomas Koenig PR fortran/68829 * doc/invoke.texi: Document change in behvaior for -Ofast for Fortran. 2017-08-07 Thomas Koenig PR fortran/68829 PR fortran/81701 * options.c: Make -Ofast honor -fmax-stack-var-size. * invoke.texi: Document change. 2017-08-07 Thomas Koenig PR fortran/68829 PR fortran/81701 * gfortran.dg/o_fast_stacksize.90: New test. Added: trunk/gcc/testsuite/gfortran.dg/o_fast_stacksize.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/81701] -fstack-arrays hehavior does not match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81701 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- Fixed the docs, closing.
[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68829 Bug 68829 depends on bug 81701, which changed state. Bug 81701 Summary: -fstack-arrays hehavior does not match documentation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81701 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68829 --- Comment #8 from Thomas Koenig --- It is now possible to use -fmax-stack-var-size with -Ofast. Closing.
[Bug fortran/68829] [5/6/7/8 Regression] Segfaults with -Ofast due to large array on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68829 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- Actually closing.
[Bug target/81755] New: Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 Bug ID: 81755 Summary: Building of cross compiler for powerpc-wrs-vxworksmils is broken Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: powerpc-wrs-vxworksmils g++ -fno-PIE -c -O0 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/marxin/Programming/gcc2/gcc -I/home/marxin/Programming/gcc2/gcc/. -I/home/marxin/Programming/gcc2/gcc/../include -I/home/marxin/Programming/gcc2/gcc/../libcpp/include -I/home/marxin/Programming/gcc2/gcc/../libdecnumber -I/home/marxin/Programming/gcc2/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/marxin/Programming/gcc2/gcc/../libbacktrace -I. -I. -I/home/marxin/Programming/gcc2/gcc -I/home/marxin/Programming/gcc2/gcc/. -I/home/marxin/Programming/gcc2/gcc/../include -I/home/marxin/Programming/gcc2/gcc/../libcpp/include -I/home/marxin/Programming/gcc2/gcc/../libdecnumber -I/home/marxin/Programming/gcc2/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/marxin/Programming/gcc2/gcc/../libbacktrace /home/marxin/Programming/gcc2/gcc/config/vxworks.c /home/marxin/Programming/gcc2/gcc/config/vxworks.c: In function ‘void vxworks_override_options()’: /home/marxin/Programming/gcc2/gcc/config/vxworks.c:130:22: error: ‘VXWORKS_HAVE_TLS’ was not declared in this scope targetm.have_tls = VXWORKS_HAVE_TLS; ^~~~ /home/marxin/Programming/gcc2/gcc/config/vxworks.c:130:22: note: suggested alternative: ‘VXWORKS_KIND_AE’ targetm.have_tls = VXWORKS_HAVE_TLS; ^~~~ VXWORKS_KIND_AE
[Bug c/81756] New: type attributes silently ignored on type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81756
Bug ID: 81756
Summary: type attributes silently ignored on type declarations
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: ---
When the C11 _Alignas specifier is used on a struct declaration GCC issues a
helpful warning pointing out that the attribute is meaningless. The warning is
issued unconditionally with no option to control it. This should be corrected
and the warning should be enabled under a designated option (e.g., -Wattributes
or -Wignored-attributes).
However, when the equivalent attribute aligned is used the same way GCC
silently ignores it. It would help prevent subtle bugs to have GCC issue a
warning in this case to let the user know that the attribute has no effect.
The test case below illustrates the problem.
$ cat b.c && gcc -O2 -S -Wall -Wextra b.c
#define A(e) _Static_assert ((e), #e)
_Alignas (32) struct NotAligned; // ignored with warning (good)
struct NotAligned { long i; };
A (_Alignof (struct NotAligned) == _Alignof (long)); // passes
struct __attribute__ ((aligned (32))) // silently ignored
Aligned32;
struct Aligned32 { long i; };
A (_Alignof (struct Aligned32) == 32); // FAILS
b.c:3:22: warning: useless ‘_Alignas’ in empty declaration
_Alignas (32) struct NotAligned; // ignored with warning (good)
^~
b.c:1:14: error: static assertion failed: "_Alignof (struct Aligned32) == 32"
#define A(e) _Static_assert ((e), #e)
^~
b.c:15:1: note: in expansion of macro ‘A’
A (_Alignof (struct Aligned32) == 32); // FAILS
^
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #5 from Tom de Vries --- Author: vries Date: Mon Aug 7 17:06:11 2017 New Revision: 250925 URL: https://gcc.gnu.org/viewcvs?rev=250925&root=gcc&view=rev Log: Fix diff_type in expand_oacc_for char iter_type 2017-08-07 Tom de Vries PR middle-end/78266 * omp-expand.c (expand_oacc_for): Ensure diff_type is large enough. * testsuite/libgomp.oacc-c-c++-common/vprop-2.c: New test. * testsuite/libgomp.oacc-c-c++-common/vprop.c: Remove xfail. Added: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/vprop-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-expand.c trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/vprop.c
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #6 from cesar at gcc dot gnu.org --- I'm not sure that solution is correct. A better solution would be to report an error/warning stating that num_workers exceeds the size of the induction variable. Also, in the case that user doesn't specify num_gangs and the type of the induction variable is less than integer_node_type, then hard-code num_gangs to 255 or something small so that the runtime doesn't assign num_gangs that generate bogus results.
[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81753 acsawdey at gcc dot gnu.org changed: What|Removed |Added CC||acsawdey at gcc dot gnu.org --- Comment #1 from acsawdey at gcc dot gnu.org --- Looks to me like this configuration is not including rs6000-string.o. Can you see if this is fixed by adding rs6000-string.o to extra_objs in the *-*-darwin section of gcc/config.gcc?
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #7 from Tom de Vries --- (In reply to cesar from comment #6) > I'm not sure that solution is correct. Why ?
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #8 from cesar at gcc dot gnu.org --- Because num_gangs exceeds largest unsigned value that can be represented by the induction variable.
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 --- Comment #9 from Tom de Vries --- patch with test-suite (In reply to cesar from comment #8) > Because num_gangs exceeds largest unsigned value that can be represented by > the induction variable. I think what you're trying to say here is that the program is not correct. I haven't found anything in the standard to suggest that this is incorrect.
[Bug middle-end/78266] broken openacc loop partitioning on nvptx offloading targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78266 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Tom de Vries --- patch with test-case committed. marking resolved-fixed.
[Bug fortran/67493] -fcheck=recursive not thread aware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67493
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Thomas Koenig ---
In this particular case, all variables are on the stack, so this
is not a problem.
However, even a PURE function could put an array into static storage,
such as this example:
$ gfortran -S -fdump-tree-original worker.f90
$ cat worker.f90.003t.original
worker (integer(kind=4) & restrict n, integer(kind=4) & restrict sumn)
{
integer(kind=4) k;
static integer(kind=4) x[1];
*sumn = 0;
[...]
So, for thread-safety, better specify RECURSIVE.
[Bug c/69389] bit field incompatible with OpenMP atomic update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69389 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Mon Aug 7 18:34:29 2017 New Revision: 250929 URL: https://gcc.gnu.org/viewcvs?rev=250929&root=gcc&view=rev Log: PR c/69389 * gimplify.c (goa_stabilize_expr): Handle BIT_INSERT_EXPR and BIT_FIELD_REF. * c-omp.c (c_finish_omp_atomic): Handle atomics on bitfields. * testsuite/libgomp.c/pr69389.c: New test. * testsuite/libgomp.c++/pr69389.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr69389.C trunk/libgomp/testsuite/libgomp.c/pr69389.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-omp.c trunk/gcc/gimplify.c trunk/libgomp/ChangeLog
[Bug c++/81757] New: function reference on nonnull and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81757
Bug ID: 81757
Summary: function reference on nonnull and noexcept
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 41948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41948&action=edit
a minimal reproduction
We have noticed a behavior that we believe to be a bug. It appears in the
recent 7.2 release candidate, and we know for sure that the behavior was not
present in 6.3. It manifests in --std=c++17 or --std=c++1z.
I have attached a minimal reproduction.
g++ --std=c++17 -c repro.cpp
We get a failure to compile with the following message
--
error: invalid initialization of reference of type ‘void (&)(void*) noexcept’
from expression of type ‘void(void*) noexcept’
void do_stuff() { test(foo); }
^
note: in passing argument 1 of ‘void test(TFunction&&) [with TFunction = void
(&)(void*) noexcept]’
void test(TFunction&& function);
--
We encounter the error only if _all_ the following conditions are met:
1. The function passed as an argument takes a pointer-typed argument is forward
declared with __attribute__((nonnull(n))) (With "n" replaced with the 1-based
index of the pointer-typed argument).
2. The function is declared noexcept
3. That function is passed as an argument to another function via forwarding
reference
[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81525 --- Comment #2 from Jason Merrill --- The bug is that GCC is replacing the auto with the implicit template argument of the generic lambda.
[Bug c++/81359] [7/8 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81359
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Comment #2 from Jason Merrill ---
Reduced:
template
static int test(int);
template
static void test(...);
template (0))>
struct A { };
struct B
{
struct C {
int i = 0;
};
A a;
};
[Bug fortran/81116] Last character of allocatable-length string reset to blank in an assigment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81116 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Mine.
[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 Olivier Hainque changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-08-07 Ever confirmed|0 |1 --- Comment #1 from Olivier Hainque --- mine
[Bug tree-optimization/81741] Misoptimisation : replacing a constant field read access by a function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741 --- Comment #2 from Patrick Pelissier --- I can reproduce the behavior without __builtin_constant_p by removing it from the M_ASSUME macro : # define M_ASSUME(x)\ ( (x) ? \ (void) 0 : __builtin_unreachable()) It still generates the same instructions.
[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 --- Comment #2 from Olivier Hainque --- Author: hainque Date: Mon Aug 7 20:13:53 2017 New Revision: 250931 URL: https://gcc.gnu.org/viewcvs?rev=250931&root=gcc&view=rev Log: Olivier Hainque PR target/81755 * config/vxworksae.h (VXWORKS_HAVE_TLS): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/vxworksae.h
[Bug target/81755] Building of cross compiler for powerpc-wrs-vxworksmils is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81755 Olivier Hainque changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Olivier Hainque --- fixed on mainline
[Bug rtl-optimization/81625] GCC v4.7 ... v8 is bloating code by > 25% compared to v3.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81625 --- Comment #5 from Fredrik Hederstierna --- I tried build several AVR toolchains from 3.4.6 to 7.1.0 and I can confirm that code size increases as described. I suspect for AVR this might start already from 3.x -> 4.x Checked Bug 17549 - [4.0 Regression] 10% increase in codesize with C code compared to GCC 3.3: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17549 If TER pass is disabled adding "-fno-tree-ter", then results get more than -10% smaller. Though results still gets +10% worse than 3.4.6 even with 7.1.0, though adding -mstrict-X also makes its slightly better too..
[Bug fortran/81758] New: [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 Bug ID: 81758 Summary: [OOP] Broken vtab Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- It seems like something is seriously wrong with GFORTRAN 7.x virtual table constructor. I observe an incorrect association of type-bound procedures to their calling names. For example, in procedure, public:: method_name=>ProcedureName I observe method_name to be associated with another (unrelated) type-bound procedure from a completely different type (pretty much all of them are associated with wrong procedures). If you clone my GFC (Generic Fortran Containers) code from https://github.com/DmitryLyakh/GFC.git or https://gitlab.com/DmitryLyakh/GFC.git then in file gfc_vector.F90 lines 740-742 you will see that a pointer "cep" is associated and is trying to invoke one of its type-bound procedures "get_value()". However the debugger shows that get_value() in _vptr is currently associated with another type-bound procedure from a completely different type vector_t, specifically its type-bound procedure VectorLowerBound(), which does not make any sense. Other type-bound procedures in "cep" also associated with wrong procedures. As a consequence, the call crashes with invalid memory reference. This is only observed with GCC 7. To build my code, just type make and run the binary.
[Bug target/72804] Poor code gen with -mvsx-timode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72804 --- Comment #5 from Peter Bergner --- I'm testing a patch. The root cause is that the vsx_le_permute_*, vsx_le_perm_load_* and vsx_le_perm_store_* patterns do not support the TImode values in integer registers and it is these patterns that LRA is using to try and reload the TImode values into/out of integer registers, which causes us to loop until some magic happens and we break out. Adding support for integer registers to the above patterns improves the code to what we would expect to see.
[Bug c++/81757] function reference on nonnull and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81757 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-07 Ever confirmed|0 |1
[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81751 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-08-07 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- That seems like a sensible change.
[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850 --- Comment #11 from DIL --- The additional problem you observe with gfortran/7.1 described in the comment "2017-05-26 22:43:21 UTC" seems to be another gfortran compiler bug introduced in GCC/7.0. I have just filed a bug report for it (#81758). To my current understanding, it is not related to this (potential) bug report which is observed with GCC/5.x and GCC/6.x. Also, in the context of the current bug report, for more convenience I have isolated the problematic section of my code in a separate few-line procedure that can be found in stsubs.F90 line 275 (function clone_object). I still observe the same wrong behavior: Sourced allocate() returns "Attempt to allocated and allocated object" on an explicitly dissociated pointer (meaning allocation status is Unallocated). Additionally, I ran more tests on different platforms and here is the statistics: a) The sourced allocation crash I observe is non-deterministic; b) It is more likely to appear in the "-O0 -g" build than in "-O3"; c) It disappears in GDB; d) It always crashes on Mac; e) It crashes ~ 50% of times on Ubuntu Linux; f) It does not crash on some platforms with RedHat Linux. The code repo is the same: https://github.com/DmitryLyakh/GFC.git or https://gitlab.com/DmitryLyakh/GFC.git Any response or comment would be highly appreciated! Thanks.
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-08-07 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Do you have a reduced test case that does not require understanding your whole package?
[Bug c/81759] New: Improve data tracking for _pext_u64 and __builtin_ffsll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81759
Bug ID: 81759
Summary: Improve data tracking for _pext_u64 and
__builtin_ffsll
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
This simple function gets index of least significant byte with its MSB cleared:
#include
#include "immintrin.h"
uint64_t get_first_msb_cleared(uint64_t val)
{
uint64_t msbs = _pext_u64(val, 0x8080808080808080);
uint64_t msb_index = __builtin_ffsll(~msbs) - 1;
return msb_index;
}
Here is assembly generated by gcc 7.1 (according to https://godbolt.org/):
get_first_msb_cleared(unsigned long):
movabs rax, -9187201950435737472
pext rdi, rdi, rax
mov rax, -1
not rdi
bsf rdi, rdi
cmove rdi, rax
movsx rax, edi
ret
gcc could do better job here. In this case value returned by _pext_u64 has bits
9-64 set to zero, so after negation they will be set to 1. Because of this gcc
could skip "mov rax, -1" and "cmove rdi, rax", this code path is dead.
[Bug c++/81760] New: attribute target uses the wrong default function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81760
Bug ID: 81760
Summary: attribute target uses the wrong default function
argument
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: ---
GCC allows multiple functions with attribute target to be declared with
conflicting default arguments. The function that ends up invoked may or may
not be passed the default argument values corresponding to its declaration.
The test case below should print one of two lines. Either
foo ("arch=silvermont") [arch=silvermont]
on a Silvermont CPU, or
foo ("default") [default]
on a lesser processor, but it instead prints:
foo ("arch=silvermont") [default]
indicating that the default function is invoked with the default argument value
corresponding to the one Silvermont overload.
Since C++ normally prohibits declaring the same function with two different
default argument values it seems that rejecting it on distinct overloads that
differ only in the target attribute would make the most sense.
$ cat a.c && gcc -Wall -Wextra -fdump-tree-optimized=/dev/stdout -xc++ a.c &&
./a.out
$ cat a.c && /ssd/build/gcc-git/gcc/xgcc -B /ssd/build/gcc-git/gcc -Wall
-Wextra -fdump-tree-optimized=/dev/stdout -xc++ a.c && ./a.out
#define A "arch=silvermont"
void __attribute__ ((target ("default")))
foo (const char* = "default");
void __attribute__ ((target (A)))
foo (const char * = A); // accepted (bug)
int main ()
{
foo ();
}
int __attribute__ ((target ("default")))
foo (const char *a)
{
__builtin_printf ("foo (\"%s\") [default]\n", a);
return 0;
}
int __attribute__ ((target (A)))
foo (const char *a)
{
__builtin_printf ("foo (\"%s\") [%s]\n", a, A);
return 0;
}
;; Function int main() (main, funcdef_no=0, decl_uid=2445, cgraph_uid=3,
symbol_order=3)
int main() ()
{
int D.2460;
int _3;
[0.00%] [count: INV]:
_Z3fooPKc ("arch=silvermont");
_3 = 0;
[0.00%] [count: INV]:
:
return _3;
}
;; Function int foo(const char*) (_Z3fooPKc, funcdef_no=1, decl_uid=2455,
cgraph_uid=4, symbol_order=4)
__attribute__((target ("default")))
int foo(const char*) (const char * a)
{
int D.2467;
int _4;
[0.00%] [count: INV]:
__builtin_printf ("foo (\"%s\") [default]\n", a_2(D));
_4 = 0;
[0.00%] [count: INV]:
:
return _4;
}
;; Function int foo(const char*) (_Z3fooPKc.arch_silvermont, funcdef_no=2,
decl_uid=2458, cgraph_uid=5, symbol_order=5)
__attribute__((target ("arch=silvermont")))
int foo(const char*) (const char * a)
{
int D.2469;
int _4;
[0.00%] [count: INV]:
__builtin_printf ("foo (\"%s\") [%s]\n", a_2(D), "arch=silvermont");
_4 = 0;
[0.00%] [count: INV]:
:
return _4;
}
;; Function _Z3fooPKc.resolver (_Z3fooPKc.resolver, funcdef_no=4,
decl_uid=2462, cgraph_uid=6, symbol_order=6)
_Z3fooPKc.resolver ()
{
void * D.2466;
int D.2465;
void * D.2464;
int _3;
void * _4;
void * _5;
[100.00%] [count: INV]:
__builtin_cpu_init ();
_3 = __builtin_cpu_is (&"silvermont"[0]);
if (_3 > 0)
goto ; [100.00%] [count: INV]
else
goto ; [INV] [count: INV]
[100.00%] [count: INV]:
_5 = (void *) foo;
return _5;
[100.00%] [count: INV]:
_4 = (void *) foo;
return _4;
}
foo ("arch=silvermont") [default]
[Bug target/81759] Improve data tracking for _pext_u64 and __builtin_ffsll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81759 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-pc-linux-gnu Severity|normal |enhancement
[Bug c++/81761] New: assembler error on __func__ et al. on attribute target overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81761
Bug ID: 81761
Summary: assembler error on __func__ et al. on attribute target
overloads
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: ---
Using the assert() macro or the __func__ special identifier in two or more
overloads of a function that differ only in their attribute target
specification leads to assembler errors caused by the identifiers not being
sufficiently differentiated from one another. The test case below shows the
problem on x86_64 but the same issue is likely to affect the powerpc64 back
end.
$ cat a.c && gcc -Wall -Wextra -xc++ a.c && ./a.out
#include
#define A "arch=silvermont"
void __attribute__ ((target ("default")))
foo ()
{
assert (!__builtin_cpu_is ("silvermont"));
}
void __attribute__ ((target (A)))
foo ()
{
assert (__builtin_cpu_is ("silvermont"));
}
/tmp/ccX8mC6W.s: Assembler messages:
/tmp/ccX8mC6W.s:82: Error: symbol `_ZZ3foovE19__PRETTY_FUNCTION__' is already
defined
[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81721 --- Comment #1 from Juro Bystricky --- This patch fixes the issue: http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140486.html
[Bug c++/81721] precompiled header : internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81721 Juro Bystricky changed: What|Removed |Added CC||juro.bystricky at intel dot com --- Comment #2 from Juro Bystricky --- This patch fixes the issue: http://lists.openembedded.org/pipermail/openembedded-core/2017-August/140486.html
[Bug c++/81762] New: errors defining attribute target overloads of the same function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81762
Bug ID: 81762
Summary: errors defining attribute target overloads of the same
function template
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: ---
G++ accepts definitions of distinct overloads of the same function that differ
only in their target attribute specifier but rejects definitions of equivalent
"overloads" of function templates, or "overloads" of the same explicit
specializations of a function template.
In the test case below, I expect all the definitions to be accepted as distinct
but the template ones are rejected with errors that suggest an incomplete
integration of the attribute target feature into the C++ front end.
$ cat a.c && gcc -Wall -Wextra -xc++ a.c && ./a.out
#define A "arch=corei7"
void __attribute__ ((target ("default")))
foo (int) { }
void __attribute__ ((target (A)))
foo (int) { /* okay, different foo */ }
template
void bar (T);
template <>
void __attribute__ ((target ("default")))
bar(int) { }
template <>
void __attribute__ ((target (A)))
bar(int) { /* rejected (bug?) */ }
template
void __attribute__ ((target ("default")))
baz (T) { }
template
void __attribute__ ((target (A)))
baz (T) { /* rejected (bug?) */ }
a.c:19:1: error: redefinition of ‘void bar(T) [with T = int]’
bar(int) { /* rejected (bug?) */ }
^~~~
a.c:15:1: note: ‘void bar(T) [with T = int]’ previously declared here
bar(int) { }
^~~~
a.c:28:1: error: ambiguating new declaration ‘template void baz(T)’
baz (T) { /* rejected (bug?) */ }
^~~
a.c:24:1: note: old declaration ‘template void baz(T)’
baz (T) { }
^~~
[Bug fortran/81758] [OOP] Broken vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758 --- Comment #2 from DIL --- No, at this point I do not, unfortunately. These OOP bugs tend to show up at higher levels, so it is not always clear how to reduce it to something small. I will try to reduce it to something smaller, but not sure how far. For example, the current problem shows up in the implementation of a vector container (gfc_vector.F90), but only when it is used to implement something more complex, specifically the graph container in this case (gfc_graph.F90). The latter uses three containers in its implementation: vector, list, and dictionary, so it depends on all of those.
[Bug lto/41565] -m32 causes an ICE when the object files were compiled with 64bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41565
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2009-10-04 09:54:07 |2017-8-7
--- Comment #13 from Eric Gallager ---
(In reply to Eric Gallager from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > Simple testcase for powerpc64.
> > int main(void){ return 0; }
> > --- CUT --
> > gcc t.c -flto -c -m64
> > /home/apinski/gcc-mainline/libexec/gcc/powerpc64-unknown-linux-gnu/4.5.0/
> > lto1 t.o -m32
> >
> > --- CUT ---
> > I have not tried after the patch though.
>
> Confirmed, happens on i386-apple-darwin9.8.0 too.
Oops, meant to switch back to ASSIGNED since it already has an assignee.
[Bug fortran/52387] I/O output of write after nonadvancing read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387 Eric Gallager changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #14 from Eric Gallager --- (In reply to Jerry DeLisle from comment #13) > (In reply to Eric Gallager from comment #12) > > (In reply to Dominique d'Humieres from comment #11) > > > > Tobias, any further information on this one? > > > > > > Any news after more than one year? > > > > Guess not, closing for being stuck in WAITING for so long > > Although we have had no feedback from Standards people, I was actually > starting to look at this a few days ago. The issue is one of squeezing my > personal time to work on these things. I do think we should unless I > discover a major pain to do it. OK, changing to ASSIGNED then since you're already the assignee for it.
[Bug c++/81668] LTO ODR warnings are not helpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81668 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez --- > fts0pars.y:62:0: note: a field with different name is defined in another > translation unit Did you cut the above? It looks like a note without a previous warning. Also, GCC will have trouble to point out the correct location when compiling a generated file that contains linemarkers, unless the linemarkers exactly point out to the original file AND the original file is available to read. > ../include/violite.h:288:8: warning: type ‘struct st_vio’ violates the C++ > One Definition Rule [-Wodr] > struct st_vio > ^ > ../include/violite.h:288:0: note: a different type is defined in another > translation unit > struct st_vio > This seems a problem with location info that fails to point to the .c file affected. One should never get column 0.
[Bug target/81593] Optimize PowerPC vector set from vector extract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81593 --- Comment #2 from Michael Meissner --- Author: meissner Date: Mon Aug 7 23:51:27 2017 New Revision: 250936 URL: https://gcc.gnu.org/viewcvs?rev=250936&root=gcc&view=rev Log: [gcc] 2017-08-07 Michael Meissner PR target/81593 * config/rs6000/vsx.md (vsx_concat_, VSX_D): Cleanup constraints since the -mupper-regs-* switches have been eliminated. (vsx_concat__1): New combiner insns to recognize inserting into a vector from a double word element that was extracted from another vector, and eliminate extra XXPERMDI instructions. (vsx_concat__2): Likewise. (vsx_concat__3): Likewise. (vsx_set_, VSX_D): Rewrite vector set in terms of vector concat to allow optimizing inserts from previous extracts. [gcc/testsuite] 2017-08-07 Michael Meissner PR target/81593 * gcc.target/powerpc/vec-setup.h: New tests to test various combinations of setting up vectors of 2 double word elements. * gcc.target/powerpc/vec-setup-long.c: Likewise. * gcc.target/powerpc/vec-setup-double.c: Likewise. * gcc.target/powerpc/vec-setup-be-long.c: Likewise. * gcc.target/powerpc/vec-setup-be-double.c: Likewise. * gcc.target/powerpc/vsx-extract-6.c: New tests for optimzing vector inserts from vector extracts. * gcc.target/powerpc/vsx-extract-7.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-be-double.c trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-be-long.c trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-double.c trunk/gcc/testsuite/gcc.target/powerpc/vec-setup-long.c trunk/gcc/testsuite/gcc.target/powerpc/vec-setup.h trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-6.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-extract-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/vsx.md trunk/gcc/testsuite/ChangeLog
