[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
--- Comment #3 from Nuno Gonçalves ---
Also to add, this could be suppressed if
enum class Bool : bool{False=0, True=1};
So a better example is for a 2 bit BitField:
enum class Nr : uint8_t{Zero=0, One=1, Two=2, Three=3};
struct{
Nr v:2;
} b;
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
--- Comment #2 from Nuno Gonçalves ---
Not the case since, same warning if:
enum class Bool : uint8_t {False=0, True=1}
[Bug c++/87292] Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292 --- Comment #1 from Andrew Pinski --- I think the second is correct but I dont know the exact rules about enum classes; are they unsigned by default? I know normal emuns are signed by default.
[Bug c++/87292] New: Warnings with Bit Fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87292
Bug ID: 87292
Summary: Warnings with Bit Fields
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nunojpg at gmail dot com
Target Milestone: ---
#include
#include
int main()
{
struct{
uint8_t c1:6;
uint8_t c2:6;
} a;
auto c = {a.c1, a.c2}; //warning: narrowing conversion of '(unsigned
char)c1' from 'unsigned char' to 'unsigned char:6' [-Wnarrowing]
enum class Bool{False=0, True=1};
struct{
Bool v:1; //warning: 'v' is too small to hold all values of 'enum class
main()::Bool'
} b;
return 0;
}
I get this 2 warnings with g++, including trunk, but not with clang++.
I believe the first case is a bug, c1 is promoted to uint8_t and then is
truncated back to uint8_t:6.
The second case I am not sure if the warning is reasonable. For example clang++
will also not warn if the enum class have values defined that do not fit, and
instead will only warn if it detects a assignment that causes truncation.
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||bergner at gcc dot gnu.org Resolution|--- |INVALID --- Comment #8 from Peter Bergner --- (In reply to pdbain from comment #5) > The compiler trips on this part of jnicsup.cpp (ca. line 500): > > #ifdef J9VM_INTERP_FLOAT_SUPPORT > case 'F': > /* float type */ > fltPtr = (jfloat*)--sp; > /* The Linux SH4 compiler needs the next two > lines to be two steps. If > you combine them it fails to compile */ > dbl = ARG(jdouble, f); > *fltPtr = (jfloat)dbl; > break; > case 'D': > /* double type */ > dbl = ARG(jdouble, d); > lngOrDblPtr = (UDATA *) &dbl; > goto pushLongOrDouble; > #endif > case 'J': > /* long type */ > lng = ARG(jlong, j); > lngOrDblPtr = (UDATA *) &lng; > pushLongOrDouble: > #ifdef J9VM_ENV_DATA64 > --sp; > *--sp = *(lngOrDblPtr); > #else > *--sp = *(lngOrDblPtr + 1); > *--sp = *(lngOrDblPtr); > #endif > break; I was able to create a small reproducer program and it shows you have a -fstrict-aliasing bug in your source code. You take the address of the double var "dbl" and cast its address to a UDATA * pointer and then use it. That violates aliasing rules. I was able to get my small reproducer program to work using the -fno-strict-aliasing option as well as using -O0 and -O1 where -fstrict-aliasing is not enabled by default. I'll note that a quick scan through pushArguments() shows other code that looks to violate the aliasing rules too. You can either use -fno-strict-aliasing as a work around or you will need to fix your code.
[Bug target/87288] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288 --- Comment #3 from bin cheng --- Sorry for the breakage, will investigate this soon. Thanks.
[Bug c++/87093] is_constructible (__is_constructible() instrinsic) explicitly instantiates conversion member function of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ville Voutilainen --- Fixed.
[Bug c++/87093] is_constructible (__is_constructible() instrinsic) explicitly instantiates conversion member function of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093 --- Comment #6 from ville at gcc dot gnu.org --- Author: ville Date: Wed Sep 12 21:43:49 2018 New Revision: 264254 URL: https://gcc.gnu.org/viewcvs?rev=264254&root=gcc&view=rev Log: PR c++/87093 Backport from mainline 2018-09-13 Ville Voutilainen gcc/cp PR c++/87093 * method.c (constructible_expr): We're in an unevaluated context in all cases, not just for class targets. testsuite/ PR c++/87093 * g++.dg/ext/is_constructible2.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/is_constructible2.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/method.c
[Bug c++/87093] is_constructible (__is_constructible() instrinsic) explicitly instantiates conversion member function of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87093 --- Comment #5 from ville at gcc dot gnu.org --- Author: ville Date: Wed Sep 12 21:10:43 2018 New Revision: 264253 URL: https://gcc.gnu.org/viewcvs?rev=264253&root=gcc&view=rev Log: PR c++/87093 gcc/cp PR c++/87093 * method.c (constructible_expr): We're in an unevaluated context in all cases, not just for class targets. testsuite/ PR c++/87093 * g++.dg/ext/is_constructible2.C: New. Added: trunk/gcc/testsuite/g++.dg/ext/is_constructible2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #7 from Segher Boessenkool --- Do things work if you add the -fno-strict-aliasing compiler flag?
[Bug fortran/87284] [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87284 --- Comment #2 from Paul Thomas --- Author: pault Date: Wed Sep 12 18:53:50 2018 New Revision: 264251 URL: https://gcc.gnu.org/viewcvs?rev=264251&root=gcc&view=rev Log: 2018-09-12 Paul Thomas PR fortran/87284 * trans-expr.c (gfc_trans_class_init_assign): Access to to array elements of the dynamic type requires that the array reference be added to the class expression and not the _data component, unlike scalar expressions. 2018-09-12 Paul Thomas PR fortran/87284 * gfortran.dg/allocate_with_mold_2.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/allocate_with_mold_2.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/85110] Missing underlines for some bad arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85110
--- Comment #8 from David Malcolm ---
Author: dmalcolm
Date: Wed Sep 12 18:50:08 2018
New Revision: 264250
URL: https://gcc.gnu.org/viewcvs?rev=264250&root=gcc&view=rev
Log:
C++: special-case single non-viable candidate (more PR c++/85110)
I broke out the "no viable candidates" case in build_new_method_call_1
into a subroutine, and added special-case handling for when there's
a single non-viable candidate where there's an argument conversion
error. I turned the error-handling from convert_for_assignment into
a subroutine, calling it from this new special-case.
This converts:
demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:44: error: no matching function for call to 's4::member_1(int&, const
char*&, float&)'
5 | return s4::member_1 (first, second, third);
|^
demo.cc:1:24: note: candidate: 'static int s4::member_1(int, const char**,
float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three);
};
|^~~~
demo.cc:1:56: note: no known conversion for argument 2 from 'const char*' to
'const char**'
1 | struct s4 { static int member_1 (int one, const char **two, float three);
};
| ~^~~
to:
demo.cc: In function 'int test_4(int, const char*, float)':
demo.cc:5:31: error: cannot convert 'const char*' to 'const char**'
5 | return s4::member_1 (first, second, third);
| ^~
| |
| const char*
demo.cc:1:56: note: initializing argument 2 of 'static int s4::member_1(int,
const char**, float)'
1 | struct s4 { static int member_1 (int one, const char **two, float three);
};
| ~^~~
thus highlighting the problematic argument at the callsite (and its type).
gcc/cp/ChangeLog:
PR c++/85110
* call.c (struct conversion_info): Add "loc" field.
(arg_conversion_rejection): Add "loc" param, using it to
initialize the new field.
(bad_arg_conversion_rejection): Likewise.
(explicit_conversion_rejection): Initialize the new field to
UNKNOWN_LOCATION.
(template_conversion_rejection): Likewise.
(add_function_candidate): Pass on the argument location to the new
param of arg_conversion_rejection.
(add_conv_candidate): Likewise.
(build_builtin_candidate): Likewise.
(build_user_type_conversion_1): Likewise.
(single_z_candidate): New function.
(maybe_get_bad_conversion_for_unmatched_call): New function.
(complain_about_bad_argument): New function, based on part of
convert_for_assignment.
(build_new_method_call_1): Split out handling of the "no viable
candidates" case into...
(complain_about_no_candidates_for_method_call): ...this new
function, and use the new functions above to special-case the
handling of a single non-viable candidate due to a bad argument.
* cp-tree.h (complain_about_bad_argument): New decl.
* typeck.c (convert_for_assignment): Split out one error-handling
case into complain_about_bad_argument.
gcc/testsuite/ChangeLog:
PR c++/85110
* g++.dg/cpp0x/explicit4.C: Update expected output to reflect
special-casing of diagnostic for a single non-viable candidate due
to a bad argument.
* g++.dg/diagnostic/param-type-mismatch-2.C: Likewise.
Add test coverage for an unmatched overloaded operator.
* g++.dg/expr/pmf-1.C: Likewise.
* g++.old-deja/g++.bugs/900330_02.C: Likewise.
* g++.old-deja/g++.jason/conversion11.C: Likewise.
* g++.old-deja/g++.law/arg11.C: Likewise.
* g++.old-deja/g++.law/arm9.C: Likewise.
* g++.old-deja/g++.robertl/eb131.C: Likewise.
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/explicit4.C
trunk/gcc/testsuite/g++.dg/diagnostic/param-type-mismatch-2.C
trunk/gcc/testsuite/g++.dg/expr/pmf-1.C
trunk/gcc/testsuite/g++.old-deja/g++.bugs/900330_02.C
trunk/gcc/testsuite/g++.old-deja/g++.jason/conversion11.C
trunk/gcc/testsuite/g++.old-deja/g++.law/arg11.C
trunk/gcc/testsuite/g++.old-deja/g++.law/arm9.C
trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb131.C
[Bug fortran/87284] [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87284 --- Comment #1 from Paul Thomas --- Author: pault Date: Wed Sep 12 18:33:13 2018 New Revision: 264249 URL: https://gcc.gnu.org/viewcvs?rev=264249&root=gcc&view=rev Log: 2018-09-12 Paul Thomas PR fortran/87284 * trans-expr.c (gfc_trans_class_init_assign): Access to to array elements of the dynamic type requires that the array reference be added to the class expression and not the _data component, unlike scalar expressions. 2018-09-12 Paul Thomas PR fortran/87284 * gfortran.dg/allocate_with_mold_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocate_with_mold_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #1 from David Malcolm --- Feature requests like this are fine here (though I make no guarantees about actually implementing them). Any thoughts on what the API should look like?
[Bug tree-optimization/87188] Function pointer canonicalization optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 --- Comment #23 from dave.anglin at bell dot net --- On 2018-09-12 4:03 AM, rguenth at gcc dot gnu.org wrote: > --- Comment #22 from Richard Biener --- > (In reply to dave.anglin from comment #21) >> On 2018-09-09 2:46 PM, rguenther at suse dot de wrote: >>> In the last patch you replace arg0 || arg1 with arg0 & & arg1, that looks >>> wrong. Otherwise the patch looks OK. >> It was intentional. See the comment in dojump.c: >> >> /* If function pointers need to be "canonicalized" before they can >> be reliably compared, then canonicalize them. >> Only do this if*both* sides of the comparison are function pointers. >> If one side isn't, we want a noncanonicalized comparison. See PR >> middle-end/17564. */ >> if (targetm.have_canonicalize_funcptr_for_compare () >> && POINTER_TYPE_P (TREE_TYPE (treeop0)) >> && POINTER_TYPE_P (TREE_TYPE (treeop1)) >> && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (treeop0))) >> && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (treeop1 >> >> Based on this, I thought that we could allow do_store_flag to output a >> "scc" instruction >> when both sides weren't function or method pointers. > Ah, I see. Based on my testing, when we have a function or method pointer for one of the operands, the other operand is either a function, method or void pointer. An implicit cast occurs if one compares a function pointer to say an int or int*. Of course, a warning is generated in that case. So, we want to canonicalize when one of the operands is a function or method pointer. This canonicalizes comparisons of a function pointer and a void pointer. Attached is latest patch.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #30 from Jakub Jelinek --- Author: jakub Date: Wed Sep 12 18:28:20 2018 New Revision: 264248 URL: https://gcc.gnu.org/viewcvs?rev=264248&root=gcc&view=rev Log: PR middle-end/82853 * expr.h (maybe_optimize_mod_cmp): Declare. * expr.c (mod_inv): New function. (maybe_optimize_mod_cmp): New function. (do_store_flag): Use it. * cfgexpand.c (expand_gimple_cond): Likewise. * gcc.target/i386/pr82853-1.c: New test. * gcc.target/i386/pr82853-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr82853-1.c trunk/gcc/testsuite/gcc.target/i386/pr82853-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/expr.c trunk/gcc/expr.h trunk/gcc/testsuite/ChangeLog
[Bug jit/87291] New: Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 Bug ID: 87291 Summary: Add support for inline asm to libgccjit Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: programmerjake at gmail dot com Target Milestone: --- I'm thinking of using libgccjit for generating code for a custom RISC-V architecture. Support for using inline asm would be nice so I can use stock gcc without having to add lots of intrinsics for custom instructions. If this isn't the right place for feature requests please let me know.
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #6 from pdbain at ca dot ibm.com --- Created attachment 44688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44688&action=edit Reworked code without goto across cases This version works.
[Bug target/86989] ICE in rs6000_output_addr_const_extra, at config/rs6000/rs6000.c:20994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86989 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Segher Boessenkool --- Fixed on 7 and later.
[Bug target/86989] ICE in rs6000_output_addr_const_extra, at config/rs6000/rs6000.c:20994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86989 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Wed Sep 12 18:01:11 2018 New Revision: 264247 URL: https://gcc.gnu.org/viewcvs?rev=264247&root=gcc&view=rev Log: Backport patch for PR86989 to 7 2018-09-12 Segher Boessenkool Backport from trunk 2018-08-24 Segher Boessenkool PR target/86989 * config/rs6000/rs6000.c (toc_relative_expr_p): Check that the base is the TOC register. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.c
[Bug target/86989] ICE in rs6000_output_addr_const_extra, at config/rs6000/rs6000.c:20994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86989 --- Comment #4 from Segher Boessenkool --- Author: segher Date: Wed Sep 12 17:58:31 2018 New Revision: 264246 URL: https://gcc.gnu.org/viewcvs?rev=264246&root=gcc&view=rev Log: Backport patch for PR86989 to 8 2018-09-12 Segher Boessenkool Backport from trunk 2018-08-24 Segher Boessenkool PR target/86989 * config/rs6000/rs6000.c (toc_relative_expr_p): Check that the base is the TOC register. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/rs6000.c
[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220 --- Comment #7 from Eric Botcazou --- > Eric, even accepting the purpose in 1, what I described in 2 seems like a > bug. If it needs an extra page past what's actually used, it needs to make > one probe in the last-used page to ensure it doesn't jump a guard page. Not if it's caller has done so for it though. > Anyway, I'll accept that this feature just isn't useful for what I wanted it > for, but I agree with Alexander that it should be clearly documented that > not only is it not intended for this purpose, but it fails to perform this > purpose at all and can even introduce new jump-the-guard-page conditions > that would not have been present without the option. We cannot reasonably document that a feature does exactly the opposite of what it is intended to do, can we? You need to compile the entire software with the option, that's all.
[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220 --- Comment #6 from Rich Felker --- Eric, even accepting the purpose in 1, what I described in 2 seems like a bug. If it needs an extra page past what's actually used, it needs to make one probe in the last-used page to ensure it doesn't jump a guard page. Anyway, I'll accept that this feature just isn't useful for what I wanted it for, but I agree with Alexander that it should be clearly documented that not only is it not intended for this purpose, but it fails to perform this purpose at all and can even introduce new jump-the-guard-page conditions that would not have been present without the option.
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #5 from pdbain at ca dot ibm.com --- The compiler trips on this part of jnicsup.cpp (ca. line 500): #ifdef J9VM_INTERP_FLOAT_SUPPORT case 'F': /* float type */ fltPtr = (jfloat*)--sp; /* The Linux SH4 compiler needs the next two lines to be two steps. If you combine them it fails to compile */ dbl = ARG(jdouble, f); *fltPtr = (jfloat)dbl; break; case 'D': /* double type */ dbl = ARG(jdouble, d); lngOrDblPtr = (UDATA *) &dbl; goto pushLongOrDouble; #endif case 'J': /* long type */ lng = ARG(jlong, j); lngOrDblPtr = (UDATA *) &lng; pushLongOrDouble: #ifdef J9VM_ENV_DATA64 --sp; *--sp = *(lngOrDblPtr); #else *--sp = *(lngOrDblPtr + 1); *--sp = *(lngOrDblPtr); #endif break; Replacing the "goto" with a copy of the "gone-to" code makes the test pass.
[Bug middle-end/87290] Optimize signed x % pow2p == cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87290 --- Comment #2 from Jakub Jelinek --- Created attachment 44687 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44687&action=edit gcc9-pr87290.patch Untested patch.
[Bug c/87242] optimize -O2 incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87242 Alexander Monakov changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Alexander Monakov --- As mentioned in PR 65337, this is fixed in gcc-6+, and the gcc-5 branch is now closed. *** This bug has been marked as a duplicate of bug 65337 ***
[Bug tree-optimization/65337] [5 regression] LTO bootstrap failure with Ada enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 Alexander Monakov changed: What|Removed |Added CC||minshall at acm dot org --- Comment #19 from Alexander Monakov --- *** Bug 87242 has been marked as a duplicate of this bug. ***
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #4 from pdbain at ca dot ibm.com --- Compiler command line: /usr/bin/g++ -save-temps -DOPENJ9_BUILD -O3 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -fno-exceptions -fno-rtti -fno-threadsafe-statics -g -DLINUX -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fpic -DIPv6_FUNCTION_SUPPORT -DLINUXPPC -m64 -DLINUXPPC64 -DPPC64 -Wreturn-type -Werror -I. -I../include -I../oti -I../util -I../gc_include -I../omr/gc/include -I../shared_common/include -I../gc_glue_java -I../nls -I../omr/include_core -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_POWER -c jnicsup.cpp ss.o FastJNI_java_lang_ClassLoader.o FastJNI_java_lang_J9VMInternals.o FastJNI_java_lang_Object.o FastJNI_java_lang_String.o FastJNI_java_lang_System.o FastJNI_java_lang_Thread.o FastJNI_java_lang_Throwable.o FastJNI_java_lang_invoke_MethodHandle.o FastJNI_java_lang_ref_Reference.o FastJNI_java_lang_reflect_Array.o FastJNI_sun_misc_Unsafe.o FlushProcessWriteBuffers.o J9OMRHelpers.o KeyHashTable.o MHInterpreter.o ModularityHashTables.o NativeHelpers.o ObjectFieldInfo.o ObjectMonitor.o OutOfLineINL_com_ibm_jit_JITHelpers.o OutOfLineINL_java_lang_invoke_NativeMethodHandle.o OutOfLineINL_jdk_internal_misc_Unsafe.o StackDumper.o VMAccess.o annsup.o bchelper.o bindnatv.o callin.o classallocation.o classloadersearch.o classseg.o classsupport.o createramclass.o description.o dllsup.o drophelp.o exceptiondescribe.o exceptionsupport.o findmethod.o gphandle.o growstack.o guardedstorage.o hookableAsync.o initsendtarget.o intfunc.o javaPriority.o jnicgen.o jnicsup.o jnifield.o jniinv.o jnimem.o jnimisc.o jnireflect.o jvmfree.o jvminit.o jvminitcommon.o jvmrisup.o linearswalk.o lockwordconfig.o logsupport.o lookuphelper.o lookupmethod.o monhelpers.o montable.o ownedmonitors.o pcinterp.o profilingbc.o rasdump.o rastrace.o resolvefield.o resolvesupport.o romclasses.o romutil.o segment.o statistics.o stringhelpers.o swalk.o threadhelp.o threadpark.o throwexception.o unsafeHelper.o ut_j9vm.o visible.o vmbootlib.o vmhook.o vmifunc.o vmizip.o vmphases.o vmprops.o vmruntimestate.o vmthinit.o vmthread.o xcheck.o \ -Xlinker --start-group -lj9verutil -lj9util -lj9utilcore -lj9stackmap -lj9bcv -lj9dyn -lj9simplepool -lj9zip -lffi -lj9avl -lj9hashtable -lj9pool -lj9omr -Xlinker --end-group -lj9thr29 -lj9hookable29 -lj9prt29 -lomrsig -g -lc -lm
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #3 from pdbain at ca dot ibm.com --- Created attachment 44686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44686&action=edit Good version of jnicsup
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 --- Comment #2 from pdbain at ca dot ibm.com --- Created attachment 44685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44685&action=edit Bad version of jnicsup
[Bug c/87242] optimize -O2 incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87242 rpluim at gmail dot com changed: What|Removed |Added CC||rpluim at gmail dot com --- Comment #6 from rpluim at gmail dot com --- Based on my bisection of gcc using the same emacs test case, this was fixed by: commit e98da821c1ee4450bbe40a0278cd75803706aa7c (HEAD, refs/bisect/new) Author: hubicka Date: Sun Dec 20 05:50:29 2015 + PR middle-end/65337 * tree-ssa-dce.c (bb_postorder): New static var. (forward_edge_to_pdom): Remove. (remove_dead_stmt): Instead of redirecting edges only keep an edge on a path to nearest live BB. (eliminate_unnecessary_stmts): Free bb_postorder. * cfganal.c (dfs_find_deadend): Add START_POINTES. * cfganal.h (inverted_post_order_compute): Update prototype. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/address@hidden 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug middle-end/87290] Optimize signed x % pow2p == cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87290 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-12 CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I have a patch.
[Bug middle-end/87290] New: Optimize signed x % pow2p == cst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87290 Bug ID: 87290 Summary: Optimize signed x % pow2p == cst Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- As mentioned in https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02005.html and PR82853, we don't and should optimize signed x % 16 == 13 to x & (INT_MIN | 15) == 13 and x % 16 == -13 to x & (INT_MIN | 15) == (-13 & (INT_MIN | 15)).
[Bug rtl-optimization/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Segher Boessenkool --- Fixed on trunk and 8; closing as fixed.
[Bug rtl-optimization/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #23 from Segher Boessenkool --- Author: segher Date: Wed Sep 12 16:23:01 2018 New Revision: 264245 URL: https://gcc.gnu.org/viewcvs?rev=264245&root=gcc&view=rev Log: Backport PR86771 fix to 8 2018-09-12 Segher Boessenkool Backport from trunk 2018-08-22 Segher Boessenkool PR rtl-optimization/86771 * combine.c (try_combine): Do not allow splitting a resulting PARALLEL of two SETs into those two SETs, one to be placed at i2, if that SETs destination is modified between i2 and i3. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/combine.c
[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220 --- Comment #5 from Eric Botcazou --- > Eric, can you please contribute a documentation patch that would explain > what -fstack-check is designed to do? Existing documentation does not say > anything about the extra page. Is it supposed to be useful for languages > other that Ada at all? I presume so, if you need to recover from the stack overflow. Not every language can afford to simply abort the process like C...
[Bug c/87242] optimize -O2 incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87242 --- Comment #5 from Greg Minshall --- Created attachment 44684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44684&action=edit creduce'd (but, only partly) test case. module_intern() is the function i creduce'd on (my creduce "interesting" required module_intern() to be unchanged in the .c file, and emacs_intern() in the -O2 .s file to be within epsilon of unchanged, as well as in the non-O2 .s file to have a call to lisp_to_value()). with -O2, it makes a couple of calls then returns 0, which is incorrect behavior.
[Bug c++/87289] jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 Bill Schmidt changed: What|Removed |Added CC||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org --- Comment #1 from Bill Schmidt --- Please see https://gcc.gnu.org/bugs/ for how to submit a bug report. Specifically, we need "the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command." The information you've provided is helpful, but you shouldn't expect us to download and build entire packages to reproduce the bug.
[Bug c++/87289] New: jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87289 Bug ID: 87289 Summary: jdk11 plinux compiled with gcc 7.3 doesn't work with NativeImageBuffer Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pdbain at ca dot ibm.com Target Milestone: --- Created attachment 44683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44683&action=edit Test code and sample source code Further to https://github.com/eclipse/openj9/issues/2788 GCC does not compile "jnicsup.cpp" correctly when optimization is enabled. It appears that "pushArguments()" is not placing the correct data on the Java stack. Inserting a printf makes the test pass. To reproduce: download and build OpenJ9 per instructions in https://www.eclipse.org/openj9/oj9_build.html (use "git clone https://github.com/ibmruntimes/openj9-openjdk-jdk11";). Replace "openj9/runtime/vm/jnicsup.cpp" with the copy from the attached archive. Enable or disable the printf on line 522. To test, put "testgras.class" in the current directory and run "java testgras" (the "java" command will be in a directory called "build/linux-ppc64le-normal-server-release/images/jdk/bin") If the test is successful, no exception is thrown. This bug may date back to version 5.
[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #4 from Alexander Monakov --- Eric, can you please contribute a documentation patch that would explain what -fstack-check is designed to do? Existing documentation does not say anything about the extra page. Is it supposed to be useful for languages other that Ada at all?
[Bug middle-end/86336] [9 regression] ICE in omp-low.c:7879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86336 --- Comment #3 from jules at gcc dot gnu.org --- Author: jules Date: Wed Sep 12 15:21:19 2018 New Revision: 264244 URL: https://gcc.gnu.org/viewcvs?rev=264244&root=gcc&view=rev Log: [OpenACC] C++ reference mapping 2018-09-09 Cesar Philippidis Julian Brown PR middle-end/86336 gcc/cp/ * semantics.c (finish_omp_clauses): Treat C++ references the same in OpenACC as OpenMP. gcc/ * gimplify.c (gimplify_scan_omp_clauses): Set target_firstprivatize_array_bases in OpenACC parallel and kernels region contexts. Remove GOMP_MAP_FIRSTPRIVATE_REFERENCE clauses from OpenACC data regions. libgomp/ * testsuite/libgomp.oacc-c++/non-scalar-data.C: Remove XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/gimplify.c trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.oacc-c++/non-scalar-data.C
[Bug target/87288] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288 Richard Biener changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #2 from Richard Biener --- -fno-ivopts also avoids the issue but still generates aligned accesses: 400510: 66 0f 10 02 movupd (%rdx),%xmm0 400514: 83 c6 01add$0x1,%esi 400517: 48 83 c2 20 add$0x20,%rdx 40051b: 48 83 c1 10 add$0x10,%rcx 40051f: 66 0f 16 42 f0 movhpd -0x10(%rdx),%xmm0 400524: 0f 29 41 f0 movaps %xmm0,-0x10(%rcx) 400528: 41 39 f0cmp%esi,%r8d 40052b: 77 e3 ja 400510 Oh, the issue is bogus iteration... in the original cited assembly we start with rdx == rcx == 0 and thus iterate until overflow. IVOPTs does - MEM[(double &)vectp_jacobianTransposeds.15_51] = vect_perm_even_49; - vectp.11_45 = vectp.11_47 + 16; - vectp_jacobianTransposeds.15_52 = vectp_jacobianTransposeds.15_51 + 16; - ivtmp_55 = ivtmp_54 + 1; - if (ivtmp_55 >= bnd.8_41) + MEM[symbol: jacobianTransposeds, index: ivtmp.23_27, offset: 0] = vect_perm_even_49; + ivtmp.23_26 = ivtmp.23_27 + 16; + if (ivtmp.23_26 == _19) the >= -> == transform looks wrong. Bin?
[Bug target/87288] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Last reconfirmed||2018-09-12
Component|tree-optimization |target
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||9.0
--- Comment #1 from Richard Biener ---
Confirmed on trunk.
0x00400508 <+56>:movupd (%rax,%rdx,2),%xmm0
0x0040050d <+61>:movhpd 0x10(%rax,%rdx,2),%xmm0
=> 0x00400513 <+67>:movaps %xmm0,(%rsp,%rdx,1)
0x00400517 <+71>:add$0x10,%rdx
0x0040051b <+75>:cmp%rdx,%rcx
0x0040051e <+78>:jne0x400508
and
base_address: &jacobianTransposeds
offset from base address: 0
constant offset from base address: 0
step: 8
base alignment: 16
base misalignment: 0
offset alignment: 128
step alignment: 8
base_object: MEM[(double &)&jacobianTransposeds]
Access function 0: {0B, +, 8}_1
not sure where that offset 1 comes from... (also movaps vs. movapd, but ...).
[Bug tree-optimization/87288] New: Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288 Bug ID: 87288 Summary: Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx" Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jorrit at jorrit dot de Target Milestone: --- Created attachment 44682 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44682&action=edit Test case The attached test case segfaults when compiled as /usr/bin/g++-8 -O2 -ftree-loop-vectorize -o test-cornerstoragerefwrap-fail test.ii It exits successfully when compiled with either /usr/bin/g++-8 -O2 -ftree-loop-vectorize -mavx -o test-cornerstoragerefwrap-pass test.ii /usr/bin/g++-8 -O2 -o test-cornerstoragerefwrap-pass test.ii The const_cast in the test case came out of std::array (in the _S_ref() that is called by operator[]). The segfault occurs with - g++-8 (Debian 8.2.0-4) 8.2.0 from Debian buster (registry.dune-project.org/docker/ci/debian:10) - g++ (GCC) 8.1.0 from Coliru (except that I can't test -mavx there), see http://coliru.stacked-crooked.com/a/43b736434d1b2e15 The segfault does not occur with - g++ (GCC) 7.3.0 from gcc:7.3.0 on hub.docker.com - g++ (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 from Debian stretch This was reduced from test-cornerstoragerefwrap.cc in dune-geometry. The issue seemed to start when the CI system upgraded from g++ 8.1 to 8.2, though the fact that that 8.1.0 above also produces the segfault makes me doubt that the reduced issue and the original issue are the same. Ref https://gitlab.dune-project.org/core/dune-geometry/issues/19 (maybe next week when that bugtracker is operational again)
[Bug tree-optimization/87287] Move signed (x % pow2) == 0 optimization to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87287 --- Comment #2 from Jakub Jelinek --- Created attachment 44681 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44681&action=edit gcc9-pr87287.patch Untested fix.
[Bug tree-optimization/87287] Move signed (x % pow2) == 0 optimization to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87287 --- Comment #1 from Jakub Jelinek --- With the to be posted patch, f1 and f3 remains the same, f2 and f4 improves: - movl%edi, %eax - sarl$31, %eax - shrl$28, %eax - addl%eax, %edi + xorl%eax, %eax andl$15, %edi - cmpl%eax, %edi setne %al - movzbl %al, %eax for f2 and - movl%edi, %eax - sarl$31, %eax - shrl$28, %eax - addl%eax, %edi andl$15, %edi - cmpl%eax, %edi je .L9 for f4 at -O2.
[Bug tree-optimization/87287] Move signed (x % pow2) == 0 optimization to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87287 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-12 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/87287] New: Move signed (x % pow2) == 0 optimization to gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87287
Bug ID: 87287
Summary: Move signed (x % pow2) == 0 optimization to gimple
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
As can be seen on:
void f0 (void);
int
f1 (int x)
{
return x % 16 == 0;
}
int
f2 (int x)
{
int y = x % 16;
return y != 0;
}
void
f3 (int x)
{
if (x % 16 != 0)
f0 ();
}
void
f4 (int x)
{
int y = x % 16;
if (y == 0)
f0 ();
}
we perform this optimization in fold-const.c only, it should be moved to
match.pd.
[Bug tree-optimization/87280] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87280 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Sep 12 14:03:21 2018 New Revision: 264241 URL: https://gcc.gnu.org/viewcvs?rev=264241&root=gcc&view=rev Log: 2018-09-12 Richard Biener PR tree-optimization/87280 * tree-ssa-sccvn.c (process_bb): Handle the case of executable edge but unreachable target. (do_rpo_vn): For conservatively handling a PHI only mark the backedge executable but not the block reachable. * gcc.dg/torture/pr87280.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87280.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Eric Botcazou --- >> > On SPARC/Solaris? >> >> Yes please, on an arbitrary input you see the segbus/segfault. > > It was a rhetorical question, there is no valgrind on this platform... But > I'll debug the issue at some point, no worries. Even on Solaris 11/x86, where the latest valgrind release (or the git version) is supposed to be supported, I get only failures when running make regtest.
[Bug tree-optimization/87280] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87280 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #17 from Eric Botcazou --- > > On SPARC/Solaris? > > Yes please, on an arbitrary input you see the segbus/segfault. It was a rhetorical question, there is no valgrind on this platform... But I'll debug the issue at some point, no worries.
[Bug c/87242] optimize -O2 incorrect output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87242 --- Comment #4 from Greg Minshall --- hi. sorry for the delay. i'm creduce'ing and will upload.
[Bug middle-end/87220] -fstack-check produces inefficient and wrong tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87220 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Eric Botcazou --- > -fstack-check produces the code (x86_64; similar for 32-bit): > > foo: > subq$4152, %rsp > orq $0, (%rsp) > addq$4128, %rsp > leaq6(%rsp), %rdi > callbar > addq$24, %rsp > ret > > This test: > 1. Unnecessarily touches an extra page of stack that's not used, wasting > memory. It's as designed (the extra page is necessary to unwind the stack). > 2. Skips over a whole page, potentially clobbering (data race) data on the > other side of a guard page. Likewise, because of 1. > 3. Is completely unnecessary; since less than a page of stack is needed, > only a probe of the final desired stack pointer (after the third > instruction) is needed, and it's performed implicitly by the call. Likewise, because of 1. > The excessive stack usage, unsafety (jumping the guard page), and size and > potential performance hit from unnecessary checks seem to make -fstack-check > unsuitable for its intended purpose at this time. -fstack-check was designed to implement stack checking in Ada, it has nothing to do with stack protection, you want to use -fstack-clash-protection instead.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #16 from Martin Liška --- (In reply to Eric Botcazou from comment #15) > > Could you please run compiler in valgrind? > > On SPARC/Solaris? Yes please, on an arbitrary input you see the segbus/segfault.
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #15 from Eric Botcazou --- > Could you please run compiler in valgrind? On SPARC/Solaris?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 --- Comment #14 from Martin Liška --- (In reply to Eric Botcazou from comment #13) > I have random SIGBUS errors on SPARC/Solaris 10 and 11 machines. Could you please run compiler in valgrind?
[Bug bootstrap/87134] [9 regression] SEGV in cc1 caused by r263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #13 from Eric Botcazou --- I have random SIGBUS errors on SPARC/Solaris 10 and 11 machines.
[Bug middle-end/87276] [9 Regression] Buggy tree-ssa optimization introduced in revision 263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87276
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |DUPLICATE
--- Comment #5 from Richard Biener ---
This is really a duplicate of PR86554. We're performing code-hoisting on
sum + ps->e in the following bit:
if (sum >= 0 && ps->e >= 0)
{
unsigned long uc;
uc = (unsigned long) sum + (unsigned long) ps->e;
if (uc > 9223372036854775807)
r = 2;
else
sum = 17;
}
else
sum = sum + ps->e;
Inserting expression in block 5 for code hoisting: {plus_expr,_8,sum_9} (0008)
Inserted _36 = _8 + sum_9;
in predecessor 5 (0008)
because at some point I teached value-numbering that the two expressions
compute the same value and GCC transforms if (uc > 9223372036854775807)
to if ((signed long)uc < 0).
The testcase works correctly with -fno-code-hoisting. Not sure why the
cited rev. triggers it but as seen with the other PR the underlying issue
(hoisting an expression with undefined behavior) is latent. After
code-hoisting
later VRP pass will optimize the compare (as expected), so -fno-tree-vrp also
is a workaround.
*** This bug has been marked as a duplicate of bug 86554 ***
[Bug middle-end/86554] [7/8/9 Regression] Incorrect code generation with signed/unsigned comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554 Richard Biener changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #8 from Richard Biener --- *** Bug 87276 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87263] [9 Regression] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87263 --- Comment #3 from Richard Biener --- This is because dominated_by_p_w_unex called by rpo_elim::eliminate_avail is looking at edges we have not yet processed. This might be also an issue when iterating because we may "leak" previous iteration state into the current iteration and may end up failing to iterate.
[Bug ada/87058] FAIL: gnat.dg/slice7.adb (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87058 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Eric Botcazou --- I cannot reproduce: === gnat Summary === # of expected passes2707 # of expected failures 24 # of unsupported tests 3 /home/eric/build/gcc-8-branch/native/gcc/gnatmake version 8.2.1 20180912 [gcc-8-branch revision 264232] eric@polaris:~/build/gcc-8-branch/native> gcc/xgcc -v Using built-in specs. COLLECT_GCC=gcc/xgcc Target: x86_64-suse-linux Configured with: /home/eric/svn/gcc-8-branch/configure --build=x86_64-suse-linux --prefix=/home/eric/install/gcc-8-branch --enable-languages=all --enable-__cxa_atexit --disable-nls --enable-checking=yes Thread model: posix gcc version 8.2.1 20180912 [gcc-8-branch revision 264232] (GCC)
[Bug tree-optimization/87266] [9 Regression] ICE: Segmentation fault (in useless_type_conversion_p, tree_nop_conversion_p, or is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87266 --- Comment #5 from Richard Biener --- Author: rguenth Date: Wed Sep 12 12:14:27 2018 New Revision: 264237 URL: https://gcc.gnu.org/viewcvs?rev=264237&root=gcc&view=rev Log: 2018-09-12 Richard Biener PR tree-optimization/87266 * tree-ssa-sccvn.c (do_rpo_vn): Always iterate to not yet visited blocks. * gcc.dg/torture/pr87266-1.c: New testcase. * gcc.dg/torture/pr87266-2.c: Likewise. * gcc.dg/torture/pr87266-3.c: Likewise. * gcc.dg/torture/pr87266-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87266-1.c trunk/gcc/testsuite/gcc.dg/torture/pr87266-2.c trunk/gcc/testsuite/gcc.dg/torture/pr87266-3.c trunk/gcc/testsuite/gcc.dg/torture/pr87266-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/87266] [9 Regression] ICE: Segmentation fault (in useless_type_conversion_p, tree_nop_conversion_p, or is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87266 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 --- Comment #4 from rguenther at suse dot de --- On Wed, 12 Sep 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #3 from Jakub Jelinek --- > You mean like mtrace in glibc? > Another option is try valgrind. Yeah, it's said to not work on freebsd. valgrind seems clean on trunk x86_64-linux and I think that means everything is OK there... I've just verified hash-map construction works as desired. I wonder if side-stepping the small-object allocators by changing the reserve_exact (2) to say reserve_exact (16) would change things... That is, I'm absolutely not ruling out an allocator issue (try tcmalloc?!)
[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- You mean like mtrace in glibc? Another option is try valgrind.
[Bug tree-optimization/87280] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87280 --- Comment #2 from Richard Biener --- Here we're running into the not executable but limited region where we marked not only backedges as executable but also destination BBs as reachable. Things go downhill here because we end up with with all sorts of weird state this way. So this is related to (and probably caused by) r264057 and PR87169.
[Bug tree-optimization/87267] [9 Regression] ICE: Segmentation fault (in gimple_truth_valued_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87267 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- Same issue as PR87266. *** This bug has been marked as a duplicate of bug 87266 ***
[Bug tree-optimization/87266] [9 Regression] ICE: Segmentation fault (in useless_type_conversion_p, tree_nop_conversion_p, or is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87266 --- Comment #3 from Richard Biener --- *** Bug 87267 has been marked as a duplicate of this bug. ***
[Bug c/87286] New: ICE on vectors of enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87286
Bug ID: 87286
Summary: ICE on vectors of enums
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
This testcase:
enum foo { F };
typedef enum foo vec_foo __attribute__((vector_size (16)));
vec_foo add (vec_foo x, vec_foo y) { return x + y; }
triggers:
internal compiler error: in vector_types_compatible_elements_p
This seems to be a disagreement between handle_vector_size_attribute (which
accepts INTEGRAL_TYPE_Ps except BOOLEAN_TYPE) and
vector_types_compatible_elements_p (which uses INTEGER_TYPE instead of
INTEGRAL_TYPE_P). Not sure whether the intent was to forbid vectors of enums,
so not sure whether this is ice-on-valid or ice-on-invalid.
[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85774
--- Comment #9 from Jakub Jelinek ---
So, can't we somewhere in:
/* Find best representative of the partition.
Prefer those with DECL_NAME, even better
satisfying asan_protect_stack_decl predicate. */
for (j = i; j != EOC; j = stack_vars[j].next)
if (asan_protect_stack_decl (stack_vars[j].decl)
&& DECL_NAME (stack_vars[j].decl))
{
repr_decl = stack_vars[j].decl;
break;
}
else if (repr_decl == NULL_TREE
&& DECL_P (stack_vars[j].decl)
&& DECL_NAME (stack_vars[j].decl))
repr_decl = stack_vars[j].decl;
if (repr_decl == NULL_TREE)
repr_decl = stack_vars[i].decl;
data->asan_decl_vec.safe_push (repr_decl);
code tell the asan.c code about the whole partition, essentially
after picking up the representative, essentially do:
if (asan_handled_variables
&& !asan_handled_variables->contains (repr_decl))
{
for (j = i; j != EOC; j = stack_vars[j].next)
if (asan_handled_variables->contains (stack_vars[j].decl))
break;
if (j != EOC)
asan_handled_variables->add (repr_decl);
}
, i.e. if any variable in the partition was ever poisoned, make sure the
representative is unpoisoned?
Of course, asan_handled_variables is private to asan.c and EOC and the way the
vars are chained is cfgexpand.c's private thing, so it might need some wrapping
into asan.c APIs that cfgexpand.c can call.
[Bug middle-end/86078] Documentation: missing param default values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86078 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Note that there are also params that have completely missing documentation: indir-call-topn-profile unlikely-bb-count-fraction
[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Should be fixed in r264202. Please reopen if still present.
[Bug sanitizer/85774] Incorrect stack-use-after-scope caused by missing cleanup of shadow bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85774 --- Comment #8 from Martin Liška --- Jakub: PING^2
[Bug tree-optimization/86844] [8/9 regression] wrong code caused by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Sep 12 09:25:07 2018 New Revision: 264232 URL: https://gcc.gnu.org/viewcvs?rev=264232&root=gcc&view=rev Log: PR tree-optimization/86844 * gimple-ssa-store-merging.c (imm_store_chain_info::coalesce_immediate): For overlapping stores, if there are any overlapping stores in between them, make sure they are also coalesced or we give up completely. * gcc.c-torture/execute/pr86844.c: New test. * gcc.dg/store_merging_22.c: New test. * gcc.dg/store_merging_23.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr86844.c trunk/gcc/testsuite/gcc.dg/store_merging_22.c trunk/gcc/testsuite/gcc.dg/store_merging_23.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/87248] [6/7/8/9 Regression] Bad code for masked operations involving signed ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87248 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Sep 12 09:21:03 2018 New Revision: 264231 URL: https://gcc.gnu.org/viewcvs?rev=264231&root=gcc&view=rev Log: PR middle-end/87248 * fold-const.c (fold_ternary_loc) : Verify also that BIT_AND_EXPR's second operand is a power of two. Formatting fix. * c-c++-common/torture/pr87248.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/c-c++-common/torture/pr87248.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/fold-const.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/87248] [6/7/8/9 Regression] Bad code for masked operations involving signed ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87248 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Sep 12 09:18:55 2018 New Revision: 264230 URL: https://gcc.gnu.org/viewcvs?rev=264230&root=gcc&view=rev Log: PR middle-end/87248 * fold-const.c (fold_ternary_loc) : Verify also that BIT_AND_EXPR's second operand is a power of two. Formatting fix. * c-c++-common/torture/pr87248.c: New test. Added: trunk/gcc/testsuite/c-c++-common/torture/pr87248.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87172] [9 Regression] Spurious "Derived type 'c_funptr' at (1) has not been declared" error after r263782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87172 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from janus at gcc dot gnu.org --- Fixed with r264214. Closing.
[Bug go/87260] [8/9 Regression] go fails to build a simple program on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260 --- Comment #2 from Matthias Klose --- the patch fixes the issue.
[Bug target/87285] [9 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3235) with -O2 -std=gnu++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87285 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug fortran/87284] [7/8/9 Regression] Allocation of class arrays with mold results in "conditional jump or move depends on uninitialised value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87284 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.4
[Bug tree-optimization/87280] [9 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:3647
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87280 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-12 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/87271] [9 Regression] ICE in rpo_elim::~rpo_elim (this=0xbfbfe15c, __in_chrg=) at ../../gcc/tree-ssa-sccvn.c:5709 on FreeBSD 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87271 --- Comment #2 from Richard Biener --- I wonder if there's a way to trace all malloc/realloc/free calls as well (possibly simply via breakpoints and doing continue in their commands, logging the result).
[Bug middle-end/87268] Missed optimization for a tailcall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87268 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- So works as expected on valid input.
[Bug tree-optimization/87267] [9 Regression] ICE: Segmentation fault (in gimple_truth_valued_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87267 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine...
[Bug tree-optimization/87266] [9 Regression] ICE: Segmentation fault (in useless_type_conversion_p, tree_nop_conversion_p, or is_gimple_reg_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87266 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/87263] [9 Regression] ICE on valid code at -O1: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87263 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Version|unknown |9.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug go/87260] [8/9 Regression] go fails to build a simple program on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87260 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3 Summary|[8 Regression] go fails to |[8/9 Regression] go fails |build a simple program on |to build a simple program |arm-linux-gnueabihf |on arm-linux-gnueabihf
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 --- Comment #7 from Richard Biener --- (In reply to Jakub Jelinek from comment #6) > For the above case, there are during the recursion 77608 synth_mult calls, > which might be ok, so indeed better hashing would help, but 10311 is too > large and is not a prime number. Plus this hash table is resolving all > collisions by evicting older cash entries. > That is perhaps fine for the toplevel synth_mult calls, but for the > recursive ones I guess we want to make sure we cache all the values needed > to compute the same toplevel call and perhaps only record the toplevel > call's entry if it would need to evict older entries. > So maybe use the current hash table + another temporary hash_map live just > during the outermost synth_mult call (and activate this behavior only if say > seeing a recursion count of 16)? Sounds reasonable - I'd try activating the behavior on the first collision?
[Bug rtl-optimization/87246] [6/7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246 Richard Biener changed: What|Removed |Added Version|unknown |8.2.1 Target Milestone|--- |6.5
[Bug ada/86916] Constraint_Error erroneous memory access instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 Eric Botcazou changed: What|Removed |Added Target|x86_64-apple-darwin15 | Status|UNCONFIRMED |NEW Keywords||accepts-invalid Last reconfirmed||2018-09-12 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Summary|8.1.0 |Constraint_Error erroneous |(x86_64-apple-darwin15) |memory access instead of |Constraint_Error erroneous |error |memory access | Target Milestone|--- |9.0 --- Comment #5 from Eric Botcazou --- Confirmed. This gives an assertion failure on mainline: +===GNAT BUG DETECTED==+ | 9.0.0 20180911 (experimental) [trunk revision 264202] (x86_64-suse-linux) | | Assert_Failure elists.adb:220| | Error detected at animation.adb:61:16
[Bug tree-optimization/87245] [missed optimization] switching on indices of struct members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87245 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-12 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Possibly the same as if (i == 0) return a[0]; return a[i];
[Bug c++/87282] Invalid use of 'void', in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87282 --- Comment #1 from delrieutheo at gmail dot com --- Note that it fails with operator-=(void*, void*) as well.
[Bug tree-optimization/87188] Function pointer canonicalization optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188 --- Comment #22 from Richard Biener --- (In reply to dave.anglin from comment #21) > On 2018-09-09 2:46 PM, rguenther at suse dot de wrote: > > In the last patch you replace arg0 || arg1 with arg0 & & arg1, that looks > > wrong. Otherwise the patch looks OK. > It was intentional. See the comment in dojump.c: > > /* If function pointers need to be "canonicalized" before they can > be reliably compared, then canonicalize them. > Only do this if *both* sides of the comparison are function pointers. > If one side isn't, we want a noncanonicalized comparison. See PR > middle-end/17564. */ > if (targetm.have_canonicalize_funcptr_for_compare () > && POINTER_TYPE_P (TREE_TYPE (treeop0)) > && POINTER_TYPE_P (TREE_TYPE (treeop1)) > && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (treeop0))) > && FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (treeop1 > > Based on this, I thought that we could allow do_store_flag to output a > "scc" instruction > when both sides weren't function or method pointers. Ah, I see. > I just looked at the testcase for middle-end/17564. I think we also > have to handle > pointers to void types. Looks like fix for 17564 was wrong... > > I also missed updating a similar bit of code in match.pd with > POINTER_TYPE_P and > FUNC_OR_METHOD_TYPE_P. > > I'm not 100% certain about the need for the code in fold-const.c and > match.pd. Well, for consistency we probably want them. > Dave
[Bug middle-end/87276] [9 Regression] Buggy tree-ssa optimization introduced in revision 263875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87276 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-12 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 Summary|Buggy tree-ssa optimization |[9 Regression] Buggy |introduced in revision |tree-ssa optimization |263875 |introduced in revision ||263875 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- I will have a look.
[Bug rtl-optimization/87273] [8/9 Regression] ICE in merge_fences, at sel-sched-ir.c:708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87273 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |8.2.1 Target Milestone|--- |8.3
