[Bug fortran/82895] New: An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 Bug ID: 82895 Summary: An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arjen.markus at deltares dot nl Target Milestone: --- Created attachment 42559 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42559&action=edit Sample program exhibiting the bug Background: I want to use OpenMP to parallellise a large DO-loop in one of my programs. Due to the updates to the arrays that are involved and the patterns of in which the updates occur in a sequential run, I can do that via a nested loop, thus avoiding collisions - i.e. both array elements A(i) and A(j) are updated in a single iteration, but by structuring the DO-loop in an outer one that is parallellised and an inner one that is not, I avoid such collisions. To avoid duplication of the code (I need two sets of DO-loops), I want to use an internal routine. The attached program fails as the loop variable j (thread-private) does not get the right value inside the internal routine loop_body. If I change the signature to pass j explicitly as an actual argument, all seems to work well. There is no such problem for the shared arrays. My preliminary conclusion is that such private variables are not passed correctly to internal routines. Sample output (intended: the number of iterations per thread): $ ./chkloop_internal 1 10 2 0 3 0 4 0 5 0 6 0 7 0 8 0 instead of a more evenly spread of the iterations over the threads - actually because the index j has the value 0, the counting does not work at all.
[Bug bootstrap/82670] UBSAN bootstrap broken after recent libsanitizer merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82670 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Nov 8 08:17:02 2017 New Revision: 254518 URL: https://gcc.gnu.org/viewcvs?rev=254518&root=gcc&view=rev Log: PR bootstrap/82670 * ubsan/Makefile.am (ubsan_files): Remove ubsan_init_standalone.cc and ubsan_signals_standalone.cc. * ubsan/Makefile.in: Regenerated. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/ubsan/Makefile.am trunk/libsanitizer/ubsan/Makefile.in
[Bug sanitizer/82792] Fallthrough attribute ignored after label, and before with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 --- Comment #15 from Martin Liška --- Author: marxin Date: Wed Nov 8 08:17:30 2017 New Revision: 254519 URL: https://gcc.gnu.org/viewcvs?rev=254519&root=gcc&view=rev Log: Fix fallthrough attribute ignorance w/ -fsanitize=address (PR sanitizer/82792). 2017-11-08 Martin Liska PR sanitizer/82792 * gimplify.c (expand_FALLTHROUGH_r): Skip IFN_ASAN_MARK. 2017-11-08 Martin Liska PR sanitizer/82792 * g++.dg/asan/pr82792.C: New test. Added: trunk/gcc/testsuite/g++.dg/asan/pr82792.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/82792] Fallthrough attribute ignored after label, and before with address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82792 Martin Liška changed: What|Removed |Added Known to work||8.0 Known to fail||7.2.0 --- Comment #16 from Martin Liška --- Fixed on trunk.
[Bug bootstrap/82670] UBSAN bootstrap broken after recent libsanitizer merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82670 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #16 from Martin Liška --- Matti: Any progress with the reduction?
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-08 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #23 from Eric Botcazou --- The testsuite is still polluted by the warnings about SHT_NULL so it would be nice to do something here.
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #17 from Matti Bryce --- (In reply to Martin Liška from comment #16) > Matti: Any progress with the reduction? Yeah, it's reduced about 20% or so. But it's taken several days just to get this far, so it's going to be quite a while before anything usefully small come of it.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #24 from rguenther at suse dot de --- On Wed, 8 Nov 2017, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > Eric Botcazou changed: > >What|Removed |Added > > Status|UNCONFIRMED |NEW >Last reconfirmed||2017-11-08 > CC||ebotcazou at gcc dot gnu.org > Ever confirmed|0 |1 > > --- Comment #23 from Eric Botcazou --- > The testsuite is still polluted by the warnings about SHT_NULL so it would be > nice to do something here. See the attached patch - it misses SHN_XINDEX handling. I'll come back to this during stage3 if nobody beats me to it.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 Eric Botcazou changed: What|Removed |Added Severity|normal |major
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #25 from Eric Botcazou --- > See the attached patch - it misses SHN_XINDEX handling. I'll come back to > this during stage3 if nobody beats me to it. But AFAICS it doesn't deal with the SHT_NULL thing, does it?
[Bug fortran/82896] New: probably pointer assignement bug in gfortran compiler version 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82896 Bug ID: 82896 Summary: probably pointer assignement bug in gfortran compiler version 7.2.0 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeangual at yahoo dot fr Target Milestone: --- Created attachment 42560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42560&action=edit source fortran code The small attached source (100 lines) finish with segmental fault with the latest Mingw release (gcc version 7.2.0 (Rev1, Built by MSYS2 project) and did works very well with the previous version (gcc version 6.1.0 (x86_64-posix-seh, Built by MinGW-W64 project) . I send this bug to Mingw org. and this answer is : This looks like a code generation issue in gcc itself. Looking at the assembly that was generated, it appears the vtbl function pointers aren't being set properly for the extension class. Please report this to the gcc bugzilla at https://gcc.gnu.org/bugzilla/, as the code generated is invalid on a linux machine as well (verified with gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) Bug description : I reduced the code source to the minimal size and when we reduce more the code turn normaly. we use in this code the latets oriented object specifications proposed with the 2003 fortran release. I have a big load experience of Fortran bugs and i am sure that is a bug compiler because in the code source there is not any array, ni parameter mismath ni other instruction that usely causes bugs. Moreover ther are only five instructions between the start program and the segmental fault : allocate (mate) Call mate%Creer_situation_acier(1) allocate (pt_situation) pt_situation%m_pt_materiau => this Call pt_situation%Set_Type_Situation_projet (type_situation) The main instruction in cause in the bug is the pointer assignement in the routine Creer_situation_acier : pt_situation%m_pt_materiau => this and the segmentaion fault appears with the folower instruction : Call pt_situation%Set_Type_Situation_projet (type_situation) The compilation instruction is : gfortran *.f90 the bug doesnot depends on the compilation options like optimisation level and degug level. Thanks for your help.
[Bug target/82897] New: Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897
Bug ID: 82897
Summary: Unnecessary zero-extension when loading mask register
from memory
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following testcase:
--cut here--
__mmask16 m;
__m512i
foo (__m512i x, __m512i y, int a)
{
return _mm512_mask_srai_epi32 (y, m, x, a);
}
--cut here--
compiles with -O2 -mavx512f to:
movl%edi, %edi
vmovdqa64 %zmm1, %zmm2
--> movzwl m(%rip), %eax
vmovq %rdi, %xmm3
--> kmovw %eax, %k1
vpsrad %xmm3, %zmm0, %zmm2{%k1}
vmovdqa64 %zmm2, %zmm0
ret
Note unnecessary zero-extension when mask reg is loaded from memory.
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 --- Comment #1 from Tony E Lewis --- I should say that I've also raised the same issue against libc++ : https://bugs.llvm.org/show_bug.cgi?id=35235
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-11-08 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Created attachment 42561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42561&action=edit Prototype patch This patch changes predicate for mask register to nonimmediate operand. This way, combine is able to simplify sequences of zero-extend and subreg operators to a simple move.
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897
--- Comment #2 from Uroš Bizjak ---
Hm, why does middle-end convert to integer in the first place? .optimized tree
dump reads:
foo (__m512i x, __m512i y, int a)
{
short unsigned int m.1_1;
int _2;
vector(16) int _7;
vector(16) int _8;
vector(16) int _9;
vector(8) long long int _10;
[local count: 1]:
m.1_1 = m;
_2 = (int) m.1_1;
_7 = VIEW_CONVERT_EXPR(y_5(D));
_8 = VIEW_CONVERT_EXPR(x_6(D));
_9 = __builtin_ia32_psradi512_mask (_8, a_3(D), _7, _2);
_10 = VIEW_CONVERT_EXPR<__m512i>(_9);
return _10;
}
[Bug middle-end/82898] New: Aliasing knowledge is not used to replace memmove with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
Bug ID: 82898
Summary: Aliasing knowledge is not used to replace memmove with
memcpy
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
This has been resolved once in Bug 21602 but now the issue appears again:
void foo(int* i, const float* f) {
__builtin_memmove(i, f, 1024*1024);
}
Produces assembly:
foo(int*, float const*):
mov edx, 1048576
jmp memmove <=== Could be memcpy
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #18 from Martin Liška --- Created attachment 42562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42562&action=edit Reduce test-case I've got following test-case that started with r253608: $ ./xg++ -B. -std=c++1z -mavx512dq -c /tmp/repro.ii cc1plus: internal compiler error: Segmentation fault 0x1203f31 crash_signal ../../gcc/toplev.c:326 0x1575044 decl_assembler_name(tree_node*) ../../gcc/tree.c:672 0x92d913 hash_table::find_slot_with_hash(tree_node* const&, unsigned int, insert_option) ../../gcc/hash-table.h:892 0x929e90 record_mangling(tree_node*, bool) ../../gcc/cp/decl2.c:4405 0x989780 mangle_decl(tree_node*) ../../gcc/cp/mangle.c:3842 0x1575094 decl_assembler_name(tree_node*) ../../gcc/tree.c:673 0xc7e3ed symtab_node::get_comdat_group_id() ../../gcc/cgraph.h:215 0xc96888 analyze_functions ../../gcc/cgraphunit.c:1081 0xc9bac3 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2666 $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: x86_64-w64-mingw32 Configured with: ../configure --enable-languages=c,c++ --disable-multilib --disable-libsanitizer --prefix=/home/marxin/bin/gcc --disable-bootstrap --target=x86_64-w64-mingw32 Thread model: win32 gcc version 8.0.0 20171010 (experimental) (GCC) Which will be probably another problem as you're using GCC 7.2 Nathan can you please take a look?
[Bug middle-end/82899] New: *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
Bug ID: 82899
Summary: *this in constructors could not alias with reference
input parameters of the same type
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following code
struct test {
char data[2] = {1, 2};
test(const test& v);
~test(){} // non trivial destructor!
};
test::test(const test& v)
: data{ v.data[0], v.data[0] }
{}
Produces the following assembly:
test::test(test const&):
movzx eax, BYTE PTR [rsi]
mov BYTE PTR [rdi], al
movzx eax, BYTE PTR [rsi] <=== This is not required
mov BYTE PTR [rdi+1], al
ret
`*this` could not alias with `v` because `v` is already constructed while *this
is still being constructed. Any attempt to make `*this` alias `v` is a UB:
#1
test t; // let's assume that `test` is default constructible
new (&t) test(t); // UB: destructor was not called
#2
std::aligned_storage_t t;
new (&t) test(reinterpret_cast(t)); // UB: test was not constructed on t
#3 (doubtful)
test t; // let's assume that `test` has trivial destructor
// t.~test(); // users may skip this call
new (&t) test(t); // extremely wired
Please, either assume that *this never alias input parameter of the same type
OR
assume that *this never alias input parameter of the same type if the
destructor is not trivial.
This aliasing issue affects performance of all the copy and move constructors.
[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- Fixed everywhere for powerpc. Does hppa still need backports?
[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Segher Boessenkool --- Oh I cannot read. Fixed everywhere.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #26 from rguenther at suse dot de --- On Wed, 8 Nov 2017, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 > > --- Comment #25 from Eric Botcazou --- > > See the attached patch - it misses SHN_XINDEX handling. I'll come back to > > this during stage3 if nobody beats me to it. > > But AFAICS it doesn't deal with the SHT_NULL thing, does it? It does by removing the SHT_NULL sections. The patch should work - you can double-check - it just doesn't handle the "corner case" of more than 32000 input sections correctly when rewriting the symbol table.
[Bug fortran/82896] probably pointer assignement bug in gfortran compiler version 7.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82896 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This problem seems fixed on 7.2.1 (r254377) and trunk (8.0).
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 --- Comment #7 from Janne Blomqvist --- Author: jb Date: Wed Nov 8 11:51:00 2017 New Revision: 254526 URL: https://gcc.gnu.org/viewcvs?rev=254526&root=gcc&view=rev Log: PR 82869 Introduce logical_type_node and use it Earlier GFortran used to redefine boolean_type_node, which in the rest of the compiler means the C/C++ _Bool/bool type, to the Fortran default logical type. When this redefinition was removed, a few issues surfaced. Namely, 1) PR 82869, where we created a boolean tmp variable, and passed it to the runtime library as a Fortran logical variable of a different size. 2) Fortran specifies that logical operations should be done with the default logical kind, not in any other kind. 3) Using 8-bit variables have some issues, such as - on x86, partial register stalls and length prefix changes. - s390 has a compare with immediate and jump instruction which works with 32-bit but not 8-bit quantities. This patch addresses these issues by introducing a type logical_type_node which is a Fortran LOGICAL variable of default kind. It is then used in places were the Fortran standard mandates, as well as for compiler generated temporary variables. For x86-64, using the Polyhedron benchmark suite, no performance or code size difference worth mentioning was observed. Regtested on x86_64-pc-linux-gnu. gcc/fortran/ChangeLog: 2017-11-08 Janne Blomqvist PR 82869 * convert.c (truthvalue_conversion): Use logical_type_node. * trans-array.c (gfc_trans_allocate_array_storage): Likewise. (gfc_trans_create_temp_array): Likewise. (gfc_trans_array_ctor_element): Likewise. (gfc_trans_array_constructor_value): Likewise. (trans_array_constructor): Likewise. (trans_array_bound_check): Likewise. (gfc_conv_array_ref): Likewise. (gfc_trans_scalarized_loop_end): Likewise. (gfc_conv_array_extent_dim): Likewise. (gfc_array_init_size): Likewise. (gfc_array_allocate): Likewise. (gfc_trans_array_bounds): Likewise. (gfc_trans_dummy_array_bias): Likewise. (gfc_conv_array_parameter): Likewise. (duplicate_allocatable): Likewise. (duplicate_allocatable_coarray): Likewise. (structure_alloc_comps): Likewise (get_std_lbound): Likewise (gfc_alloc_allocatable_for_assignment): Likewise * trans-decl.c (add_argument_checking): Likewise (gfc_generate_function_code): Likewise * trans-expr.c (gfc_copy_class_to_class): Likewise (gfc_trans_class_array_init_assign): Likewise (gfc_trans_class_init_assign): Likewise (gfc_conv_expr_present): Likewise (gfc_conv_substring): Likewise (gfc_conv_cst_int_power): Likewise (gfc_conv_expr_op): Likewise (gfc_conv_procedure_call): Likewise (fill_with_spaces): Likewise (gfc_trans_string_copy): Likewise (gfc_trans_alloc_subarray_assign): Likewise (gfc_trans_pointer_assignment): Likewise (gfc_trans_scalar_assign): Likewise (fcncall_realloc_result): Likewise (alloc_scalar_allocatable_for_assignment): Likewise (trans_class_assignment): Likewise (gfc_trans_assignment_1): Likewise * trans-intrinsic.c (build_fixbound_expr): Likewise (gfc_conv_intrinsic_aint): Likewise (gfc_trans_same_strlen_check): Likewise (conv_caf_send): Likewise (trans_this_image): Likewise (conv_intrinsic_image_status): Likewise (trans_image_index): Likewise (gfc_conv_intrinsic_bound): Likewise (conv_intrinsic_cobound): Likewise (gfc_conv_intrinsic_mod): Likewise (gfc_conv_intrinsic_dshift): Likewise (gfc_conv_intrinsic_dim): Likewise (gfc_conv_intrinsic_sign): Likewise (gfc_conv_intrinsic_ctime): Likewise (gfc_conv_intrinsic_fdate): Likewise (gfc_conv_intrinsic_ttynam): Likewise (gfc_conv_intrinsic_minmax): Likewise (gfc_conv_intrinsic_minmax_char): Likewise (gfc_conv_intrinsic_anyall): Likewise (gfc_conv_intrinsic_arith): Likewise (gfc_conv_intrinsic_minmaxloc): Likewise (gfc_conv_intrinsic_minmaxval): Likewise (gfc_conv_intrinsic_btest): Likewise (gfc_conv_intrinsic_bitcomp): Likewise (gfc_conv_intrinsic_shift): Likewise (gfc_conv_intrinsic_ishft): Likewise (gfc_conv_intrinsic_ishftc): Likewise (gfc_conv_intrinsic_leadz): Likewise (gfc_conv_intrinsic_trailz): Likewise (gfc_conv_intrinsic_mask): Likewise (gfc_conv_intrinsic_spacing): Likewise (gfc_conv_intrinsic_rrspacing): Likewise (gfc_conv_intrinsic_size): Likewise (gfc_conv_intrinsic_sizeof): Likewise (gfc_conv_intrinsic_transfer): Likewise (gfc_conv_allocated): Likewise (gfc_conv_associated): Likewise (gfc_conv
[Bug sanitizer/82869] c_associated does not always give false for null pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82869 --- Comment #8 from Janne Blomqvist --- Fixed on trunk. I'll wait a few days for possible fallout and then backport it to the GCC-7 release as well.
[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898 --- Comment #1 from Marc Glisse --- At least in the gcc model, the type of a pointer is meaningless as long as you do not dereference it using that type, so I am not sure what can be done here.
[Bug other/82880] [6/7/8 Regression] gcc --help=target --help=optimizers hangs on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82880 Richard Biener changed: What|Removed |Added Version|unknown |7.2.0 Target Milestone|--- |6.5
[Bug middle-end/82885] memcpy does not propagate aliasing knowledge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82885 Richard Biener changed: What|Removed |Added Keywords||alias, missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-08 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- It's also difficult because there's no representation for "[ch1, ch1 + 1024*1024[ and [ch2, ch2 + 1024+1024[" do not overlap.
[Bug c++/82888] terrible code generation for initialization of POD array members vs. clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82888 --- Comment #6 from Richard Biener --- (In reply to Marc Glisse from comment #4) > The front-end internally uses VEC_INIT_EXPR, and gimplifies it to a loop. I > believe we should end up with an empty CONSTRUCTOR instead. Indeed. Note that using memset in the gimplification might pessimize followup optimization, but maybe it's not too important cases only (it forces the destination TREE_ADDRESSABLE).
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 --- Comment #27 from Eric Botcazou --- > It does by removing the SHT_NULL sections. The patch should work - you > can double-check - it just doesn't handle the "corner case" of more > than 32000 input sections correctly when rewriting the symbol table. Ah, sorry, it works fine indeed (after minor tweaks to make it apply). Thanks!
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 Eric Botcazou changed: What|Removed |Added Attachment #42225|0 |1 is obsolete|| --- Comment #28 from Eric Botcazou --- Created attachment 42563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42563&action=edit Updated patch to really remove discarded sections
[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
CC||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Indeed - nothing can be done here. Unsure whether the C standard says anything
about it. Does
int main()
{
int i;
(float *)&i;
}
already invoke undefined behavior? I guess not.
[Bug middle-end/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
Richard Biener changed:
What|Removed |Added
Keywords||alias, missed-optimization
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
Would it be valid to make 'this' __restrict? Is it valid to do
struct X { int i; };
struct Y : X { Y(Y *); int k; };
Y::Y(Y *x)
{
k = x->i;
}
int main()
{
Y y(&y);
}
? That is, access members of the base class which should be initialized
already?
This would mean using __restrict isn't valid.
[Bug middle-end/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 --- Comment #2 from Antony Polukhin --- Looks like [class.ctor] paragraph 14 covers this case: "During the construction of an object, if the value of the object or any of its subobjects is accessed through a glvalue that is not obtained, directly or indirectly, from the constructor’s this pointer, the value of the object or subobject thus obtained is unspecified."
[Bug middle-end/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 --- Comment #3 from Antony Polukhin --- BTW, Clang warns on code like Y y(y) warning: variable 'y' is uninitialized when used within its own initialization [-Wuninitialized] Y y(y); ~ ^ GCC may add same warning
[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-08 Component|middle-end |c++ Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- (In reply to Antony Polukhin from comment #2) > Looks like [class.ctor] paragraph 14 covers this case: > > "During the construction of an object, if the value of the object or any of > its subobjects is accessed through > a glvalue that is not obtained, directly or indirectly, from the > constructor’s this pointer, the value of the > object or subobject thus obtained is unspecified." Yeah, sounds like covering this case. Thus we can make 'this' restrict in constructors (and possibly assignment operators if self-assignment is forbidden). It would be "restrict" in the GCC middle-end sense, not the C specification sense though, barring some extra clarification on "not obtained, directly or indirectly, from the constructor's this pointer". We conservatively propagate what can point to a restrict parameters object. Thus, C++ FE issue.
[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 --- Comment #5 from Richard Biener --- (In reply to Antony Polukhin from comment #3) > BTW, Clang warns on code like Y y(y) > > warning: variable 'y' is uninitialized when used within its own > initialization [-Wuninitialized] > Y y(y); > ~ ^ > > GCC may add same warning Can you open a bugreport?
[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
--- Comment #3 from Antony Polukhin ---
> At least in the gcc model, the type of a pointer is meaningless
> as long as you do not dereference it using that type<...>
OK, does dereferencing the pointers change anything?
void foo(int* i, const float* f) {
i[0] = f[0]; // Does it triggers the aliasing logic?
__builtin_memmove(i, f, 1024*1024);
}
Code from above still uses memmove, instead of memcpy.
[Bug c++/82900] New: Warn on initialization with self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82900
Bug ID: 82900
Summary: Warn on initialization with self
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Following code
struct Y { Y(Y&){} };
int main() {
Y y(y);
}
Produces a useful warning on clang:
warning: variable 'y' is uninitialized when used within its own initialization
[-Wuninitialized]
Y y(y);
~ ^
It would be nice to have this warning in GCC, especially because this case may
produce unexpected results after implementing Bug 82899
[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899 --- Comment #6 from Antony Polukhin --- Done: Bug 82900
[Bug c++/82900] Warn on initialization with self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82900 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-08 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
--- Comment #4 from rguenther at suse dot de ---
On Wed, 8 Nov 2017, antoshkka at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
>
> --- Comment #3 from Antony Polukhin ---
> > At least in the gcc model, the type of a pointer is meaningless
> > as long as you do not dereference it using that type<...>
>
> OK, does dereferencing the pointers change anything?
>
> void foo(int* i, const float* f) {
> i[0] = f[0]; // Does it triggers the aliasing logic?
for GCC it says that at *f the dynamic type at function entry was
float and after the assignment that of *i is now int. It doesn't
say that f != i.
You'd have to do
global_i = *i;
global_f = *f;
which would be only valid if i != f (and thus they are non-overlapping
because alignof of both is the same as the size)
> __builtin_memmove(i, f, 1024*1024);
> }
>
> Code from above still uses memmove, instead of memcpy.
Yes. For bigger sizes than alignof I'm sure it doesn't work.
For __builtin_memmove (i, f, 4); it doesn't work because we
don't derive context sensitive points-to (and I have a hard
time thinking of an efficient and effective way of doing that).
For the small sizes we instead optimize the memmove as a
read from *f and then a store to *i.
[Bug c/82892] Spelling hints do not take into account missing compiler options (e.g. -fopenmp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82892 --- Comment #2 from David Malcolm --- Thanks for filing this. I think a natural way to implement this would be on top of the deferred_diagnostic patch kit here, see e.g.: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00145.html (that one's still waiting review) and: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00437.html (I hope to have a go at implementing this for gcc 8 stage 1, but am knee-deep in another bug right now)
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Because builtins are treated like any other function calls, and if short/char args are promoted for normal calls, they are promoted for builtins too.
[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- The contained functions access the original variables, not the privatized ones, therefore your testcase has unspecified behavior. Don't do that.
[Bug c++/82247] [concepts] Name deduction in concepts fails depending on the argument type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82247 Joël Lamotte changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Joël Lamotte --- I confirm that the code is valid and my understanding of part of two-phase lookup mislead me to not understand why these lines fails compiling.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 82247, which changed state. Bug 82247 Summary: [concepts] Name deduction in concepts fails depending on the argument type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82247 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 --- Comment #2 from Arjen Markus --- Clear, so the workaround I found actually constitutes the proper method of doing this?
[Bug target/82863] [8 Regression] ICE in verify_flow_info building SH libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82863 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Let me take a look.
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 --- Comment #4 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #3) > Because builtins are treated like any other function calls, and if > short/char args are promoted for normal calls, they are promoted for > builtins too. Indeed. Disabling TARGET_PROMOTE_PROTOTYPES gets us the direct move from memory. So... do we really need to promote all these builtins that usually result in a well known instruction? Is there a way to mark (some of ?) them with a "nopromote" flag?
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897
--- Comment #5 from Uroš Bizjak ---
Also,
#include
__mmask16 m;
__m512i zzz;
__m512i
foo (__m512i x, __m512i y, int a)
{
zzz = _mm512_mask_slli_epi32 (y, m, x, a);
return _mm512_mask_srai_epi32 (y, m, x, a);
}
defeats the proposed prototype patch, resulting in:
vmovd %edi, %xmm2
vmovdqa64 %zmm1, %zmm3
movzwl m(%rip), %eax
vmovdqa64 %zmm1, %zmm4
kmovw %eax, %k1
vpslld %xmm2, %zmm0, %zmm3{%k1}
vpsrad %xmm2, %zmm0, %zmm4{%k1}
vmovdqa64 %zmm3, zzz(%rip)
vmovdqa64 %zmm4, %zmm0
ret
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 --- Comment #6 from Marek Polacek --- There is "type generic" attribute which disables certain promotions I think (or at least float -> double).
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 --- Comment #7 from Uroš Bizjak --- Another idea is to add an "nopromote" attribute to builtin decl (in ix86_Add_new_buitins), detect this attribute in TARGET_PROMOTE_PROTOTYPES and disable promotion in this case. If this approach works, we can perhaps selectively add "nopromote" attribute to masked builtins.
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 --- Comment #8 from Jakub Jelinek --- That does something different though. But there is in C: if (targetm.calls.promote_prototypes (fundecl ? TREE_TYPE (fundecl) : 0) && INTEGRAL_TYPE_P (type) && (TYPE_PRECISION (type) < TYPE_PRECISION (integer_type_node))) parmval = default_conversion (parmval); and in C++: else if (targetm.calls.promote_prototypes (type) && INTEGRAL_TYPE_P (type) && COMPLETE_TYPE_P (type) && tree_int_cst_lt (TYPE_SIZE (type), TYPE_SIZE (integer_type_node))) type = integer_type_node; and else if (targetm.calls.promote_prototypes (type) && INTEGRAL_TYPE_P (type) && COMPLETE_TYPE_P (type) && tree_int_cst_lt (TYPE_SIZE (type), TYPE_SIZE (integer_type_node))) val = cp_perform_integral_promotions (val, complain); This shows a clear inconsistency between C and C++, C passes the FUNCTION_TYPE, while C++ passes the argument type. If all the FEs passed the FUNCTION_TYPE/METHOD_TYPE at least, then i386 target hook could decide say based on some custom attribute you'd use on those builtins. Or we could change the target hook further and pass a fndecl (if known) and type to the target hook.
[Bug rtl-optimization/82889] Unnecessary sign extension of int32 to int64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||law at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
That is because the signed integer pos needs to be extended to 64-bit sizetype
for the array index and we only have the knowledge that pos is >= 0 in that
part of code during vrp passes and so the expansion or REE pass or similar
can't easily figure out that ZERO_EXTEND could be used the same as SIGN_EXTEND
and pick one that is cheaper.
Note, even using:
int
foo (int *table, int *ht, unsigned hash, unsigned mask)
{
unsigned long probe, i;
for (probe = hash & mask, i = 1;; ++i)
{
int pos = ht[probe];
if (pos >= 0)
{
if (table[(unsigned) pos] == 42)
return 1;
}
else if (pos & 1)
return 0;
probe += i;
probe &= mask;
}
}
doesn't help, because vrp pass optimize away the unsigned cast, because it
knows that pos in that chunk of code is >= 0, but not in others, so it can't be
preserved in range information.
Note we don't even optimize
int x;
long long
foo (void)
{
if (x < -1)
return 73;
int y = x + 1;
return y;
}
where the value range for y is known to be [0, INT_MAX] and so we should know
that when extending y to wider type both zero and sign extension give the same
result. Dunno how the middle-end would know that zero_extend is cheaper though
(in this case really for free), perhaps the REE pass ought to know that.
[Bug rtl-optimization/82889] Unnecessary sign extension of int32 to int64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889 --- Comment #2 from Jakub Jelinek --- On the other side, in REE nonzero_bits on the operand of SIGN_EXTEND on the last testcase above doesn't return 0x7fff, but 0x, maybe it is too late to use SSA_NAME_RANGE_INFO at that point. So, perhaps use range info (possibly improved with the on-demand VRP) in the expander when emitting a SIGN_EXTEND or ZERO_EXTEND and ask the backend what is generally cheaper to use if the value range indicates value between 0 and signed integral maximum of the corresponding precision. Then we'd use ZERO_EXTEND on x86 any time we'd otherwise emit SIGN_EXTEND if range info tells us the MSB is clear.
[Bug libgomp/82901] New: GOACC_declare calls GOACC_enter_exit_data with async arg 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82901 Bug ID: 82901 Summary: GOACC_declare calls GOACC_enter_exit_data with async arg 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: --- GOACC_enter_exit_data has this prototype: ... void GOACC_enter_exit_data (int device, size_t mapnum, void **hostaddrs, size_t *sizes, unsigned short *kinds, int async, int num_waits, ...) ... And GOACC_declare calls GOACC_enter_exit_data with async arg 0: ... case GOMP_MAP_DELETE: GOACC_enter_exit_data (device, 1, &hostaddrs[i], &sizes[i], &kinds[i], 0, 0); ... Async arg zero means the first async queue. The declare directive has no async clause, so the arg should be GOMP_ASYNC_SYNC.
[Bug libgomp/82901] GOACC_declare calls GOACC_enter_exit_data with async arg 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82901 --- Comment #1 from Tom de Vries --- Created attachment 42564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42564&action=edit Tentative patch
[Bug tree-optimization/78821] GCC7: Copying whole 32 bits structure field by field not optimised into copying whole 32 bits at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78821 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Nov 8 15:46:58 2017 New Revision: 254536 URL: https://gcc.gnu.org/viewcvs?rev=254536&root=gcc&view=rev Log: PR tree-optimization/78821 * gimple-ssa-store-merging.c (struct store_operand_info): Add bit_not_p data member. (store_operand_info::store_operand_info): Initialize it to false. (pass_store_merging::terminate_all_aliasing_chains): Rewritten to use ref_maybe_used_by_stmt_p and stmt_may_clobber_ref_p on lhs of each store in the group, and if chain_info is non-NULL, to ignore altogether that chain. (compatible_load_p): Fail if bit_not_p does not match. (imm_store_chain_info::output_merged_store): Handle bit_not_p loads. (handled_load): Fill in bit_not_p. Handle BIT_NOT_EXPR. (pass_store_merging::process_store): Adjust terminate_all_aliasing_chains calls to pass NULL in all current spots, call terminate_all_aliasing_chains newly when adding a store into a chain with non-NULL chain_info. * gcc.dg/store_merging_2.c: Expect 3 store mergings instead of 2. * gcc.dg/store_merging_13.c (f7, f8, f9, f10, f11, f12, f13): New functions. (main): Test also those. Expect 13 store mergings instead of 6. * gcc.dg/store_merging_14.c (f7, f8, f9): New functions. (main): Test also those. Expect 9 store mergings instead of 6. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/store_merging_13.c trunk/gcc/testsuite/gcc.dg/store_merging_14.c trunk/gcc/testsuite/gcc.dg/store_merging_2.c
[Bug c++/82900] Warn on initialization with self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82900 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- Self-initialization was used as an idiom to suppress uninitialized value warnings. Has this changed?
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #12 from Niels Möller --- It would be nice with some way to annotate the asm to have it treated in the same as a possibly trapping division or pointer dereference. E.g., adding "trap" to the clobber list, somewhat similar to "memory". This would be a weaker constraint than volatile, since it would allow the compiler to reorder the asm relative to other instructions, including loads and stores, but it can't move it out of a conditional. Do you think that's a reasonable addition?
[Bug rtl-optimization/82889] Unnecessary sign extension of int32 to int64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law --- That would seem possible. We'd turn expansion into a dominator walk with embedded range analysis. We'd then be able to perform queries as we expand from trees/ssa into RTL. I haven't looked at the tree/ssa->rtl expansion bits since Matz's (?) reorganization a few years ago. I don't know how difficult it would be to turn it into a dominator walk over the blocks. Alternately we'd have to wait for Andrew's work to be able to perform the queries purely on-demand.
[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #5 from Martin Sebor ---
(In reply to Antony Polukhin from comment #0)
Declaring the pointers restrict has the effect you are looking for (calling
memcpy).
Without the restrict keyword the pointers cannot be assumed not to alias one
another even if they point to different types because the C standard aliasing
rules allow objects of incompatible types to be accessed via an lvalue of a
character type (e.g., such as by memmove).
For the case of
void foo(int* i, const float* f)
{
i[0] = f[0]; // Does it triggers the aliasing logic?
__builtin_memmove(i, f, 1024*1024);
}
the assignment implies that the objects pointed to by i and f are distinct
(otherwise the access would be undefined) and so the memove call could be
replaced by memcpy. Though whether or not it would gain much, if anything, is
a separate question.
[Bug target/82897] Unnecessary zero-extension when loading mask register from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82897 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ubizjak at gmail dot com |unassigned at gcc dot gnu.org --- Comment #9 from Uroš Bizjak --- Oh well ... it looks that the implementation wandered into the areas of the compiler I'm not familiar with ... Unassigning myself, considering that at the end of a day, the prototype patch looks more like a band-aid for some different problem.
[Bug c++/82899] *this in constructors could not alias with reference input parameters of the same type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=81009
--- Comment #7 from Martin Sebor ---
See also bug 81009 for a related optimization opportunity (this one having to
do with const objects/members).
A ctor declaration cannot be qualified but G++ does seem top allow the
__restrict qualifier on a ctor definition outside the class with the expected
effect.
Explicitly annotating the argument of the copy ctor with __restrict keyword is
valid and has the expected effect:
$ cat t.C && gcc -O2 -S -fdump-tree-optimized=/dev/stdout t.C
struct test {
char data[2] = {1, 2};
test(const test& v);
~test(){} // non trivial destructor!
};
test::test(const test& __restrict v) /* __restrict here works too */
: data{ v.data[0], v.data[0] }
{}
;; Function test::test (_ZN4testC2ERKS_, funcdef_no=4, decl_uid=2331,
cgraph_uid=4, symbol_order=4)
test::test (struct test * const restrict this, const struct test & v)
{
char _1;
[local count: 1]:
_1 = *v_5(D).data[0];
*this_3(D).data[0] = _1;
*this_3(D).data[1] = _1;
return;
}
[Bug tree-optimization/82902] New: ICE verify_ssa failed during GIMPLE pass: phiprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82902 Bug ID: 82902 Summary: ICE verify_ssa failed during GIMPLE pass: phiprop Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jvb at cyberscience dot com Target Milestone: --- Created attachment 42565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42565&action=edit Reduced test case, compile with -O1 -ftree-vrp (or -O2) Compiling a particular file (reduce case attached) with -O1 -ftree-vrp (or -O2) fails with: test1.c: In function ‘a’: test1.c:49:5: error: definition in block 8 does not dominate use in block 5 int a( LT elt, CEV_T *CEV ) ^ for SSA_NAME: _5 in statement: # .MEM_22 = VDEF <.MEM_8> *_5 = MEM[(struct EV_T *)_16]; during GIMPLE pass: phiprop test1.c:49:5: internal compiler error: verify_ssa failed 0xe20803 verify_ssa(bool, bool) ../../gcc-trunk/gcc/tree-ssa.c:1188 0xb6dcbd execute_function_todo ../../gcc-trunk/gcc/passes.c:2001 0xb6ea2e execute_todo ../../gcc-trunk/gcc/passes.c:2048 Works with -O2 -no-tree-vrp. The ICE is from a trunk build, gcc version 8.0.0 20171108 (x86_64-pc-linux-gnu) Gcc 7.0 to 7.2 produces invalid code which will SEGV at runtime (same result on many platforms). Gcc 6.3 and earlier produced working code. To reproduce: gcc -O1 -ftree-vrp test1.c
[Bug c++/52167] self-assignment should at least produce use-of-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167 Martin Sebor changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #6 from Martin Sebor --- *** Bug 82900 has been marked as a duplicate of this bug. ***
[Bug c++/82900] Warn on initialization with self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82900
Martin Sebor changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=48483
Resolution|--- |DUPLICATE
--- Comment #3 from Martin Sebor ---
I believe this bug is a dupe of pr52167. See also pr48483 for a
similar/related request.
As an aside, the test case in comment #1 is fine (as in has well-defined
semantics) because there is no access to the yet-uninitialized object.
Changing the test case so that the copy ctor accesses the argument and
compiling it with optimization does produce a warning:
$ cat t.C && gcc -O2 -S -Wall -Wextra t.C
struct Y { int i; Y (Y &y): i (y.i) { } };
int main() {
Y y(y);
}
t.C: In function ‘int main()’:
t.C:4:5: warning: ‘y.Y::i’ is used uninitialized in this function
[-Wuninitialized]
Y y(y);
^
*** This bug has been marked as a duplicate of bug 52167 ***
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #19 from Nathan Sidwell --- I can take a look at the trunk crash, but not till next week. You could try https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00384.html, which I've yet to commit.
[Bug c++/52167] self-initialization should at least produce use-of-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Summary|self-assignment should at |self-initialization should |least produce |at least produce |use-of-uninitialized|use-of-uninitialized |warning |warning --- Comment #7 from Martin Sebor --- Let me adjust the Summary to better reflect the request.
[Bug ipa/82903] New: [8 regression] gcc.dg/tree-prof/20050826-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82903 Bug ID: 82903 Summary: [8 regression] gcc.dg/tree-prof/20050826-2.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com CC: marxin at gcc dot gnu.org Target Milestone: --- r254452 triggers this: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.dg/tree-prof/20050826-2.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -fdump-tree-dom2-all -fprofile-use -D_PROFILE_USE -lm -o /work/gcc/testsuite/gcc3/20050826-2.x02 PASS: gcc.dg/tree-prof/20050826-2.c compilation, -fprofile-use -D_PROFILE_USE PASS: gcc.dg/tree-prof/20050826-2.c execution,-fprofile-use -D_PROFILE_USE FAIL: gcc.dg/tree-prof/20050826-2.c scan-tree-dump-not dom2 "Invalid sum" Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm
[Bug ipa/82903] [8 regression] gcc.dg/tree-prof/20050826-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82903 --- Comment #1 from Andrey Guskov --- gcc.dg/tree-prof/cmpsf-1.c is also affected: PASS: gcc.dg/tree-prof/cmpsf-1.c execution,-fprofile-use -D_PROFILE_USE FAIL: gcc.dg/tree-prof/cmpsf-1.c scan-tree-dump-not dom2 "Invalid sum"
[Bug ipa/82903] [8 regression] gcc.dg/tree-prof/20050826-2.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82903 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-08 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed on darwin too.
[Bug fortran/82904] New: ICE in make_ssa_name_fn, at tree-ssanames.c:261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82904 Bug ID: 82904 Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:261 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Together with -fcoarray=lib at -Os, -O1 or higher : $ cat z1.f90 program p save character(:), allocatable :: x character(:), allocatable :: y[:] allocate (character(3) :: y[*]) allocate (x, source='abc') y[1] = x end $ gfortran-8-20171105 -O2 -c z1.f90 -fcoarray=single $ $ gfortran-8-20171105 -O2 -c z1.f90 -fcoarray=lib during IPA pass: inline z1.f90:8:0: end internal compiler error: Segmentation fault 0xb60fdf crash_signal ../../gcc/toplev.c:324 0xd202c7 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int) ../../gcc/tree-ssanames.c:261 0xbc51fe make_ssa_name ../../gcc/tree-ssanames.h:116 0xbc51fe remap_ssa_name ../../gcc/tree-inline.c:239 0xbc98f7 copy_tree_body_r(tree_node**, int*, void*) ../../gcc/tree-inline.c:1089 0xda5f43 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:1 0xda6133 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:11428 0xbc4b2c remap_type_1 ../../gcc/tree-inline.c:572 0xbc4d21 remap_type(tree_node*, copy_body_data*) ../../gcc/tree-inline.c:601 0xbc4968 remap_type_1 ../../gcc/tree-inline.c:419 0xbc4d21 remap_type(tree_node*, copy_body_data*) ../../gcc/tree-inline.c:601 0xbc9c44 remap_gimple_op_r ../../gcc/tree-inline.c:1000 0xda5f43 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.c:1 0x940c0a walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc/gimple-walk.c:203 0xbc5d9c remap_gimple_stmt ../../gcc/tree-inline.c:1747 0xbc6e94 copy_bb ../../gcc/tree-inline.c:1800 0xbc6e94 copy_cfg_body ../../gcc/tree-inline.c:2735 0xbc6e94 copy_body ../../gcc/tree-inline.c:2972 0xbcb63c expand_call_inline ../../gcc/tree-inline.c:4722 0xbcd45c gimple_expand_calls_inline ../../gcc/tree-inline.c:4940
[Bug fortran/82904] ICE in make_ssa_name_fn, at tree-ssanames.c:261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82904 --- Comment #1 from G. Steinmetz --- Without this explicit "save" in above source, an ICE only occurs with additional option -fno-automatic (which implies "save") : $ cat z2.f90 program p character(:), allocatable :: x character(:), allocatable :: y[:] allocate (character(3) :: y[*]) allocate (x, source='abc') y[1] = x end $ gfortran-8-20171105 -O2 -c z2.f90 -fcoarray=lib $ $ gfortran-8-20171105 -O2 -c z2.f90 -fcoarray=lib -fno-automatic during IPA pass: inline z2.f90:7:0: end internal compiler error: Segmentation fault ...
[Bug tree-optimization/82902] [8 Regression] ICE verify_ssa failed during GIMPLE pass: phiprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82902
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-11-08
CC||trippels at gcc dot gnu.org
Summary|ICE verify_ssa failed |[8 Regression] ICE
|during GIMPLE pass: phiprop |verify_ssa failed during
||GIMPLE pass: phiprop
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
typedef struct el_t {
el_t *next;
int elem[];
} EL;
el_t a, c;
void *b;
void *fn1() {
if (b)
return a.elem;
return c.elem;
}
typedef struct {
int x;
} EV_T;
EV_T *d;
void fn2() {
EV_T *e = (EV_T *)fn1();
d[0] = *e;
}
[Bug rtl-optimization/82904] [7/8 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82904 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||6.4.0 Keywords||ice-on-valid-code Last reconfirmed||2017-11-08 Component|fortran |rtl-optimization CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE in make_ssa_name_fn, at |[7/8 Regression] ICE in |tree-ssanames.c:261 |make_ssa_name_fn, at ||tree-ssanames.c:261 Known to fail||7.2.0, 8.0 --- Comment #2 from Dominique d'Humieres --- Started with revision r235817.
[Bug tree-optimization/82905] New: vector shift forced to 32 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82905
Bug ID: 82905
Summary: vector shift forced to 32 bytes
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno.uy at gmail dot com
Target Milestone: ---
#include
using namespace std;
int const count = 1024;
uint8_t p[count];
void mul(uint16_t m)
{
for (int i = 0; i < count; ++i)
{
p[i] = uint16_t(p[i] * m) >> 8;
}
}
compiled for x86-64 with -O3 generates psrad instructions instead of psrlw
instructions. Also, the pand instructions are not needed.
[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 --- Comment #13 from rguenther at suse dot de --- On November 8, 2017 5:04:39 PM GMT+01:00, "nisse at lysator dot liu.se" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 > >--- Comment #12 from Niels Möller --- >It would be nice with some way to annotate the asm to have it treated >in the >same as a possibly trapping division or pointer dereference. > >E.g., adding "trap" to the clobber list, somewhat similar to "memory". >This >would be a weaker constraint than volatile, since it would allow the >compiler >to reorder the asm relative to other instructions, including loads and >stores, >but it can't move it out of a conditional. > >Do you think that's a reasonable addition? Yes. I think something besides volatile would be useful.
[Bug c++/82906] New: thread_local address not uniqued across shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82906
Bug ID: 82906
Summary: thread_local address not uniqued across shared
libraries
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
Target Milestone: ---
Given
test.h:
inline int *foo() {
static thread_local int i = 42;
return &i;
}
test.cpp:
#include "test.h"
int *bar() { return foo(); }
test2.cpp:
#include "test.h"
#include
int *bar();
int main() {
printf("%d\n", bar() == foo());
return 0;
}
If test.cpp is compiled with "gcc -c -O2 -fPIC test.c", the resulting .o has a
R_X86_64_TLSLD R_X86_64_DTPOFF32 pair.
Compiling the rest of the program with
g++ test.o -shared -o test.so"
g++ test2.cpp test.so -o t -Wl,-rpath="\$ORIGIN"
produces an executable that prints 0 when run. It should print 1, that is,
bar() and foo() should find the same address.
Changing test.o to use general dynamic instead of local dynamic solves the
problem.
[Bug libstdc++/82891] stable_sort() won't compile with function object that takes parameters by non-const reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler --- (In reply to Tony E Lewis from comment #1) > I should say that I've also raised the same issue against libc++ : > > https://bugs.llvm.org/show_bug.cgi?id=35235 There is now an LWG issue submission request waiting to become published for this. I'll return when it has been added.
[Bug c++/82906] thread_local address not uniqued across shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82906 --- Comment #1 from Andrew Pinski --- Could this be a bug in ld.so rather than gcc? Not doing copy relocs for TLS?
[Bug target/82907] New: [8 regression] gcc.target/powerpc/p9-xxbr-1.c fails after r254464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82907 Bug ID: 82907 Summary: [8 regression] gcc.target/powerpc/p9-xxbr-1.c fails after r254464 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This happens on power8 and power9, LE and BE spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-xxbr-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -mcpu=power9 -O3 -ffat-lto-objects -S -o p9-xxbr-1.s PASS: gcc.target/powerpc/p9-xxbr-1.c (test for excess errors) PASS: gcc.target/powerpc/p9-xxbr-1.c scan-assembler-times xxbrd 1 PASS: gcc.target/powerpc/p9-xxbr-1.c scan-assembler-times xxbrh 3 FAIL: gcc.target/powerpc/p9-xxbr-1.c scan-assembler-times xxbrq 4 (found 0 times) PASS: gcc.target/powerpc/p9-xxbr-1.c scan-assembler-times xxbrw 4 seurer@perch:~/gcc/build/gcc-trunk$ diff p9-xxbr-1.s.r254463 p9-xxbr-1.s.r254464 9d8 < xxbrq 34,34 19d17 < xxbrq 34,34 29d26 < xxbrq 34,34 39d35 < xxbrq 34,34 124c120 < .ident "GCC: (GNU) 8.0.0 20171106 (experimental) [trunk revision 254463]" --- > .ident "GCC: (GNU) 8.0.0 20171106 (experimental) [trunk revision > 254464]"
[Bug c++/82906] thread_local address not uniqued across shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82906 --- Comment #2 from Rafael Avila de Espindola --- (In reply to Andrew Pinski from comment #1) > Could this be a bug in ld.so rather than gcc? Not doing copy relocs for TLS? I don't think there is enough information left for ld.so to fix the situation. With local dynamic the relocations in test.so are Relocation section '.rela.dyn' at offset 0x2a8 contains 1 entries: Offset Info Type Sym. ValueSym. Name + Addend 00200ff0 0010 R_X86_64_DTPMOD640 Relocation section '.rela.plt' at offset 0x2c0 contains 1 entries: Offset Info Type Sym. ValueSym. Name + Addend 00201018 00010007 R_X86_64_JUMP_SLO __tls_get_addr + 0 So it will always get variable in test.so.
[Bug target/82855] AVX512: replace OP+movemask with OP_mask+ktest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Nov 8 20:15:42 2017 New Revision: 254552 URL: https://gcc.gnu.org/viewcvs?rev=254552&root=gcc&view=rev Log: PR target/82855 * config/i386/sse.md (_eq3, _eq3_1): Use nonimmediate_operand predicate for operand 1 instead of register_operand. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md
[Bug fortran/82895] An internal routine used in a parallel section (OpenMP) does not get the values of thread-private variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82895 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf --- (In reply to Arjen Markus from comment #2) > Clear, so the workaround I found actually constitutes the proper method of > doing this? Well, Jakub explained the main issue, but there are more problems with your code: - loop_body accesses the host-associated, non-threadprivate variables q, x, and id, and you get data races - it does not make sense that q appears in the omp private declaration, try to make it a local variable in loop_body - the I/O (write) is not thread-safe If possible, try to make the subroutine thread-safe, do not access variables by host association unless properly annotated. Hint: use valgrind or some other thread-checker.
[Bug fortran/82884] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82884 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I have a patch going though regression testing.
[Bug fortran/82884] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82884 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Nov 8 20:56:43 2017 New Revision: 254553 URL: https://gcc.gnu.org/viewcvs?rev=254553&root=gcc&view=rev Log: 2017-11-08 Steven G. Kargl PR fortran/82884 * arith.c (gfc_hollerith2character): Clear pad. 2017-11-08 Steven G. Kargl PR fortran/82884 * gfortran.dg/hollerith_character_array_constructor.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/hollerith_character_array_constructor.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/82884] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2069
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82884 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on truck. Not a regression so no back port.
Bug in std::floor?
Hi,
The following
-
#include
#include
int main()
{
double v = 4.6;
std::cout << "v = " << v << std::endl;
std::cout << "v*100 = " << v*100 << std::endl;
std::cout << "floor(v*100) = " << std::floor(v*100) << std::endl;
}
-
outputs
--
v = 4.6
v*100 = 460
floor(v*100) = 459
--
It that a bug?
If so where is the implementation of floor (so I can study and fix)? I
know it is supposed to be in gcc/builtins.c but I don't understand where.
You may run the program above from http://tpcg.io/QNfhYr
Thanks,
Nil
[Bug ipa/82908] New: [8 regression] gcc.dg/tree-prof/cmpsf-1.c and gcc.dg/tree-prof/20050826-2.c fail starting with r254452
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82908 Bug ID: 82908 Summary: [8 regression] gcc.dg/tree-prof/cmpsf-1.c and gcc.dg/tree-prof/20050826-2.c fail starting with r254452 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- FAIL: gcc.dg/tree-prof/cmpsf-1.c scan-tree-dump-not dom2 "Invalid sum" FAIL: gcc.dg/tree-prof/20050826-2.c scan-tree-dump-not dom2 "Invalid sum" I am seeing this on powerpc64 both LE and BE. Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/20050826-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -fdump-tree-dom2-all -fprofile-generate -D_PROFILE_GENERATE -lm-o /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gcc/20050826-2.x01(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/20050826-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -fdump-tree-dom2-all -fprofile-generate -D_PROFILE_GENERATE -lm -o /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gcc/20050826-2.x01 PASS: gcc.dg/tree-prof/20050826-2.c compilation, -fprofile-generate -D_PROFILE_GENERATE Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/gcc/32::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/gcc/32:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libsanitizer/asan/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libsanitizer/asan/.libs:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.1.0/lib64 spawn [open ...] PASS: gcc.dg/tree-prof/20050826-2.c execution,-fprofile-generate -D_PROFILE_GENERATE Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/20050826-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -fdump-tree-dom2-all -fprofile-use -D_PROFILE_USE -lm-o /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gcc/20050826-2.x02(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/tree-prof/20050826-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -Ofast -fdump-tree-dom2-all -fprofile-use -D_PROFILE_USE -lm -o /home/seurer/gcc/build/gcc-test2/gcc/testsuite/gcc/20050826-2.x02 PASS: gcc.dg/tree-prof/20050826-2.c compilation, -fprofile-use -D_PROFILE_USE Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/gcc/32::/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/gcc/32:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gc
Re: Bug in std::floor?
The gcc-bugs@gcc email list is for automated email from our bug
tracking database, not for reporting bugs, and not for "is this a
bug?" questions. I've CC'd this to the gcc-help list where this is
more appropriate (please remove gcc-bugs from any follow-up replies).
On 08/11/17 23:13 +0200, Nil Geisweiller wrote:
Hi,
The following
-
#include
#include
int main()
{
double v = 4.6;
std::cout << "v = " << v << std::endl;
std::cout << "v*100 = " << v*100 << std::endl;
std::cout << "floor(v*100) = " << std::floor(v*100) << std::endl;
}
-
outputs
--
v = 4.6
v*100 = 460
floor(v*100) = 459
--
It that a bug?
No.
Try:
#include
#include
#include
int main()
{
double v = 4.6;
std::cout << "v = " << std::setprecision(17) << v << std::endl;
std::cout << "v*100 = " << std::setprecision(16) << v*100 << std::endl;
std::cout << "floor(v*100) = " << std::floor(v*100) << std::endl;
}
If so where is the implementation of floor (so I can study and fix)? I
know it is supposed to be in gcc/builtins.c but I don't understand
where.
It doesn't necessarily use __builtin_floor anyway (without optimzation
it just calls the C library's floor(double) function).
You may run the program above from http://tpcg.io/QNfhYr
Thanks,
Nil
[Bug fortran/82841] Segfault in gfc_simplify_transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82841 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org
[Bug fortran/82841] Segfault in gfc_simplify_transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82841 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Nov 8 22:56:58 2017 New Revision: 254555 URL: https://gcc.gnu.org/viewcvs?rev=254555&root=gcc&view=rev Log: 2017-11-08 Steven G. Kargl PR Fortran/82841 * simplify.c(gfc_simplify_transfer): Do not dereference a NULL pointer. Unwrap a short line. 2017-11-08 Steven G. Kargl PR Fortran/82841 * gfortran.dg/transfer_simplify_11.f90: new test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_simplify_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug c/82909] New: Scope of type defined by offsetof() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909
Bug ID: 82909
Summary: Scope of type defined by offsetof() macro
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
/*
* C standard appears to be unclear on scope of new type defined in
* offsetof() macro. Some compilers accept; some reject.
* This is related to C Defect Report 496.
*/
#include /* offsetof() */
int main(void){
if( 0 == (int)offsetof( struct s4 {int i4;}, i4 ) ){
struct s4 s43; /* OK here */
}
{
struct s4 s44; /* Should(?) be OK here */
}
return 0;
}
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #0)
> Compiling the following test (coming from pr55501)
>
> program testmerge3
> implicit none
> integer,parameter::iarray(merge(2,3,.true.)) = 1, i = size(iarray)
> print "(A,99I2)",'i,iarray =',i,iarray
> end program testmerge3
>
> gives the ICE
>
> pr55501_3.f90:4:0:
>
>print "(A,99I2)",'i,iarray =',i,iarray
>
> internal compiler error: in gfc_conv_expr_descriptor, at
> fortran/trans-array.c:6972
>
> (gcc_assert (ss != gfc_ss_terminator);).
If the code is changed to
program testmerge3
implicit none
integer, parameter :: j = merge(2,3,.true.)
integer, parameter :: iarray(j) = 1
integer, parameter :: i = size(iarray)
print "(A,99I2)",'i,iarray =', i, iarray
end program testmerge3
it compiles and runs. The problems appears to be that
when merge is in iarray, then array's shape is not properly
set. For my modified program, we have
(gdb) p *array
$4 = {expr_type = EXPR_VARIABLE, ts = {type = BT_INTEGER, kind = 4, u = {
derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0,
is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 1, shape = 0x201e628c0, symtree = 0x201d58630,
for the original program
(gdb) p *array
$5 = {expr_type = EXPR_VARIABLE, ts = {type = BT_INTEGER, kind = 4, u = {
derived = 0x0, cl = 0x0, pad = 0}, interface = 0x0, is_c_interop = 0,
is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 1, shape = 0x0, symtree = 0x201d58630,
Not sure where the array->shape should be set.
[Bug c/82909] Scope of type defined by offsetof() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 8 Nov 2017, tydeman at tybor dot com wrote:
> /*
> * C standard appears to be unclear on scope of new type defined in
> * offsetof() macro. Some compilers accept; some reject.
> * This is related to C Defect Report 496.
> */
>
> #include /* offsetof() */
>
> int main(void){
>
> if( 0 == (int)offsetof( struct s4 {int i4;}, i4 ) ){
> struct s4 s43; /* OK here */
> }
> {
> struct s4 s44; /* Should(?) be OK here */
> }
This is accepted for -std=c89 (where selection statements don't introduce
block scopes) and rejected for -std=c99 and -std=c11 (where selection
statements do introduce block scopes; C11 6.8.4p3). I don't see a bug
here; what do you think should behave differently?
[Bug c++/82910] New: marking data members private affects code generation of copying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82910
Bug ID: 82910
Summary: marking data members private affects code generation
of copying
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
Consider the following piece of code:
struct pair
{
private:
void* first;
unsigned second;
};
struct other
{
pair get() const;
};
struct my
{
pair get(other const& other);
pair current;
pair* target;
};
pair my::get(other const& other)
{
*target = other.get();
return current;
}
For the function my::get() GCC generates the following (quite inefficient)
code:
my::get(other const&):
pushq %rbx
movq %rdi, %rbx
movq %rsi, %rdi
subq $16, %rsp
call other::get() const
movq 16(%rbx), %rcx
movq %rax, (%rsp)
movq %rdx, 8(%rsp)
movq %rax, (%rcx)
movl 8(%rsp), %eax
movl %eax, 8(%rcx)
movq (%rbx), %rax
movq 8(%rbx), %rdx
addq $16, %rsp
popq %rbx
ret
The expected generated code is:
my::get(other const&):
pushq %rbp
pushq %rbx
movq %rdi, %rbx
subq $8, %rsp
movq 16(%rdi), %rbp
movq %rsi, %rdi
call other::get() const
movq %rax, 0(%rbp) # just storing to *my::target...
movq %rdx, 8(%rbp)
movq (%rbx), %rax # ... and then loading my::current
movq 8(%rbx), %rdx
addq $8, %rsp
popq %rbx
popq %rbp
ret
The issue can be worked around. One way to do this is to make the data members
of pair public. Another way is changing pair::second type to unsigned long (to
match the size of pointer).
It would be great is GCC generates the second code irrespectively of
private-ness or the size of pair::second.
[Bug c/82909] Scope of type defined by offsetof() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909 --- Comment #2 from Fred J. Tydeman --- I agree with your analysis. The behavior is C standard version dependent with respect to the 'if' statement. There is no bug in gcc.
[Bug tree-optimization/82911] New: missing strlen optimization for strncpy with constant strings and constant bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82911
Bug ID: 82911
Summary: missing strlen optimization for strncpy with constant
strings and constant bound
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC can figure out the length of the string created by the first two statements
in f0() but it doesn't do the same in f1(). The optimization in f1() is
possible regardless of which of the constant strings is selected by the
conditional expression because they are both longer than the constant bound
specified by the third argument to strncpy. By making use of the
get_range_strln() function defined in gimple-fold.c the tree-ssa-strlen.c pass
could determine the length of the shortest source string and use it to gate the
same optimization as in the first case.
$ cat c.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
void f0 (char *d)
{
__builtin_strncpy (d, "123", 2);
d[2] = 0;
if (__builtin_strlen (d) != 2) // eliminated, good
__builtin_abort ();
}
void f1 (char *d, _Bool b)
{
__builtin_strncpy (d, b ? "123" : "1234", 2);
d[2] = 0;
if (__builtin_strlen (d) != 2) // not eliminated but could be
__builtin_abort ();
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1887, cgraph_uid=0, symbol_order=0)
f0 (char * d)
{
[local count: 1]:
__builtin_memcpy (d_3(D), "123", 2);
MEM[(char *)d_3(D) + 2B] = 0;
return;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1891, cgraph_uid=1, symbol_order=1)
f1 (char * d, _Bool b)
{
long unsigned int _1;
const char * iftmp.0_2;
[local count: 1]:
if (b_3(D) != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 5000]:
[local count: 1]:
# iftmp.0_2 = PHI <"123"(2), "1234"(3)>
__builtin_strncpy (d_5(D), iftmp.0_2, 2);
MEM[(char *)d_5(D) + 2B] = 0;
_1 = __builtin_strlen (d_5(D));
if (_1 != 2)
goto ; [0.04%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 9996]:
return;
}
