[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #18 from Jean-Christophe Dubois --- (In reply to Mikael Pettersson from comment #17) > My though reading this is that most RICSs have problems synthesizing large > literals, so putting a jump table in .text might increase the likelihood of > its address being synthesizable with a PC + offset addressing mode. Putting > it in .rodata would almost certainly require you to indirect through the GOT > to address it. That said, if the user wants .text to be execute-only, then > the jump table ought to land in .rodata. As far as I can say with the assembly code generated today for SPARC32, the jump tables could be anywhere in memory (4GB address space) with the exact same code. I don't think it would trigger additional indirection. It might be different for other architecture.
[Bug fortran/91726] [8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 --- Comment #5 from Paul Thomas --- (In reply to anlauf from comment #4) > This appears to be fixed on trunk. Since this is marked as a regression, > shall it be backported? Hi Harald, Yes it should. Unfortunately, I am working every waking our on our experimental campaign through to Christmas Eve. I will fit in some gfortran work during the holiday. Cheers Paul
[Bug testsuite/92941] New: Test failure when no C++ compiler built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92941
Bug ID: 92941
Summary: Test failure when no C++ compiler built
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: green at redhat dot com
Target Milestone: ---
If you run the testsuite on a C-only build of the toolchain, you'll
get a FAIL for this test:
compiler driver -Q --help=warnings option(s): "-Wabsolute-value[
\t]+\[available in C, ObjC\]" present in output
It comes from here...
check_for_options c++ "-Q --help=warnings" {
-Wabsolute-value[ \t]+\[available in C, ObjC\]
} "" ""
But the testsuite should ignore c++ related tests if we haven't configured and
built g++.
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #7 from Paul Thomas --- I cannot agree that this is a regression since the bug is present in the original implementation. However, I will leave it marked as such to flag up that both branches need fixing :-) I am tied up every waking hour until Christmas Eve with "daytime" work - I'll get on to it in the holiday period. Regards Paul
[Bug tree-optimization/92930] [8/9/10 Regression] GCC incorrectly optimizes away __builtin_apply() calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92930 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Dec 14 11:18:30 2019 New Revision: 279394 URL: https://gcc.gnu.org/viewcvs?rev=279394&root=gcc&view=rev Log: PR tree-optimization/92930 * ipa-pure-const.c (special_builtin_state): Don't handle BUILT_IN_APPLY. Formatting fixes. (check_call): Formatting fixes. * gcc.dg/tree-ssa/pr92930.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr92930.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/92357] ICE in IPA pass fnsummary in openmp offload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92357 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Sat Dec 14 11:19:07 2019 New Revision: 279395 URL: https://gcc.gnu.org/viewcvs?rev=279395&root=gcc&view=rev Log: PR ipa/92357 * ipa-fnsummary.c (ipa_fn_summary_write): Use lto_symtab_encoder_iterator with lsei_start_function_in_partition and lsei_next_function_in_partition instead of walking all cgraph nodes in encoder. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-fnsummary.c
[Bug tree-optimization/92930] [8/9 Regression] GCC incorrectly optimizes away __builtin_apply() calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92930 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] GCC |[8/9 Regression] GCC |incorrectly optimizes away |incorrectly optimizes away |__builtin_apply() calls |__builtin_apply() calls --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/92932] Optimizers generate wrong code due to aggressive data optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92932
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> Dup of at least PR92294 and PR54666;
These PRs are different because no target hook is needed to see that the code
is wrong. This is different with PR92606 because a target attribute is
involved.
Hence this PR for a new target hook that can tell whether such transformation
might not be legitimate {apart from generic reasons}.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 --- Comment #19 from Jean-Christophe Dubois --- (In reply to Andrew Pinski from comment #16) > (In reply to Jean-Christophe Dubois from comment #15) > > Am I missing something? > > YES. Most likely it will not be loaded in the instruction cache as it is > larger than the cache line size. Maybe this is not a big issue but couldn't the end of the jump table be loaded in instruction cache (depending on function alignment) with the beginning of the function it will be used with (when code is compiled with -Os functions don't seem to be aligned on cache line size) Or the beginning of the jump table with the end of the previous function. This might be only few bytes of instruction cache each time and maybe it is not an issue overall. And when you mix data and code there will also be some instruction that will enter the data cache if things are not aligned on cache line size. Maybe this is not an issue performance wise either.
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #19 from Steve Kargl --- On Sat, Dec 14, 2019 at 07:47:46AM +, thenlich+gccbug at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 > > --- Comment #18 from Thomas Henlich --- > (In reply to Thomas Henlich from comment #13) > > For example: > > > > gfc_notify_std (GFC_STD_F2018, "positive width required at %L", > > &format_locus) > > > > should read > > gfc_notify_std (GFC_STD_F2018, "zero width at %L", &format_locus) > > Even so, "zero width" is not the best choice of words, "E0.d editing" or "E0 > editing" would be more appropriate; or "% in format at %L" to keep it > consisten with other uses. > Looks like a good opprtunity for someone sitting on the sidelines to get involved in building a better tool.
[Bug target/91534] some defined builtins are not usable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91534 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- Why is this a problem? Where do we promise to do have builtins like this? We certainly need to overhaul how we do the builtins, and work on that is in progress, but what you describe is not a problem?
[Bug demangler/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 --- Comment #6 from Mark Wielaard --- (In reply to Christian Biesinger from comment #5) > Using binutils from a month ago or so, this does not crash but also does not > demangle... Could you be slightly more specific? Which symbol produced by which compiler doesn't (correctly) demangle? And, if known, is it a valid mangled symbol?
[Bug fortran/92753] [9/10 Regression] ICE in gfc_trans_call, at fortran/trans-stmt.c:392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92753
--- Comment #8 from Paul Thomas ---
Created attachment 47497
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47497&action=edit
Provisional patch for the PR
The attached patch fixes the bugs in this PR. However, complex components of
derived type parameters seem to cause problems that I cannot fathom.
module m
type t
character(3) :: c
end type
type u
complex :: z
end type
type(t), parameter :: x = t('abc')
integer, parameter :: l = x%c%len ! Used to ICE
type(u), parameter :: z = u((42.0,-42.0))
end
program p
use m
call s(x%c%len) ! ditto
print *, z%z%re ! this gives a wrong result while %im causes a
segfault
contains
subroutine s(n)
if (n .ne. l) stop 1
end
end
The problems arise in the mpfr_set's in expr.c:1815-1837. Suggestions welcome!
[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Priority|P3 |P4
Status|NEW |ASSIGNED
CC||anlauf at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
Tentative patch:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 279398)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -9218,6 +9218,13 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf
break;
rank_remap = (remap && remap->u.ar.end[0]);
+ if (remap && expr2->expr_type == EXPR_NULL)
+ {
+ gfc_error ("If bounds remapping is specified at %L, "
+"the data target shall not be NULL", &expr1->where);
+ return NULL_TREE;
+ }
+
gfc_init_se (&lse, NULL);
if (remap)
lse.descriptor_only = 1;
[Bug preprocessor/92919] invalid memory access in wide_str_to_charconst when running ucn2.C testcase (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92919 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Dec 14 22:18:53 2019 New Revision: 279399 URL: https://gcc.gnu.org/viewcvs?rev=279399&root=gcc&view=rev Log: PR preprocessor/92919 * charset.c (wide_str_to_charconst): If str contains just the NUL terminator, punt quietly. Modified: trunk/libcpp/ChangeLog trunk/libcpp/charset.c
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878
--- Comment #7 from Ville Voutilainen ---
__is_constructible is incorrectly false for such an aggregate:
struct aggressive_aggregate
{
int a;
int b;
};
int main()
{
static_assert(__is_constructible(aggressive_aggregate, int, int));
}
Do you want a new bug report, or should this be handled as a follow-up on this
one?
By the way, this is exactly why I asked to add a libstdc++ test for this, for
make_shared, make_unique and allocator::construct (and construct_at). When I
started writing that test, I semi-immediately ran into make_shared still not
working, because the underlying utilities it uses check constructibility, and
get a wrong answer.
[Bug middle-end/92942] New: missing -Wstringop-overflow for allocations with a negative lower bound size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92942
Bug ID: 92942
Summary: missing -Wstringop-overflow for allocations with a
negative lower bound size
Product: gcc
Version: 10.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: ---
In LP64, only the buffer overflow in f() below is diagnosed. The one in g() is
not because n is determined to be in the anti-range ~[4, 18446744071562067967],
i.e., the size of the object is considered to be between [0, 4] and [INT_MAX,
SIZE_MAX]. (In ILP32 both calls are diagnosed).
The warning should try to determine the type of the argument to malloc() and if
it's signed, assume it's not negative.
$ cat a.c && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall a.c
#include
#include
void* f (unsigned n)
{
if (3 < n)
n = 3;
void *p = malloc (n);
strcpy (p, "12345"); // buffer overflow detected
return p;
}
void* g (int n)
{
if (3 < n)
n = 3;
void *p = malloc (n);
strcpy (p, "12345"); // buffer overflow not detected
return p;
}
In file included from /usr/include/string.h:494,
from a.c:2:
In function ‘strcpy’,
inlined from ‘f’ at a.c:10:3:
/usr/include/bits/string_fortified.h:90:10: warning: ‘__builtin_memcpy’ writing
6 bytes into a region of size between 0 and 3 [-Wstringop-overflow=]
90 | return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
| ^~
a.c: In function ‘f’:
a.c:9:13: note: at offset 0 to an object with size at most 3 allocated by
‘malloc’ here
9 | void *p = malloc (n);
| ^~
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #8 from Ville Voutilainen --- One more thing besides the __is_constructible; this aggregate doesn't seem to work in an unevaluated context. Both decltype(aggressive_aggregate(1,2)) and noexcept(aggressive_aggregate(1,2)) are rejected.
[Bug c++/92878] Parenthesized aggregate initialization doesn't work in a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92878 --- Comment #9 from Ville Voutilainen --- This seems to do the right thing for __is_constructible. I haven't looked at decltype or noexcept yet. diff --git a/gcc/cp/method.c b/gcc/cp/method.c index 97c27c51ea3..4b8daf8634f 100644 --- a/gcc/cp/method.c +++ b/gcc/cp/method.c @@ -1742,8 +1742,11 @@ constructible_expr (tree to, tree from) tree ob = build_stub_object (to); for (; from; from = TREE_CHAIN (from)) vec_safe_push (args, build_stub_object (TREE_VALUE (from))); - expr = build_special_member_call (ob, complete_ctor_identifier, &args, - ctype, LOOKUP_NORMAL, tf_none); + if (CP_AGGREGATE_TYPE_P (ctype)) + expr = build_aggr_init(ob, from, LOOKUP_NORMAL, tf_none); + else + expr = build_special_member_call (ob, complete_ctor_identifier, &args, + ctype, LOOKUP_NORMAL, tf_none); if (expr == error_mark_node) return error_mark_node; /* The current state of the standard vis-a-vis LWG 2116 is that
[Bug middle-end/92943] New: missing -Wformat-overflow with an allocated buffer with non-constant size in known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92943
Bug ID: 92943
Summary: missing -Wformat-overflow with an allocated buffer
with non-constant size in known range
Product: gcc
Version: 10.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: ---
With pr78245 resolved, GCC diagnoses the buffer overflow in function f() below.
The overflow in g() is also detected but only after the sprintf pass has
transformed the call to memcpy, and not by the pass itself. The overflow in
h() is not detected at all, (presumably) because the detection relies on the
objsize pass which is limited to constant sizes.
$ cat a.c && gcc -O2 -S -Wall a.c
void* f (void)
{
char *p = __builtin_malloc (4);
__builtin_sprintf (p, "%i", 12345); // overflow detected
return p;
}
void* g (unsigned n)
{
if (4 < n)
n = 4;
char *p = __builtin_malloc (n);
__builtin_sprintf (p, "%s", "12345");// overflow detected
return p;
}
void* h (unsigned n)
{
if (4 < n)
n = 4;
char *p = __builtin_malloc (n);
__builtin_sprintf (p, "%i", 12345); // overflow not detected
return p;
}
a.c: In function ‘f’:
a.c:4:26: warning: ‘%i’ directive writing 5 bytes into a region of size 4
[-Wformat-overflow=]
4 | __builtin_sprintf (p, "%i", 12345); // overflow detected
| ^~
a.c:4:3: note: ‘__builtin_sprintf’ output 6 bytes into a destination of size 4
4 | __builtin_sprintf (p, "%i", 12345); // overflow detected
| ^~
a.c: In function ‘g’:
a.c:13:3: warning: ‘__builtin_memcpy’ forming offset [4, 5] is out of the
bounds [0, 4] [-Warray-bounds]
13 | __builtin_sprintf (p, "%s", "12345"); // overflow detected
| ^~~~
[Bug fortran/92114] equivalence in module causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92114 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig --- In such cases (especially if the test case has been fixed by something unknown), I prefer to add the test case to the testsuite. Just to make sure nothing regresses..
[Bug c/61579] -Wwrite-strings does not behave as a warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579 --- Comment #6 from Rich Felker --- Ping.
[Bug c++/86464] Delegating constructor causes error if parameter has same name as class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86464
--- Comment #2 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #1)
> EDG accepts it but Clang also rejects it:
>
> del.cc:5:11: error: member initializer 'foo' does not name a non-static data
> member or base class
> : foo{ foo }
> ^~
>
> But I think the code is valid according to [class.base.init] p2.
Even if it's valid and GCC will start accepting it, I think it should still get
a warning from -Wshadow or something
