[Bug tree-optimization/86710] New: 3 missing logarithm optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86710 Bug ID: 86710 Summary: 3 missing logarithm optimizations Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- I've looked at match.pd, and spotted missing properties of logarithm. I could poorly write the code for two, still needs to check that the log base is the same: (for logs (LOG LOG2 LOG10) /* logN(a) + logN(b) -> logN(a * b). */ (simplify (plus (logs (@0)) (logs (@1))) (logs (mult:c (@0) (@1 (for logs (LOG LOG2 LOG10) /* logN(a) - logN(b) -> logN(a / b). */ (simplify (sub (logs (@0)) (logs (@1))) (logs (rdiv (@0) (@1 I couldn't code the last one /* logN(b)/logN(a) * logN(c)/logN(b) -> logN(c)/logN(a). */ Here are the test cases: 1: https://godbolt.org/g/boqxQb 2: https://godbolt.org/g/m7zHxK 3: https://godbolt.org/g/KXrbV4
[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #23 from Paul Thomas --- Created attachment 44457 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44457&action=edit A fix for the PR I have just posted the attached fix to the list. Should it be backported - it is very innocuous? Paul
[Bug tree-optimization/86710] 3 missing logarithm optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86710 --- Comment #1 from Marc Glisse --- This kind of transformation needs to be protected by some unsafe math flag, and by a single_use (aka :s) check on the logs. No :c in the output. The third transformation has nothing to do with logs, you are just talking of simplifying (y/x)*(z/y) (possibly after suitable CSE of log(b)).
[Bug middle-end/86711] New: wrong folding of memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86711
Bug ID: 86711
Summary: wrong folding of memchr
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
This example generates wrong code:
$ cat part.c
static const char a[2][4] = { "1234", "5678" };
int main ()
{
void *p = __builtin_memchr (a, 0, 5);
if (p)
__builtin_abort ();
}
$ gcc part.c
$ ./a.out
Aborted (core dumped)
[Bug c/59616] OpenMP standard conflict in parallel default clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59616 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- This has been changed unintentionally in the OpenMP standard, I was hoping and trying to resolve the incompatibility and that is why GCC kept using the 3.1 rule here. In the end after discussing it in the language committee recently we've decided that it is too late to resolve it and it will stay the way it is currently worded, gomp-5_0-branch already implements this behavior and GCC 9 will too.
[Bug fortran/86472] allocatable array, bound-procedure, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86472 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-28 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 6.4.0 up to trunk (9.0).
[Bug libitm/86712] New: libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86712 Bug ID: 86712 Summary: libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Noticed as part of gentoo's QA checker in TEXTRELs in shared libraries: $ scanelf -qTR /usr/lib/gcc/sh4-unknown-linux-gnu/ libitm.so.1.0.0: (memory/data?) [0x8FA4] in (optimized out: previous _ITM_beginTransaction) [0x8F74] /usr/lib/gcc/sh4-unknown-linux-gnu/8.2.0/libitm.so.1.0.0 The TEXTREL comes from R_SH_RELATIVE relocation: $ objdump -d -R ./sh4-unknown-linux-gnu/libitm/.libs/libitm.so.1.0.0 | fgrep -B30 -A4 R_SH_ 8d0e: ff ff .word 0x 8d10: 94 93 mov.w 8e3c <_ZN12_GLOBAL__N_118serialirr_dispatch26closed_nesting_alternativeEv+0x4>,r3 ! dc02 8d12: fe ff fmacfr0,fr15,fr15 8d14 <_ITM_beginTransaction>: 8d14: f3 61 mov r15,r1 8d16: fb ff fmovfr15,@-r15 8d18: eb ff fmovfr14,@-r15 8d1a: db ff fmovfr13,@-r15 8d1c: cb ff fmovfr12,@-r15 8d1e: 62 4f sts.l fpscr,@-r15 8d20: 13 4f stc.l gbr,@-r15 8d22: 22 4f sts.l pr,@-r15 8d24: 16 2f mov.l r1,@-r15 8d26: e6 2f mov.l r14,@-r15 8d28: d6 2f mov.l r13,@-r15 8d2a: c6 2f mov.l r12,@-r15 8d2c: b6 2f mov.l r11,@-r15 8d2e: a6 2f mov.l r10,@-r15 8d30: 96 2f mov.l r9,@-r15 8d32: 86 2f mov.l r8,@-r15 8d34: 03 d1 mov.l 8d44 <_ITM_beginTransaction+0x30>,r1 ! 6d2c 8d36: 0b 41 jsr @r1 8d38: f3 65 mov r15,r5 8d3a: f8 51 mov.l @(32,r15),r1 8d3c: 2a 41 lds r1,pr 8d3e: 3c 7f add #60,r15 8d40: 0b 00 rts 8d42: 09 00 nop 8d44: 2c 6d extu.b r2,r13 8d44: R_SH_RELATIVE *ABS*+0x6d2c ... 8d48 : 8d48: 56 68 mov.l @r5+,r8
[Bug libitm/86712] libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86712 --- Comment #1 from Sergei Trofimovich --- This fix seems to be enough to not encode absolute address into _ITM_beginTransaction: diff --git a/libitm/config/sh/sjlj.S b/libitm/config/sh/sjlj.S index 043f36749be..80a810d8360 100644 --- a/libitm/config/sh/sjlj.S +++ b/libitm/config/sh/sjlj.S @@ -46,21 +46,21 @@ _ITM_beginTransaction: mov.l r12, @-r15 mov.l r11, @-r15 mov.l r10, @-r15 mov.l r9, @-r15 mov.l r8, @-r15 #ifdef __SH_FPU_ANY__ cfi_def_cfa_offset (4*15) #else cfi_def_cfa_offset (4*10) #endif -#if defined HAVE_ATTRIBUTE_VISIBILITY || !defined __PIC__ +#if defined HAVE_ATTRIBUTE_VISIBILITY && !defined __PIC__ mov.l .Lbegin, r1 jsr @r1 movr15, r5 #else mov.l .Lbegin, r1 bsrfr1 movr15, r5 .Lbegin0: mov.l @(4*4,r15), r12 #endif @@ -71,21 +71,21 @@ _ITM_beginTransaction: #else add #(10*5), r15 #endif cfi_def_cfa_offset (0) rts nop cfi_endproc .align 2 .Lbegin: -#if defined HAVE_ATTRIBUTE_VISIBILITY || !defined __PIC__ +#if defined HAVE_ATTRIBUTE_VISIBILITY && !defined __PIC__ .long GTM_begin_transaction #else .long GTM_begin_transaction@PCREL-(.Lbegin0-.) #endif .size _ITM_beginTransaction, . - _ITM_beginTransaction .global GTM_longjmp .hidden GTM_longjmp .type GTM_longjmp, %function
[Bug fortran/86472] allocatable array, bound-procedure, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86472 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- (In reply to Jim Feng from comment #0) > Module M1 > implicit none > > type :: mytype > contains > procedure :: myfunc1 > end type > > interface > > module subroutine myfunc1(self, a) > class(mytype), intent(in) :: self > real, intent(in) :: a(:) > real, allocatable :: t(:) > end subroutine myfunc1 > end interface > End Module M1 > -- > submodule(M1) M2 > contains > > module procedure myfunc1 > !real, allocatable :: t(:) > allocate(t, source=a) > x=10.0 > print *,t, a, x > end procedure myfunc1 > end submodule M2 > > = > > submodule M2 showed compilation error (Error: Allocate-object is neither a > data pointer nor an allocatable variable) without re-declare variable t. > Also un-declared variable x gives no error. Yes indeed with respect to the declaration of 't'. However, since the submodule is a separate compilation unit, I believe that it also must contain an 'implicit none' to pick up the undeclared variable 'x'. I will check the standard on this. Thanks Paul
[Bug libitm/86712] libitm produces libitm.so with TEXTREL on SuperH (sh4) in _ITM_beginTransaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86712 --- Comment #2 from Sergei Trofimovich --- (In reply to Sergei Trofimovich from comment #1) > This fix seems to be enough to not encode absolute address into > _ITM_beginTransaction: Sent the above as https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01776.html for review.
[Bug fortran/86472] allocatable array, bound-procedure, submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86472 --- Comment #3 from Dominique d'Humieres --- > Yes indeed with respect to the declaration of 't'. However, since the > submodule > is a separate compilation unit, I believe that it also must contain > an 'implicit none' to pick up the undeclared variable 'x'. I will check > the standard on this. If I add implicit none real :: x I get print *,t, a, x 1 Error: Symbol 't' at (1) has no IMPLICIT type
[Bug middle-end/86711] wrong folding of memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86711 --- Comment #1 from Bernd Edlinger --- Created attachment 44458 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44458&action=edit untestted patch
[Bug c/86713] New: 'nofp', 'nosimd', 'nocrypto' and 'nofp16' feature modifiers for Aarch64 fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86713 Bug ID: 86713 Summary: 'nofp', 'nosimd', 'nocrypto' and 'nofp16' feature modifiers for Aarch64 fail to build Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vladimir at bashkirtsev dot com Target Milestone: --- Created attachment 44459 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44459&action=edit Patch unrolling wrapped lines in config/aarch64/aarch64-option-extensions.def Build of GCC 8.2.0 fails when built with --with-arch=armv8-a+nocrypto AARCH64_OPT_EXTENSION for 'fp', 'simd', 'crypto' and 'fp16' in config/aarch64/aarch64-option-extensions.def file are wrapped around. They are consumed by config.gcc@3739 and expected to be a single lines. When these lines are wrapped around config.gcc produces invalid tm.h file and gcc fails to build consequently.
[Bug target/86693] inefficient atomic_fetch_xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86693
--- Comment #2 from Ruslan Nikolaev ---
Also may be (partially) related the following cases:
1.
#include
#include
void func2();
void func(_Atomic(unsigned long) * obj, void * obj2)
{
if (atomic_fetch_sub(obj, 1) == 1 && obj2)
func2();
}
generates 'xadd' when 'sub' suffices:
func:
.LFB0:
.cfi_startproc
movq$-1, %rax
lock xaddq %rax, (%rdi)
testq %rsi, %rsi
je .L1
cmpq$1, %rax
je .L10
.L1:
rep ret
.p2align 4,,10
.p2align 3
.L10:
xorl%eax, %eax
jmp func2@PLT
2.
#include
int func(_Atomic(unsigned long) * obj, unsigned long a)
{
return atomic_fetch_add(obj, a) == -a;
}
generates 'xadd' when 'add' suffices:
func:
.LFB0:
.cfi_startproc
movq%rsi, %rax
lock xaddq %rax, (%rdi)
addq%rsi, %rax
sete%al
movzbl %al, %eax
ret
[Bug c++/86706] [8/9 Regression] ICE in build_base_path, at cp/class.c:294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86706 --- Comment #2 from Jason Merrill --- (In reply to Jakub Jelinek from comment #1) > Started with r260782 aka PR85815 fix. > GCC 7 doesn't seem to ICE, eventhough PR85815 has been backported to it. The GCC 7 fix for 85815 was more conservative.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW Component|fortran |target --- Comment #8 from Dominique d'Humieres --- > > This looks like a target issue. Have you ever build gcc on HP-UX 11.31/PA? > > Definitely a target issue. ... Thus moved to target.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 64095, which changed state. Bug 64095 Summary: [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.3 |7.4 --- Comment #14 from Jason Merrill --- Fixed for 8.1/7.4.
[Bug middle-end/86714] New: tree-ssa-forwprop.c confused by too long initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86714
Bug ID: 86714
Summary: tree-ssa-forwprop.c confused by too long initializer
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
as mentioned in https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01220.html
$ cat y.c
const char a[2][3] = { "1234", "xyz" };
char b[6];
int main ()
{
__builtin_memcpy(b, a, 4);
__builtin_memset(b + 4, 'a', 2);
__builtin_printf("%.6s\n", b);
}
$ gcc y.c
y.c:1:24: warning: initializer-string for array of chars is too long
const char a[2][3] = { "1234", "xyz" };
^~
y.c:1:24: note: (near initialization for 'a[0]')
$ ./a.out
1234aa
but expected would be "123xaa".
[Bug target/86713] 'nofp', 'nosimd', 'nocrypto' and 'nofp16' feature modifiers for Aarch64 fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86713 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-28 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- That does look like a bug. Please send patches to gcc-patc...@gcc.gnu.org following the guidelines at https://gcc.gnu.org/contribute.html
[Bug target/86713] 'nofp', 'nosimd', 'nocrypto' and 'nofp16' feature modifiers for Aarch64 fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86713 --- Comment #2 from Vladimir Bashkirtsev --- Would happy oblige but GNU coding standards say "Please keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments." and this bug is caused specifically by adherence to this standard. Patching it with patch attached to this bug report will violate GNU coding standards. Perhaps more complex patch must be applied to config.gcc to cope with wrapped lines. What is your take on it? Also I am honestly struggle with a testcase: not really sure how it can be tested at all (I mean by means of automated testing).
[Bug libgcc/86224] [m68k] textrels in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86224 --- Comment #1 from Sergei Trofimovich --- Sent https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01791.html for review. I went by hidden symbols as they generate roughly the same code as before and don't require GOT/PCREL setup.
[Bug target/86713] 'nofp', 'nosimd', 'nocrypto' and 'nofp16' feature modifiers for Aarch64 fail to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86713 --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Vladimir Bashkirtsev from comment #2) > Would happy oblige but GNU coding standards say "Please keep the length of > source lines to 79 characters or less, for maximum readability in the widest > range of environments." and this bug is caused specifically by adherence to > this standard. Patching it with patch attached to this bug report will > violate GNU coding standards. > > Perhaps more complex patch must be applied to config.gcc to cope with > wrapped lines. > > What is your take on it? > > Also I am honestly struggle with a testcase: not really sure how it can be > tested at all (I mean by means of automated testing). In this case the long line length is necessary for correctness, so that wouldn't disqualify the patch. config.gcc could be made more robust, but that would be a separate piece of work and I'm not sure if it would be worth the complexity just to accommodate line length. The coding style is a guideline to be followed when possible, but it shouldn't dictate the content of the patch. There's no straightforward way to write a testcase for this as it is a GCC build-time bug. When submitting the patch, please mention what configure command fails before your patch and that it succeeds with your patch. That would be strong justification for it.
[Bug fortran/86481] Memory leak with nested sourced allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86481 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-28 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Related to pr80477, but not fixed by the patch at https://gcc.gnu.org/ml/fortran/2018-07/msg00123.html.
[Bug fortran/86481] Memory leak with nested sourced allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86481 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org --- Here is the simplest reduction of the test case that I could find: program simple_leak implicit none type :: foo_t end type class(foo_t), allocatable :: f allocate(f, SOURCE=func_foo()) contains function func_foo () result (f) class(foo_t), allocatable :: f allocate(foo_t :: f) end function end It leaks a lot less, though: ==27446== HEAP SUMMARY: ==27446== in use at exit: 2 bytes in 2 blocks ==27446== total heap usage: 23 allocs, 21 frees, 13,562 bytes allocated ==27446== ==27446== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2
[Bug target/86693] inefficient atomic_fetch_xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86693 --- Comment #3 from Ruslan Nikolaev --- (In reply to Jakub Jelinek from comment #1) > The reason why this works for sub/add is that x86 has xadd instruction, so > we expand it as xadd and later on during combine find out we are actually > comparing the result of lock; xadd with something we can optimize better and > do the optimization. > For __atomic_fetch_xor (ptr, x, y) == x (or != x), or __atomic_xor_fetch > (ptr, x, y) == 0 (or != 0), or __atomic_or_fetch (ptr, x, y) == 0 (or != 0), > we'd need to handle this specially already at expansion time, so with extra > special optabs, because there is no instruction that keeps the old or new > value of xor or ior in a register, and once we emit a compare and exchange > loop, it is very hard to optimize that to something different. btw, do not know exactly how gcc handles it... Is it possible to emit an artificial 'xxor' instruction which acts like xadd? Then during optimization, xxor can be replaced to xor or to cmpxchg-loop depending on the circumstances.
[Bug middle-end/86715] New: ICE passing too large argument on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86715
Bug ID: 86715
Summary: ICE passing too large argument on stack
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
#define COLS 24000L
struct Matrix {
float data[COLS * COLS];
};
float mulv(float A[], float B[], int i, int j)
{
float result = 0.0;
{ int k; for (k = 0; k < COLS; ++k)
result += A[i*COLS + k] * B[j + k*COLS];
}
return result;
}
struct Matrix mulm(struct Matrix A, struct Matrix B)
{
struct Matrix result;
#define IJ(M) (M[i*COLS + j])
{ int i, j; for (i = 0; i < COLS; ++i)
for (j = 0; j < COLS; ++j)
IJ(result.data) = mulv(A.data, B.data, i, j);
}
return result;
}
int main(int argc, char* argv[])
{
struct Matrix m1, m2, result;
result = mulm(m1, m2);
return result.data[argc];
}
The error messages of gcc are as follows:
2sameartificialtestprogramhopefullytextplain.cpp: In function 'int main(int,
char**)':
2sameartificialtestprogramhopefullytextplain.cpp:34:23: sorry, unimplemented:
passing too large argument on stack
result = mulm(m1, m2);
^
2sameartificialtestprogramhopefullytextplain.cpp:34:23: sorry, unimplemented:
passing too large argument on stack
during RTL pass: expand
2sameartificialtestprogramhopefullytextplain.cpp:34:23: internal compiler
error: in expand_call, at calls.c:4591
0x6d26bd expand_call(tree_node*, rtx_def*, int)
../../gcc9.0/gcc/calls.c:4588
0xbdfefe expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc9.0/gcc/expr.c:10914
0xbec31f store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc9.0/gcc/expr.c:5614
0xbed74b expand_assignment(tree_node*, tree_node*, bool)
../../gcc9.0/gcc/expr.c:5398
0xadb8e4 expand_call_stmt
../../gcc9.0/gcc/cfgexpand.c:2685
0xadb8e4 expand_gimple_stmt_1
../../gcc9.0/gcc/cfgexpand.c:3575
0xadb8e4 expand_gimple_stmt
../../gcc9.0/gcc/cfgexpand.c:3734
0xadcc4f expand_gimple_basic_block
../../gcc9.0/gcc/cfgexpand.c:5769
0xae1837 execute
../../gcc9.0/gcc/cfgexpand.c:6372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/86716] New: use of parameter outside function body before ‘++’ token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86716
Bug ID: 86716
Summary: use of parameter outside function body before ‘++’
token
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
#include
int
f (int a, int b[a++], int c, int d[c++])
{
printf ("%d %d\n", a, c);
}
int
main (void)
{
int dummy[10];
f (1, dummy, 1, dummy);
return 0;
}
gcc rejects the code:
gcc code0.c.cpp
code0.c.cpp:3:18: error: use of parameter outside function body before '++'
token
f (int a, int b[a++], int c, int d[c++])
^~
code0.c.cpp:3:21: error: expected ')' before ',' token
f (int a, int b[a++], int c, int d[c++])
~ ^
)
code0.c.cpp:3:23: error: expected unqualified-id before 'int'
f (int a, int b[a++], int c, int d[c++])
^~~
clang accepts the code. The above code looks legal?
[Bug c++/86717] New: Unexpected error in dynamic allocation of an array of function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86717
Bug ID: 86717
Summary: Unexpected error in dynamic allocation of an array of
function pointers
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/** BEGIN SOURCE **/
template
void f() {
typedef void(*arr[T::value])();
new arr; // OK
new (void(*[(T::value)])()); // OK
new (void(*[T::value])()); // error: capture of non-variable 'T'
}
struct S {
static constexpr int value = 5;
};
int main() {
f();
}
/*** END SOURCE ***/
The last new-expression is rejected (as I believe, incorrectly). For
comparison, clang and MSVC compile this code successfully.
Tested with build 9.0.0 20180726 (experimental).
[Bug c/71422] Total size of static objects is not limited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71422 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-29 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to Jakub Jelinek from comment #1) > > IMNSHO gcc shouldn't, after all, if you just put each into a separate CU, > > gcc won't even see them together. It should be linker's responsibility to > > complain. > > What if you use LTO? WAITING on a reply to this
[Bug c/70952] Missing warning for likely-erroneous octal escapes in string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70952 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60523 --- Comment #9 from Eric Gallager --- Even if this isn't a dup I'd say it's still related enough to go under "See Also" though
[Bug c++/86716] use of parameter outside function body before ‘++’ token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86716 --- Comment #1 from Andrew Pinski --- With the C front-end this is accepted. I suspect C99 feature is not implemented in the C++ front-end.
[Bug c/86718] New: ICE during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86718
Bug ID: 86718
Summary: ICE during RTL pass: expand
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
void __attribute__((noinline, noclone))
test(char *data, __SIZE_TYPE__ len)
{
static char const appended[] = "/./";
char *buf = __builtin_alloca (len + sizeof appended);
__builtin_memcpy (buf, data, len);
__builtin_strcpy (buf + len, &appended[data[len - 1] == '/']);
if (__builtin_strcmp(buf, "test1234/./"))
__builtin_abort();
}
int
main()
{
char *arg = "test1234/";
test(arg, __builtin_strlen(arg));
return 0;
}
The error messages are as follows:
gcc code5.c
during RTL pass: expand
code5.c: In function 'test':
code5.c:7:2: internal compiler error: tree check: expected integer_cst, have
minus_expr in get_len, at tree.h:5553
__builtin_strcpy (buf + len, &appended[data[len - 1] == '/']);
^
0x717120 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc9.0/gcc/tree.c:9351
0x6226ea tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc9.0/gcc/tree.h:3373
0x6226ea wi::extended_tree<192>::get_len() const
../../gcc9.0/gcc/tree.h:5553
0x6226ea wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc9.0/gcc/wide-int.h:961
0x6226ea wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc9.0/gcc/wide-int.h:1010
0x6226ea generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc9.0/gcc/wide-int.h:785
0x6226ea bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc9.0/gcc/wide-int.h:1877
0x6226ea wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
>,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc9.0/gcc/wide-int.h:3224
0x6226ea tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc9.0/gcc/tree.h:5709
0x6226ea check_access
../../gcc9.0/gcc/builtins.c:3199
0x8ac3fd expand_builtin_strcpy
../../gcc9.0/gcc/builtins.c:3816
0x8ac3fd expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc9.0/gcc/builtins.c:7220
0x9cfe15 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc9.0/gcc/expr.c:10911
0x8cb478 expand_expr
../../gcc9.0/gcc/expr.h:279
0x8cb478 expand_call_stmt
../../gcc9.0/gcc/cfgexpand.c:2687
0x8cb478 expand_gimple_stmt_1
../../gcc9.0/gcc/cfgexpand.c:3575
0x8cb478 expand_gimple_stmt
../../gcc9.0/gcc/cfgexpand.c:3734
0x8cc40f expand_gimple_basic_block
../../gcc9.0/gcc/cfgexpand.c:5769
0x8d0ff7 execute
../../gcc9.0/gcc/cfgexpand.c:6372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
