[Bug target/86005] [RISCV] Invalid intermixing of __atomic_* libcalls and inline atomic instruction sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86005 --- Comment #10 from James Y Knight --- I suppose since it doesn't affect most common platforms, nobody's noticed the brokenness yet? ARM is probably the most common architecture which is missing atomics on common CPU models, but when targeting common OSes (Linux, FreeBSD), you get to use the kernel atomic cmpxchg helpers, so the issue doesn't arise there. I haven't tested, but I don't think MIPS16 would be broken, since MIPS has native atomics, just not in the MIPS16 ISA. So, it calls out-of-line libgcc __sync_* routines, implemented in MIPS32 and which use LL/SC instructions. There's no problem mixing those with native load/store instructions. Anyways, for why mixing native load/store with __atomic_* functions is wrong, consider, int value = 4; Thread1: int oldval = __atomic_fetch_add(, 1, __ATOMIC_SEQ_CST); Thread2: __atomic_store_n(, 0, __ATOMIC_SEQ_CST); The only allowable results after executing both threads should be: oldval = 0, value = 1 -- if atomic_store executes first. oldval = 4, value = 0 -- if atomic_fetch_add executes first. But, if you implement __atomic_fetch_add with a lock, and implement __atomic_store with a native store instruction, you may get the "impossible" result, oldval = 4, value = 5 -- if atomic_store executes *during* atomic_fetch_add, between the load and store instructions. Oops.
[Bug c++/86098] canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86098 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/86098] canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86098 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Jun 13 03:33:06 2018 New Revision: 261536 URL: https://gcc.gnu.org/viewcvs?rev=261536=gcc=rev Log: PR c++/86098 - ICE with template placeholder for TTP. * typeck.c (structural_comptypes) [TEMPLATE_TYPE_PARM]: Check CLASS_PLACEHOLDER_TEMPLATE. Added: trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction58.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c
[Bug c++/86098] canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86098
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Summary|[concepts] canonical types |canonical types differ for
|differ for identical types |identical types
--- Comment #1 from Jason Merrill ---
A reduced testcase that doesn't involve concepts:
template class future;
template T&& declval();
template class T>
struct construct_deduced {
template
using deduced_t = decltype(T{declval()...});
template
deduced_t operator()(AN&&... an) const;
};
template
future future_from(T singleSender);
[Bug middle-end/66240] RFE: extend -falign-xyz syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #8 from Jeffrey A. Law --- In response to c#2 and c#3, you're more likely to get that kind of "ideal" solution by hacking the linker rather than the compiler or assembler. The linker is in an ideal position to make these kinds of decisions. You can even use the linker to fill in padding at the end of a function with a nearby teeny-tiny function. You don't want to do that too aggressively though because often functions in the same CU often call each other and you can easily muck up locality if you move a teeny-tiny function too far from its parents or children in the call graph/chain. If you want to get really smart, you start collecting data about the call graph, chains and frequencies, icache and itlb behavior and use that to drive general code layout to improve icache/itlb behavior as well as smart alignments of functions. Been there, done that :-)
[Bug gcov-profile/83878] Line hit counts are sometimes wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83878
--- Comment #2 from Marco Castelluccio ---
Created attachment 44267
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44267=edit
Archive with GCNO, GCDA, source file and GCOV output
Sorry for replying late, but I just managed to find a reproducible small test
case.
g++ --coverage -fno-exceptions -O0 main.cpp
./a.out
gcov -u -b -c main.cpp
The relevant part is:
> function main called 1 returned 100% blocks executed 94%
> 1: 24:int main(void)
> -: 25:{
> 2: 26: Ciao ciao;
> call0 returned 1
> call1 returned 1
> unconditional 2 taken 1
> -: 27:
> 1: 28: ciao.setName("Marco");
Line 26 is clearly executed once, but gcov shows it as executed twice. The same
happens if you have an if block where you call a constructor.
[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86125 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-13 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- Testing a patch.
[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86125 --- Comment #2 from Martin Sebor --- It looks like this is on purpose. match_builtin_function_types, the function that determines whether a declaration of a built-in matches its expected type, has the following comment: /* Subroutine of compare_decls. Allow harmless mismatches in return and argument types provided that the type modes match. This function returns a unified type given a suitable match, and 0 otherwise. */ and it uses TYPE_MODE (type) to decide whether return and argument types are compatible. That makes size_t and char* match on targets where they are the same size, and ditto for int and char*. C++, on the other hand, handles this more sanely and diagnoses the mismatch in both cases: c.c:2:7: warning: declaration of ‘char* strdup(int)’ conflicts with built-in declaration ‘char* strdup(const char*)’ [-Wbuiltin-declaration-mismatch] char* strdup (int);// warning ^~ c.c:3:7: warning: declaration of ‘char* strlen(const char*)’ conflicts with built-in declaration ‘long unsigned int strlen(const char*)’ [-Wbuiltin-declaration-mismatch] char* strlen (const char*);// warning ^~
[Bug libstdc++/86127] New: STL containers do not satisfy container.requirements.general clause 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86127
Bug ID: 86127
Summary: STL containers do not satisfy
container.requirements.general clause 8
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: fidget324 at gmail dot com
Target Milestone: ---
Clause 23.2.1.8 of n4140 states that for containers which obtain memory using
an allocator, "Move constructors obtain an allocator by move construction from
the allocator belonging to the container being copied." At least several STL
containers in libstdc++ do not satisfy this requirement, and in fact perform
several unnecessary copies. I recently reported a similar bug in libc++, which
has since been fixed: https://bugs.llvm.org/show_bug.cgi?id=37694
// test.cpp
#include
#include
#include
#include
#include
template
class my_allocator {
std::allocator __alloc;
public:
using value_type = T;
using propagate_on_container_move_assignment = std::true_type;
template friend class my_allocator;
template
struct rebind {
using other = my_allocator;
};
my_allocator() = default;
template
my_allocator(const my_allocator ) : __alloc(other.__alloc) {
std::cout << "template copy constructor\n";
}
my_allocator(const my_allocator ) : __alloc(other.__alloc) {
std::cout << "copy constructor\n";
}
template
my_allocator(my_allocator &) noexcept : __alloc(other.__alloc) {
std::cout << "template move constructor\n";
}
my_allocator(my_allocator &) noexcept : __alloc(other.__alloc) {
std::cout << "move constructor\n";
}
value_type *allocate(std::size_t n) {
return __alloc.allocate(n);
}
void deallocate(value_type *p, std::size_t n) {
__alloc.deallocate(p, n);
}
};
int main() {
std::cout << "\nforward_list test\n==\n";
std::forward_list> l = {1, 2, 3, 4};
auto l1 = std::move(l);
std::cout << "\nmap test\n==\n";
std::map, my_allocator>> m
= {{1, 2}, {3, 4}};
auto m1 = std::move(m);
std::cout << "\nvector test\n==\n";
std::vector> v = {1, 2, 3, 4};
auto v1 = std::move(v);
}
Compiling with libstdc++ 7.3.1:
$ clang++ -std=c++14 test.cpp
$ ./a.out
forward_list test
==
template copy constructor
move constructor
template copy constructor
template copy constructor
template copy constructor
template copy constructor
move constructor
map test
==
copy constructor
template copy constructor
move constructor
move constructor
vector test
==
move constructor
template copy constructor
template copy constructor
template copy constructor
template copy constructor
The same test using the latest 'master' of libc++:
$ clang++ -stdlib=libc++ -std=c++14 test.cpp
$ ./a.out
forward_list test
==
move constructor
map test
==
move constructor
vector test
==
move constructor
[Bug rtl-optimization/86107] [9 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:42301 with -O -funroll-loops -mavx5124fmaps -mmitigate-rop --param=hot-bb-frequency-fraction=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to Uroš Bizjak from comment #2)
> For some reason, this part of x86_mitigate_rop:
>
> int n_uses;
> reg_class superclass = regrename_find_superclass (head, _uses,
> );
> old_reg = head->regno;
> best_reg = find_rename_reg (head, superclass, ,
> old_reg, false);
> bool ok = regrename_do_replace (head, best_reg);
> gcc_assert (ok);
> if (dump_file)
> fprintf (dump_file, "Chain %d renamed as %s in %s\n", head->id,
>reg_names[best_reg], reg_class_names[superclass]);
>
> does not validate in regrename_do_replace.
>
> The compiler wants to rename:
>
> (insn 1264 1263 1265 5 (set (reg:DI 22 xmm1 [594])
> (reg:DI 3 bx [594])) "pr86107.c":15 85 {*movdi_internal}
> (expr_list:REG_DEAD (reg:DI 3 bx [594])
> (nil)))
>
> to:
>
> (set (reg:DI 22 xmm1 [594])
> (reg:DI 1 dx [594]))
>
> and fails validation of new instruction.
>
> The alternative 20 in *movdi_internal (*v->?r) is marked with
> preferred_for_speed attribute:
>
>(set (attr "preferred_for_speed")
> (cond [(eq_attr "alternative" "10,17,19")
> (symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
> (eq_attr "alternative" "11,18,20")
> (symbol_ref "TARGET_INTER_UNIT_MOVES_TO_VEC")
> ]
> (symbol_ref "true")))
>
> but should not fail verification even for !TARGET_INTER_UNIT_MOVES_TO_VEC
> targets. As a matter of fact, the compilation works with -mtune=intel.
This is by design when the insn belongs to a block that is being
optimised for speed rather than size. It isn't recog per se that
fails, but the validate_change stuff, which is designed for doing
optional optimisations rather than required changes.
[Bug tree-optimization/86114] [8/9 Regression] ICE in gimple_fold_builtin_strlen with an invalid call to strnlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86114 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00718.html
[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86064 --- Comment #10 from Alexandre Oliva --- Created attachment 44266 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44266=edit candidate patch Here's the patch I'm testing
[Bug c++/86126] New: Note when linking libraries built with different -std options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86126
Bug ID: 86126
Summary: Note when linking libraries built with different -std
options
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gburca-gnu at ebixio dot com
Target Milestone: ---
Created attachment 44265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44265=edit
Bug demo
Linking together libraries that have been built with LTO and different -std
options causes g++ to issue notes of the form: type 'A' should match type 'A'.
Specifically, with code below, the output is:
/gcc/8.1.0-1/include/c++/8.1.0/sstream:80:57: note: type ‘struct
__string_type’ should match type ‘struct __string_type’
typedef basic_string __string_type;
^
/gcc/8.1.0-1/include/c++/8.1.0/sstream:540:57: note: type ‘struct
__stringbuf_type’ should match type ‘struct __stringbuf_type’
typedef basic_stringbuf<_CharT, _Traits, _Alloc> __stringbuf_type;
^
I've tested with gcc 7.2.0 and it also issues a note about 'struct
__string_type'
Based on what I see at https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
and
https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects/49119902#49119902
it should be possible to link together objects built with the same compiler but
different -std options.
The libraries are built with:
g++ -fPIC -c liba.cpp -std=gnu++14 -o a.o ${CFLAGS}
g++ -fPIC -c libb.cpp -std=gnu++17 -o b.o ${CFLAGS}
ar cru liba.a a.o
ar cru libb.a b.o
They are linked together with:
g++ main.cpp -std=gnu++17 -L. -la -lb -o main ${CFLAGS}
-Wl,-rpath,${CXX_PATH}/lib64
And:
CFLAGS := -flto -ffat-lto-objects
[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86060 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|6.5 |7.4 --- Comment #7 from Jason Merrill --- Fixed for 7.4/8.2.
[Bug c++/85815] [7/8/9 Regression] incorrect "invalid use of incomplete type" in a lambda on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85815 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for 7.4/8.2.
[Bug c++/86060] [6/7/8/9 Regression] g++ ICE at on with "c++03" in tsubst_copy, at cp/pt.c:15459
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86060 --- Comment #6 from Jason Merrill --- Author: jason Date: Tue Jun 12 19:53:02 2018 New Revision: 261523 URL: https://gcc.gnu.org/viewcvs?rev=261523=gcc=rev Log: PR c++/86060 - ICE on range for with -std=c++98. * parser.c (cp_parser_init_statement): Don't clobber *decl after pedwarn. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/range-for35.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/range-for9.C
[Bug c++/85815] [7/8/9 Regression] incorrect "invalid use of incomplete type" in a lambda on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85815 --- Comment #5 from Jason Merrill --- Author: jason Date: Tue Jun 12 19:53:10 2018 New Revision: 261524 URL: https://gcc.gnu.org/viewcvs?rev=261524=gcc=rev Log: PR c++/85815 - reference to member of enclosing template. * parser.c (cp_parser_postfix_dot_deref_expression): Check currently_open_class. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-dependent1.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c
[Bug c++/85807] [8/9 Regression] ICEs related to noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85807 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 8.2.
[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86064 --- Comment #9 from Alexandre Oliva --- In (i), that loclist format is used because of -gsplit-dwarf, I meant to say. So we have 3 possible work-arounds immediately available: not using -gsplit-dwarf, not disabling VTA, and disabling locviews.
[Bug c/86125] missing -Wbuiltin-declaration-mismatch on a mismatched return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86125 Martin Sebor changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83656, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86114 --- Comment #1 from Martin Sebor --- See also pr83656 and pr86114.
[Bug c/86125] New: missing -Wbuiltin-declaration-mismatch on a mismatched return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86125
Bug ID: 86125
Summary: missing -Wbuiltin-declaration-mismatch on a mismatched
return type
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC correctly diagnoses the strdup() declaration that differs from the
corresponding built-in in the type of its argument but fails to issue the same
warning for the declaration of strlen() that differs from the built-in in the
return type.
$ cat c.c && gcc -S -Wall c.c
char* strdup (int);// warning (good)
char* strlen (const char*);// missing warning
char* f (void)
{
return strlen ("123");
}
c.c:1:7: warning: conflicting types for built-in function ‘strdup’
[-Wbuiltin-declaration-mismatch]
char* strdup (int);// warning (good)
^~
[Bug debug/86064] [8/9 Regression] compiling Linux kernel: Error: can't resolve `.text.unlikely' {.text.unlikely section} - `.LVL43x' {.text section}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86064 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #8 from Alexandre Oliva --- Mine. Weird... the problem is caused by the following factors: (i) the (indexed base,offset) loclist used for variable d crosses the hot/cold boundary (we should never have a single range crossing that boundary); (ii) we use a loclist because VTA is disabled (why? d is addressable, it's not a candidate for VTA) and LVU is enabled (hmm, I guess this may be forcing a LLST so that the range can get a view number); with VTA, or without LVU, we use a single location expression that covers the entire function, as intended.
[Bug c++/85764] [8/9 Regression] bogus ‘this’ was not captured for this lambda function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85764 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed for 8.2.
[Bug c++/85765] [8/9 Regression] Missing SFINAE in default template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85765 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jason Merrill --- Fixed for 8.2.
[Bug c++/59002] [meta-bug] Access checking in templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59002 Bug 59002 depends on bug 61806, which changed state. Bug 61806 Summary: [C++11] Expression sfinae w/o access gives hard error in partial template specializations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61806 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.2 --- Comment #8 from Jason Merrill --- Fixed for 8.2.
[Bug target/86048] [8/9 Regression] .seh_savexmm offset is negative error when compiling libpng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048 --- Comment #1 from Daniel Starke --- The error does not occur if I pass -fno-reorder-blocks-and-partition.
[Bug other/78068] warning: implicit declaration of function ‘time’; did you mean ‘nice’? [-Wimplicit-function-declaration]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78068 Bug 78068 depends on bug 69968, which changed state. Bug 69968 Summary: RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Implemented on trunk (for gcc 9) as r261521.
[Bug fortran/44491] Diagnostic just shows "" instead of a locus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.4 --- Comment #13 from kargl at gcc dot gnu.org --- Fixed on trunk, 7-branch, and 8-branch. Closing.
[Bug c/86124] New: [9 Regression] ICE in create_variable_info_for, at tree-ssa-structalias.c:6123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86124
Bug ID: 86124
Summary: [9 Regression] ICE in create_variable_info_for, at
tree-ssa-structalias.c:6123
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Introduced between 20180527 and 20180603, at -O[gs123] :
$ cat z1.c
extern void a (void);
void b (void)
{
void *c;
c = a;
*(char *)c = 1;
}
$ gcc-9-20180527 -c z1.c -O2 -fopenacc
$ gcc-9-20180610 -c z1.c -O2
$
$ gcc-9-20180610 -c z1.c -O2 -fopenacc
during IPA pass: pta
z1.c:7:1: internal compiler error: Segmentation fault
}
^
0xa9cbbf crash_signal
../../gcc/toplev.c:324
0xc22f29 create_variable_info_for
../../gcc/tree-ssa-structalias.c:6123
0xc22f29 get_vi_for_tree
../../gcc/tree-ssa-structalias.c:2890
0xc232c7 get_constraint_for_ssa_var
../../gcc/tree-ssa-structalias.c:2971
0xc236fe get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3559
0xc23d92 get_constraint_for_address_of
../../gcc/tree-ssa-structalias.c:3382
0xc2389b get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3450
0xc24182 get_constraint_for_ptr_offset
../../gcc/tree-ssa-structalias.c:3106
0xc238c1 get_constraint_for_1
../../gcc/tree-ssa-structalias.c:3465
0xc24f3b find_func_aliases
../../gcc/tree-ssa-structalias.c:4896
0xc2d5a1 ipa_pta_execute
../../gcc/tree-ssa-structalias.c:8018
[Bug other/69968] RFC: Use Damerau-Levenshtein within spellcheck.c, rather than Levenshtein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968 --- Comment #5 from David Malcolm --- Author: dmalcolm Date: Tue Jun 12 18:28:37 2018 New Revision: 261521 URL: https://gcc.gnu.org/viewcvs?rev=261521=gcc=rev Log: spellcheck: support transpositions aka Damerau-Levenshtein (PR other/69968) gcc/fortran/ChangeLog: PR other/69968 * misc.c (gfc_closest_fuzzy_match): Update for renaming of levenshtein_distance to get_edit_distance. gcc/ChangeLog: PR other/69968 * spellcheck-tree.c (levenshtein_distance): Rename to... (get_edit_distance): ...this, and update for underlying renaming. * spellcheck-tree.h (levenshtein_distance): Rename to... (get_edit_distance): ...this. * spellcheck.c (levenshtein_distance): Rename to... (get_edit_distance): ...this. Convert from Levenshtein distance to Damerau-Levenshtein distance by supporting transpositions of adjacent characters. Rename "v1" to "v_next" and "v0" to "v_one_ago". (selftest::levenshtein_distance_unit_test_oneway): Rename to... (selftest::test_edit_distance_unit_test_oneway): ...this, and update for underlying renaming. (selftest::levenshtein_distance_unit_test): Rename to... (selftest::test_get_edit_distance_unit): ...this, and update for underlying renaming. (selftest::test_find_closest_string): Add example from PR 69968 where transposition helps (selftest::test_metric_conditions): Update for renaming. (selftest::test_metric_conditions): Likewise. (selftest::spellcheck_c_tests): Likewise. * spellcheck.h (levenshtein_distance): Rename both overloads to... (get_edit_distance): ...this. (best_match::consider): Update for renaming. gcc/testsuite/ChangeLog: PR other/69968 * gcc.dg/spellcheck-transposition.c: New test. Added: trunk/gcc/testsuite/gcc.dg/spellcheck-transposition.c Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/misc.c trunk/gcc/spellcheck-tree.c trunk/gcc/spellcheck-tree.h trunk/gcc/spellcheck.c trunk/gcc/spellcheck.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/44491] Diagnostic just shows "" instead of a locus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491 --- Comment #12 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Jun 12 18:28:25 2018 New Revision: 261520 URL: https://gcc.gnu.org/viewcvs?rev=261520=gcc=rev Log: 2018-06-12 Steven G. Kargl PR fortran/44491 * expr.c (gfc_check_assign): Select non-NULL locus. 2018-06-12 Steven G. Kargl PR fortran/44491 * gfortran.dg/pr44491.f90: New testcase Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr44491.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c/86123] New: [8/9 Regression] ICE in prepare_cmp_insn, at optabs.c:3967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86123
Bug ID: 86123
Summary: [8/9 Regression] ICE in prepare_cmp_insn, at
optabs.c:3967
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Introduced between 20170924 and 20171008, at -O[gs123] :
$ cat z1.c
_Bool f1(_Complex unsigned x, _Complex unsigned y)
{
_Complex unsigned t1 = x / y;
_Bool t2 = (t1 != 0);
return t2;
}
_Bool f2(_Complex unsigned x, _Complex unsigned y)
{
_Complex unsigned t1 = x / y;
_Bool t2 = (t1 == 0);
return t2;
}
$ gcc-8-20170924 -c z1.c -O2
$
$ gcc-9-20180610 -c z1.c -O2
during RTL pass: expand
z1.c: In function 'f1':
z1.c:5:10: internal compiler error: in prepare_cmp_insn, at optabs.c:3967
return t2;
^~
0x9b3ae3 prepare_cmp_insn
../../gcc/optabs.c:3967
0x9b3b65 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
../../gcc/optabs.c:4113
0x76decb do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
../../gcc/dojump.c:1164
0x7e89a2 emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, int, int)
../../gcc/expmed.c:6149
0x805c7f do_store_flag
../../gcc/expr.c:11582
0x805c7f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9299
0x7f6ef4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9828
0x7052ce expand_expr
../../gcc/expr.h:279
0x7052ce expand_return
../../gcc/cfgexpand.c:3504
0x7052ce expand_gimple_stmt_1
../../gcc/cfgexpand.c:3607
0x7052ce expand_gimple_stmt
../../gcc/cfgexpand.c:3734
0x706243 expand_gimple_basic_block
../../gcc/cfgexpand.c:5762
0x70b5e6 execute
../../gcc/cfgexpand.c:6365
[Bug c/86122] New: [8/9 Regression] ICE in useless_type_conversion_p, at gimple-expr.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86122
Bug ID: 86122
Summary: [8/9 Regression] ICE in useless_type_conversion_p, at
gimple-expr.c:87
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20170618 and 20170716, at -O[gs123] :
$ cat z1.c
_Complex int f (_Complex int x)
{
x += __INT_MAX__;
x += 1;
return x;
}
$ cat z2.c
_Complex int f (_Complex int x)
{
x += 1;
x += __INT_MAX__;
return x;
}
$ gcc-7 -c z1.c -O2
$
$ gcc-9-20180610 -c z1.c -O2
during GIMPLE pass: ccp
z1.c: In function 'f':
z1.c:6:1: internal compiler error: Segmentation fault
}
^
0xa9cbbf crash_signal
../../gcc/toplev.c:324
0x8538d4 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc/gimple-expr.c:87
0xda7f98 gimple_simplify_VIEW_CONVERT_EXPR
<...>/gcc/gimple-match.c:15232
0xd9d1b0 gimple_simplify
<...>/gcc/gimple-match.c:29642
0xd9f6de gimple_resimplify1(gimple**, gimple_match_op*, tree_node*
(*)(tree_node*))
../../gcc/gimple-match-head.c:101
0x5a6bd8 gimple_simplify_154
<...>/gcc/gimple-match.c:6971
0xe18869 gimple_simplify_PLUS_EXPR
<...>/gcc/gimple-match.c:31369
0xd90c3f gimple_simplify
<...>/gcc/gimple-match.c:8
0xd92dd8 gimple_resimplify2(gimple**, gimple_match_op*, tree_node*
(*)(tree_node*))
../../gcc/gimple-match-head.c:155
0xe50041 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc/gimple-match-head.c:628
0x85a7e2 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
../../gcc/gimple-fold.c:6097
0xb6eac5 ccp_fold
../../gcc/tree-ssa-ccp.c:1258
0xb6eac5 evaluate_stmt
../../gcc/tree-ssa-ccp.c:1785
0xb6faf5 visit_assignment
../../gcc/tree-ssa-ccp.c:2352
0xbe56e3 ssa_propagation_engine::simulate_stmt(gimple*)
../../gcc/tree-ssa-propagate.c:237
0xbe5a0a ssa_propagation_engine::simulate_block(basic_block_def*)
../../gcc/tree-ssa-propagate.c:371
0xbe66a9 ssa_propagation_engine::ssa_propagate()
../../gcc/tree-ssa-propagate.c:800
0xb66df7 do_ssa_ccp
../../gcc/tree-ssa-ccp.c:2471
0xb66df7 execute
../../gcc/tree-ssa-ccp.c:2515
[Bug fortran/67883] ICE on empty array constructor of character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883 --- Comment #7 from Steve Kargl --- On Tue, Jun 12, 2018 at 06:21:06PM +, gs...@t-online.de wrote: > > --- Comment #6 from G. Steinmetz --- > (In reply to kargl from comment #4 and #5) > > trunk can now compile this code. > Confirming that ICE is gone for this group of sources. > > > ... as I think gfortran might be correct. > Agreed, it's reasonable and necessary to reject character(*) > and character(:) as type-spec in an array constructor. > > PR could be closed, thanks. > Thanks for confirmation. I'll likely convert the codes to use dejagnu declarations and commit them to the testsuite.
[Bug fortran/67883] ICE on empty array constructor of character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67883 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #6 from G. Steinmetz --- (In reply to kargl from comment #4 and #5) > trunk can now compile this code. Confirming that ICE is gone for this group of sources. > ... as I think gfortran might be correct. Agreed, it's reasonable and necessary to reject character(*) and character(:) as type-spec in an array constructor. PR could be closed, thanks.
[Bug fortran/44491] Diagnostic just shows "" instead of a locus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491 --- Comment #11 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Jun 12 18:19:03 2018 New Revision: 261519 URL: https://gcc.gnu.org/viewcvs?rev=261519=gcc=rev Log: 2018-06-12 Steven G. Kargl PR fortran/44491 * gfortran.dg/pr44491.f90: Add dg-options omitted in previous commit. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr44491.f90
[Bug tree-optimization/85259] [8/9 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259 --- Comment #6 from Martin Sebor --- Author: msebor Date: Tue Jun 12 18:05:13 2018 New Revision: 261518 URL: https://gcc.gnu.org/viewcvs?rev=261518=gcc=rev Log: PR tree-optimization/85259 - Missing -Wstringop-overflow= since r256683 gcc/ChangeLog: PR tree-optimization/85259 * builtins.c (compute_objsize): Handle constant offsets. * gimple-ssa-warn-restrict.c (maybe_diag_offset_bounds): Return true iff a warning has been issued. * gimple.h (gimple_nonartificial_location): New function. * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Call gimple_nonartificial_location and handle -Wno-system-headers. (handle_builtin_stxncpy): Same. gcc/testsuite/ChangeLog: PR tree-optimization/85259 * gcc.dg/Wstringop-overflow-5.c: New test. * gcc.dg/Wstringop-overflow-6.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-5.c trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/gimple-ssa-warn-restrict.c trunk/gcc/gimple.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug fortran/44491] Diagnostic just shows "" instead of a locus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491 --- Comment #10 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Jun 12 18:05:05 2018 New Revision: 261517 URL: https://gcc.gnu.org/viewcvs?rev=261517=gcc=rev Log: 2018-06-12 Steven G. Kargl PR fortran/44491 * expr.c (gfc_check_assign): Select non-NULL locus. 2018-06-12 Steven G. Kargl PR fortran/44491 * gfortran.dg/pr44491.f90: New testcase Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr44491.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/86121] [9 Regression] missing -Wstringop-overflow on strcpy followed by strcat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85259 --- Comment #2 from Martin Sebor --- The regression was uncovered by a test for the fix for bug 85259.
[Bug middle-end/86121] [9 Regression] missing -Wstringop-overflow on strcpy followed by strcat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Martin Sebor ---
The problem is due to the MEM_REF that the strcat() call is transformed into.
Prior to GCC 9 the strcat() call would be transformed to memcpy() like so:
MEM[(char * {ref-all})] = MEM[(char * {ref-all})"12"];
__builtin_memcpy ([(void *) + 2B], "3", 2); [tail call]
Bisection points to the following commit as the cause of the change:
r261061 | rguenth | 2018-06-01 06:49:54 -0400 (Fri, 01 Jun 2018) | 8 lines
2018-06-01 Richard Biener
PR middle-end/86017
* gimple-fold.c (var_decl_component_p): Also allow offsetted
vars wrapped in MEM_REFs.
* gcc.dg/tree-ssa/pr86017.c: New testcase.
[Bug fortran/44491] Diagnostic just shows "" instead of a locus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44491 --- Comment #9 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Jun 12 17:55:24 2018 New Revision: 261516 URL: https://gcc.gnu.org/viewcvs?rev=261516=gcc=rev Log: 2018-06-12 Steven G. Kargl PR fortran/44491 * expr.c (gfc_check_assign): Select non-NULL locus. 2018-06-12 Steven G. Kargl PR fortran/44491 * gfortran.dg/pr44491.f90: New testcase Added: trunk/gcc/testsuite/gfortran.dg/pr44491.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/86121] New: [9 Regression] missing -Wstringop-overflow on strcpy followed by strcat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121
Bug ID: 86121
Summary: [9 Regression] missing -Wstringop-overflow on strcpy
followed by strcat
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 7 and 8 correctly diagnose the buffer overflow in the test case below by
issuing -Wstringop-overflow. However, in the current trunk of GCC 9 the
warning fails to detect the same bug (GCC 9 issues -Warray-bounds instead).
$ cat c.c && gcc -O2 -S -Wstringop-overflow -fdump-tree-optimized=/dev/stdout
c.c
#define bos1(p) __builtin_object_size (p, 1)
#define strcat(d, s) __builtin___strcat_chk (d, s, bos1 (d))
#define strcpy(d, s) __builtin___strcpy_chk (d, s, bos1 (d))
char a[2];
void test_strcpy_strcat_2 (void)
{
strcpy (a, "12");
strcat (a, "3");
}
;; Function test_strcpy_strcat_2 (test_strcpy_strcat_2, funcdef_no=0,
decl_uid=1897, cgraph_uid=1, symbol_order=1)
test_strcpy_strcat_2 ()
{
[local count: 1073741825]:
MEM[(char * {ref-all})] = MEM[(char * {ref-all})"12"];
MEM[(char * {ref-all}) + 2B] = MEM[(char * {ref-all})"3"];
return;
}
[Bug c/85931] -Wsizeof-pointer-memaccess for strncpy with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85931 Martin Sebor changed: What|Removed |Added Known to work||9.0 Known to fail|9.0 | --- Comment #5 from Martin Sebor --- Patch committed into trunk in r261515.
[Bug c/85931] -Wsizeof-pointer-memaccess for strncpy with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85931 --- Comment #4 from Martin Sebor --- Author: msebor Date: Tue Jun 12 17:14:31 2018 New Revision: 261515 URL: https://gcc.gnu.org/viewcvs?rev=261515=gcc=rev Log: PR c/85931 - -Wsizeof-pointer-memaccess for strncpy with size of source gcc/c-family/ChangeLog: PR c/85931 * c-warn.c (sizeof_pointer_memaccess_warning): Avoid warning when sizeof source and destination yields the same value. gcc/ChangeLog: PR c/85931 * fold-const.c (operand_equal_p): Handle SAVE_EXPR. gcc/testsuite/ChangeLog: PR c/85931 * gcc.dg/Wstringop-truncation-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-truncation-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-warn.c trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/86120] New: SIGSEGV without backtrace when using submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86120 Bug ID: 86120 Summary: SIGSEGV without backtrace when using submodules Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: simon.kluepfel at gmail dot com Target Milestone: --- Created attachment 44264 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44264=edit source code The attached code does not run as expected when compiling with -O3 using gfortran 6 and 7. For gfortran-6 a write statement to a file inside the routine "fixes" the segfault. Works for gfortran-8. Moving the submodule into the module, or not using the str_set routine avoids the segfault as well. compiled with: gfortran-XXX -O3 -std=f2008 -g -fbacktrace -fcheck=all string.f03 dt.f03 dt_sub.f03 main.f03 for XXX= gcc version 6.4.0 20180424 (Debian 6.4.0-17) gcc version 7.3.0 (Debian 7.3.0-21) gcc version 8.1.0 (Debian 8.1.0-5) output expected / v. 8: $ ./a.out 1 2 1 2 1 2 $ v. 7: $ ./a.out 1 2 1 2 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f8c0df6e0fd in ??? #1 0x7f8c0df6d343 in ??? #2 0x7f8c0d3e2eff in ??? #3 0x0 in ??? Segmentation fault v. 6: $ ./a.out 1 2 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f1cbf72dced in ??? #1 0x7f1cbf72cf4d in ??? #2 0x7f1cbeba1eff in ??? #3 0x0 in ??? Segmentation fault
[Bug target/85990] Wrong TARGET_THREAD_SPLIT_STACK_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85990
--- Comment #2 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jun 12 15:35:22 2018
New Revision: 261501
URL: https://gcc.gnu.org/viewcvs?rev=261501=gcc=rev
Log:
Linux/x86: Update TARGET_THREAD_SPLIT_STACK_OFFSET comments
Glibc 2.18 was changed by
commit ecbf434213c0333d81706074e4d107ac45011635
Author: Andreas Jaeger
Date: Wed May 15 20:20:54 2013 +0200
Reserve new TLS field for x86 and x86_64
[BZ #10686]
* sysdeps/x86_64/tls.h (struct tcbhead_t): Add __private_ss
field.
* sysdeps/i386/tls.h (struct tcbhead_t): Likewise.
to reduce the size of __private_tm to make room for __private_ss, which
was supposed to be used for TARGET_THREAD_SPLIT_STACK_OFFSET:
typedef struct
{
void *tcb;/* Pointer to the TCB. Not necessarily the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
uintptr_t sysinfo;
uintptr_t stack_guard;
uintptr_t pointer_guard;
int gscope_flag;
int __glibc_reserved1;
/* Reservation of some values for the TM ABI. */
void *__private_tm[4];
/* GCC split stack support. */
void *__private_ss;
} tcbhead_t;
But the offset of __private_ss for i386 was mistakenly set to 0x30,
instead of 0x34 and libgcc/config/i386/morestack.S has:
cmpl%gs:0x30,%eax # See if we have enough space.
movl%eax,%gs:0x30 # Save the new stack boundary.
movl%eax,%gs:0x30 # Save the new stack boundary.
movl%ecx,%gs:0x30 # Save new stack boundary.
movl%eax,%gs:0x30
movl%gs:0x30,%eax
movl%eax,%gs:0x30
Since update TARGET_THREAD_SPLIT_STACK_OFFSET changes split stack ABI,
glibc 2.28 has been changed by
commit 0221ce2a90be2d40fc90f0b5dcec77a1ec013f53
Author: H.J. Lu
Date: Tue Jun 12 06:23:28 2018 -0700
i386: Change offset of __private_ss to 0x30 [BZ #23250]
to match GCC:
typedef struct
{
void *tcb;/* Pointer to the TCB. Not necessarily the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
uintptr_t sysinfo;
uintptr_t stack_guard;
uintptr_t pointer_guard;
int gscope_flag;
int __glibc_reserved1;
/* Reservation of some values for the TM ABI. */
void *__private_tm[3];
/* GCC split stack support. */
void *__private_ss;
void *__glibc_reserved2;
} tcbhead_t;
PR target/85990
* config/i386/gnu-user.h (TARGET_THREAD_SPLIT_STACK_OFFSET):
Update comments.
* config/i386/gnu-user64.h (TARGET_THREAD_SPLIT_STACK_OFFSET):
Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/gnu-user.h
trunk/gcc/config/i386/gnu-user64.h
[Bug target/85990] Wrong TARGET_THREAD_SPLIT_STACK_OFFSET
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85990 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #1 from H.J. Lu --- Fixed for GCC 9.
[Bug c++/58646] ICE on a multidimensional VLA with an empty initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646
Andrey Vihrov changed:
What|Removed |Added
CC||andrey.vihrov at gmail dot com
--- Comment #8 from Andrey Vihrov ---
Still happening with g++ (GCC) 8.1.1 20180531.
The first sample from description gives
x.cpp: In function 'void foo(int)':
x.cpp:3:7: internal compiler error: in make_decl_rtl, at varasm.c:1322
int a[2][n] = {};
^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/86118] Gcc segfault for big c++ data compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86118 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-06-12 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can you please provide steps to merge it back and extract?
[Bug c++/33979] support for char16_t, char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #20) > The libstdc++ support required by the standard has been complete since GCC > 5.1, but I don't know if Paolo had more in mind (we don't implement all > locale facets for char16_t and char32_t, which means e.g. > std::basic_stringstream doesn't work, but the standard doesn't > require it to work). We have PR 78486 requesting that (but I have no plans to work on it myself). Let's close this one, everything required by the standard works.
[Bug fortran/86119] New: Intrinsic len has wrong type if used within select type for a class(*) string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86119 Bug ID: 86119 Summary: Intrinsic len has wrong type if used within select type for a class(*) string Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The following program, compiled with -Wall gives the warning l2 = len(s) 1 Warning: Possible change of value in conversion from INTEGER(8) to INTEGER(4) at (1) [-Wconversion] (No warning for len_trim!) This is directly related to the use of select type in conjunction with class(*). If s is declared as character(len=:) and the select type block is removed, then there is no warning. program proglen implicit none class(*), allocatable :: s integer :: l1, l2 allocate(s, source = '123 ') select type(s) type is (character(len=*)) l1 = len_trim(s) l2 = len(s) end select end program proglen
[Bug libitm/85988] Incorrect offsets of __private_tm and pointer_guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85988
--- Comment #2 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Jun 12 11:08:52 2018
New Revision: 261491
URL: https://gcc.gnu.org/viewcvs?rev=261491=gcc=rev
Log:
libitm/x86: Correct offsets of __private_tm and pointer_guard
In glibc, sysdeps/i386/nptl/tls.h has
typedef struct
{
void *tcb;/* Pointer to the TCB. Not necessarily the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
uintptr_t sysinfo;
uintptr_t stack_guard;
uintptr_t pointer_guard;
int gscope_flag;
int __glibc_reserved1;
/* Reservation of some values for the TM ABI. */
void *__private_tm[4];
/* GCC split stack support. */
void *__private_ss;
} tcbhead_t;
and sysdeps/x86_64/nptl/tls.h has
typedef struct
{
void *tcb;/* Pointer to the TCB. Not necessarily the
thread descriptor used by libpthread. */
dtv_t *dtv;
void *self; /* Pointer to the thread descriptor. */
int multiple_threads;
int gscope_flag;
uintptr_t sysinfo;
uintptr_t stack_guard;
uintptr_t pointer_guard;
unsigned long int vgetcpu_cache[2];
int __glibc_reserved1;
int __glibc_unused1;
/* Reservation of some values for the TM ABI. */
void *__private_tm[4];
/* GCC split stack support. */
void *__private_ss;
long int __glibc_reserved2;
/* Must be kept even if it is no longer used by glibc since programs,
like AddressSanitizer, depend on the size of tcbhead_t. */
__128bits __glibc_unused2[8][4] __attribute__ ((aligned (32)));
void *__padding[8];
} tcbhead_t;
The offsets of __private_tm are
i386: 36 bytes
x32:48 bytes
x86_64: 80 bytes
and the offsets of pointer_guard are:
i386: 24 bytes
x32:28 bytes
x86_64: 48 bytes
But config/linux/x86/tls.h had
#ifdef __x86_64__
#ifdef __LP64__
# define SEG_READ(OFS) "movq\t%%fs:(" #OFS "*8),%0"
# define SEG_WRITE(OFS) "movq\t%0,%%fs:(" #OFS "*8)"
# define SEG_DECODE_READ(OFS) SEG_READ(OFS) "\n\t" \
"rorq\t$17,%0\n\t" \
"xorq\t%%fs:48,%0"
# define SEG_ENCODE_WRITE(OFS) "xorq\t%%fs:48,%0\n\t" \
"rolq\t$17,%0\n\t" \
SEG_WRITE(OFS)
#else
// For X32.
# define SEG_READ(OFS) "movl\t%%fs:(" #OFS "*4),%0"
# define SEG_WRITE(OFS) "movl\t%0,%%fs:(" #OFS "*4)"
# define SEG_DECODE_READ(OFS) SEG_READ(OFS) "\n\t" \
"rorl\t$9,%0\n\t" \
"xorl\t%%fs:24,%0"
# define SEG_ENCODE_WRITE(OFS) "xorl\t%%fs:24,%0\n\t" \
"roll\t$9,%0\n\t" \
SEG_WRITE(OFS)
#endif
#else
# define SEG_READ(OFS) "movl\t%%gs:(" #OFS "*4),%0"
# define SEG_WRITE(OFS) "movl\t%0,%%gs:(" #OFS "*4)"
# define SEG_DECODE_READ(OFS) SEG_READ(OFS) "\n\t" \
"rorl\t$9,%0\n\t" \
"xorl\t%%gs:24,%0"
# define SEG_ENCODE_WRITE(OFS) "xorl\t%%gs:24,%0\n\t" \
"roll\t$9,%0\n\t" \
SEG_WRITE(OFS)
#endif
static inline struct gtm_thread *gtm_thr(void)
{
struct gtm_thread *r;
asm volatile (SEG_READ(10) : "=r"(r));
return r;
}
static inline void set_gtm_thr(struct gtm_thread *x)
{
asm volatile (SEG_WRITE(10) : : "r"(x));
}
static inline struct abi_dispatch *abi_disp(void)
{
struct abi_dispatch *r;
asm volatile (SEG_DECODE_READ(11) : "=r"(r));
return r;
}
static inline void set_abi_disp(struct abi_dispatch *x)
{
void *scratch;
asm volatile (SEG_ENCODE_WRITE(11) : "=r"(scratch) : "0"(x));
}
SEG_READ, SEG_WRITE, SEG_DECODE_READ and SEG_ENCODE_WRITE were correct
only for x86-64.
Update SEG_READ and SEG_WRITE to use the offset of __private_tm as base
and correct the offset of pointer_guard for x32. This patch doesn't
change ABI of libitm.
PR libitm/85988
* config/linux/x86/tls.h (SEG_READ): Use the offset of
__private_tm as base.
(SEG_WRITE): Likewise.
(SEG_ENCODE_WRITE): Correct the offset of pointer_guard for x32.
(gtm_thr): Replace SEG_READ(10) with SEG_READ(0).
(set_gtm_thr): Replace SEG_WRITE(10) with SEG_WRITE(0).
(abi_disp): Replace SEG_DECODE_READ(11) with SEG_DECODE_READ(1).
(set_abi_disp): Replace SEG_ENCODE_WRITE(11) with
SEG_ENCODE_WRITE(1).
Modified:
trunk/libitm/ChangeLog
trunk/libitm/config/linux/x86/tls.h
[Bug c++/86118] Gcc segfault for big c++ data compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86118 --- Comment #2 from Александр Кроль --- Created attachment 44263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44263=edit second volume of preprocessed file Due to size limit following command sequence was done: 1. bzip2 -k ./idfs.ii 2. tar -c -M --tape-length=1000 --file=idfs1.tar.gz ./idfs.ii.bz2 ^GPrepare volume #2 for ‘idfs1.tar.gz’ and hit return: n idfs2.tar.gz
[Bug c++/86118] Gcc segfault for big c++ data compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86118 --- Comment #1 from Александр Кроль --- Created attachment 44262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44262=edit preprocessed file that triggers the bug Due to size limit following command sequence was done: 1. bzip2 -k ./idfs.ii 2. tar -c -M --tape-length=1000 --file=idfs1.tar.gz ./idfs.ii.bz2 ^GPrepare volume #2 for ‘idfs1.tar.gz’ and hit return: n idfs2.tar.gz
[Bug c++/86118] New: Gcc segfault for big c++ data compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86118 Bug ID: 86118 Summary: Gcc segfault for big c++ data compilation Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: oleksandr.krol at gmail dot com Target Milestone: --- gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) --- compilation command: /usr/local/bin/mpic++ --save-temps -DQT_CORE_LIB -DQT_NO_DEBUG -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -isystem /usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -Wall -Wextra -std=c++11 -O2 -fPIC -fPIC -o ./idfs.cc.o -c ./idfs.cc --- compiler output: g++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug fortran/86117] New: bogus warning maybe-uninitialized with class(*) and source argument in allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86117 Bug ID: 86117 Summary: bogus warning maybe-uninitialized with class(*) and source argument in allocate Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Compiling the following module with gfortran -Og -Wall -fcheck=all -c mod.f90 gives Warning: ‘’ may be used uninitialized in this function [-Wmaybe-uninitialized] When leaving out any one of the three options -Og, -Wall or -fcheck=all the warning disappears. When replacing class(*) with integer the warning also disappears. When using scalars for a and b (omitting the dimension(:) part and the do loop) the warning also disappears. module mod private public sub type, public :: generic class(*), allocatable :: item ! with integer instead of class(*), there is no warning ! integer, allocatable :: item end type generic contains subroutine sub(a, b) type(generic), dimension(:), intent(in) :: a type(generic), dimension(:), intent(out) :: b integer :: i do i = 1, 10 allocate(b(i)%item, source=a(i)%item) end do end subroutine sub end module mod
[Bug rtl-optimization/86107] [9 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:42301 with -O -funroll-loops -mavx5124fmaps -mmitigate-rop --param=hot-bb-frequency-fraction=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107 Uroš Bizjak changed: What|Removed |Added CC||richard.sandiford at linaro dot or ||g Component|target |rtl-optimization Target Milestone|--- |9.0 --- Comment #3 from Uroš Bizjak --- Looks like a rtl-optimization problem with handling of preferred-for-speed attribute. CC author.
[Bug debug/84342] Location views breaks cross builds of arm including gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84342 --- Comment #13 from Ramana Radhakrishnan --- (In reply to Jeffrey A. Law from comment #12) > I'm not familiar enough with the ccfsm bits to know if there's something we > ought to be doing generically to improve CC handling further. I think > downgrading to P2 certainly makes sense though. > > However, I wouldn't be surprised if we find other instances of this kind of > problem confusing the hell out of the location view support. So I wouldn't > dig at the ccfsm stuff just to allow the compiler to handle view support > slightly more efficiently -- removal of ccfsm should stand on its own. Agreed about the removal of ccfsm support standing on it's own. I do wonder if doing that will have the side benefit of not having these kinds of issues. IIRC arc (from the days I worked on it) has ccfsm similar to arm, so maybe the same problem will bite us on other ports as well.
[Bug target/86107] [9 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:42301 with -O -funroll-loops -mavx5124fmaps -mmitigate-rop --param=hot-bb-frequency-fraction=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107
--- Comment #2 from Uroš Bizjak ---
For some reason, this part of x86_mitigate_rop:
int n_uses;
reg_class superclass = regrename_find_superclass (head, _uses,
);
old_reg = head->regno;
best_reg = find_rename_reg (head, superclass, ,
old_reg, false);
bool ok = regrename_do_replace (head, best_reg);
gcc_assert (ok);
if (dump_file)
fprintf (dump_file, "Chain %d renamed as %s in %s\n", head->id,
reg_names[best_reg], reg_class_names[superclass]);
does not validate in regrename_do_replace.
The compiler wants to rename:
(insn 1264 1263 1265 5 (set (reg:DI 22 xmm1 [594])
(reg:DI 3 bx [594])) "pr86107.c":15 85 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 3 bx [594])
(nil)))
to:
(set (reg:DI 22 xmm1 [594])
(reg:DI 1 dx [594]))
and fails validation of new instruction.
The alternative 20 in *movdi_internal (*v->?r) is marked with
preferred_for_speed attribute:
(set (attr "preferred_for_speed")
(cond [(eq_attr "alternative" "10,17,19")
(symbol_ref "TARGET_INTER_UNIT_MOVES_FROM_VEC")
(eq_attr "alternative" "11,18,20")
(symbol_ref "TARGET_INTER_UNIT_MOVES_TO_VEC")
]
(symbol_ref "true")))
but should not fail verification even for !TARGET_INTER_UNIT_MOVES_TO_VEC
targets. As a matter of fact, the compilation works with -mtune=intel.
It looks to me that preferred_for_speed attribute handling is at fault here.
[Bug fortran/86116] New: Ambiguous generic interface not recognised
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86116 Bug ID: 86116 Summary: Ambiguous generic interface not recognised Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The following module should not compile. Calling sub(z) with z declared as "type(t), allocatable :: z" shows the ambiguity. Replacing "type(t) :: x" by "integer :: x" in the definition of s1 gives the expected error "Ambiguous interfaces in generic interface 'sub' for ‘s1’ at (1) and ‘s2’ at (2)". module mod private public sub type, public :: t end type t interface sub module procedure s1 module procedure s2 end interface sub contains subroutine s1(x) type(t) :: x ! with integer, gfortran recognises the ambiguity ! integer :: x end subroutine s1 subroutine s2(x) class(*), allocatable :: x end subroutine s2 end module mod
[Bug c++/33979] support for char16_t, char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33979 Paolo Carlini changed: What|Removed |Added Status|WAITING |NEW --- Comment #22 from Paolo Carlini --- I don't have much to add, I'm sure Jonathan will make the best decisions about this issue.
[Bug gcov-profile/86109] [8/9 Regression] gcov reports lines in lambdas as not executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86109 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-06-12 Known to work||7.3.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Summary|[GCOV] gcov reports lines |[8/9 Regression] gcov |in lambdas as not |reports lines in lambdas as |executable |not executable Ever confirmed|0 |1 Known to fail||8.1.0, 9.0 --- Comment #1 from Martin Liška --- Confirmed, regressed with r254562.
[Bug target/86107] [9 Regression] ICE: in ix86_mitigate_rop, at config/i386/i386.c:42301 with -O -funroll-loops -mavx5124fmaps -mmitigate-rop --param=hot-bb-frequency-fraction=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86107 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-06-12 CC||marxin at gcc dot gnu.org, ||uros at gcc dot gnu.org Known to work||8.1.0 Summary|ICE: in ix86_mitigate_rop, |[9 Regression] ICE: in |at config/i386/i386.c:42301 |ix86_mitigate_rop, at |with -O -funroll-loops |config/i386/i386.c:42301 |-mavx5124fmaps |with -O -funroll-loops |-mmitigate-rop |-mavx5124fmaps |--param=hot-bb-frequency-fr |-mmitigate-rop |action=1|--param=hot-bb-frequency-fr ||action=1 Ever confirmed|0 |1 Known to fail||9.0 --- Comment #1 from Martin Liška --- Started with r259701.
[Bug fortran/86115] New: move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 Bug ID: 86115 Summary: move_alloc for class(*) containing value of type character(len=*) looses data Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- related: bug 72790 Applying move_alloc(x,y) for x and y both declared as class(*) and x currently containing a string (character(len=...)) fails. The type seems to be transfered, but the value is empty. Test case, which shows that for integer variables move_alloc works as expected, but which fails for strings: program movealloc class(*), allocatable :: x, y, s, t allocate(x, source=1234) allocate(s, source='5678') call p(x) call p(y) call p(s) call p(t) call move_alloc(x, y) call move_alloc(s, t) print *,'---' call p(x) call p(y) call p(s) call p(t) contains subroutine p(z) class(*), allocatable, intent(in) :: z if (allocated(z)) then select type(z) type is (character(len=*)) print *, 'string: ', z type is (integer) print *, 'integer: ', z class default print *, 'unknown type' end select else print *, 'not allocated' end if end subroutine p end program expected output (confirmed with ifort): integer: 1234 not allocated string: 5678 not allocated --- not allocated integer: 1234 not allocated string: 5678 gfortran output: integer: 1234 not allocated string: 5678 not allocated --- not allocated integer: 1234 not allocated string: (not that it does not report 'unknown type')
