[Bug fortran/100914] Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 --- Comment #4 from José Rui Faustino de Sousa --- Created attachment 50956 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50956=edit Missing macros
[Bug fortran/100914] Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 --- Comment #3 from José Rui Faustino de Sousa --- This is the same problem as in PR100910. I will attach an updated file. Thank you very much. Best regards, José Rui
[Bug fortran/100910] Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 --- Comment #4 from José Rui Faustino de Sousa --- Created attachment 50955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50955=edit Missing macros
[Bug fortran/100910] Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 --- Comment #3 from José Rui Faustino de Sousa --- AFAIK the "CMPLX" macros are part of C11 and should be defined in the standard header "complex.h"... Since there are no complains about the header, maybe just adding the definition of the macro will do the trick... #define CMPLXL(x, y) ((long double complex)((long double)(x) + I * (long double)(y))) I will attach an altered file. Thank you very much. Best regards, José Rui
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #4 from José Rui Faustino de Sousa --- Created attachment 50954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50954=edit Mac OS support
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #3 from José Rui Faustino de Sousa --- It seems that Mac OS doesn't have the full set of C11 standard headers... :-( It should work using "stdint.h" and typedef(ing) char32_t to uint32_t. If that doesn't work either one could try "unsigned int". I will attach an updated file, with the altered file. I have no access to Mac OS, so I cannot test it. Thank you very much. Best regards, José Rui
[Bug tree-optimization/100925] [12 Regression] tree check fail in make_range_step with -O1 in reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=53336 --- Comment #6 from Andrew Pinski --- Related to the older PR 53336 bug.
[Bug c++/100928] New: [c++20] ICE with structural type value returned from constexpr function as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100928 Bug ID: 100928 Summary: [c++20] ICE with structural type value returned from constexpr function as template argument Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: josephcanedo at hotmail dot com Target Milestone: --- Created attachment 50953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50953=edit test_tag.cpp $ g++-11 -std=c++20 -c test_tag.cpp test_tag.cpp:40:43: internal compiler error: Segmentation fault 40 | using concat_test = test; | ^ 0xe30681 internal_error(char const*, ...) ???:0 0x1062d42 resolve_args(vec*, int) ???:0 0x10a169a finish_template_type(tree_node*, tree_node*, int) ???:0 0x1492c03 c_parse_file() ???:0 0x148061e c_common_parse_file() ???:0 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions.
[Bug fortran/95501] ICE in gfc_match_pointer_assignment, at fortran/match.c:1422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95501 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- See also PR95502#3.
[Bug tree-optimization/100925] [12 Regression] tree check fail in make_range_step with -O1 in reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > It was exposed by r12-1152. > > Phi-opt produces this now: > _9 = _3 != 0B; > _10 = (<<< Unknown tree: offset_type >>>) _9; > _11 = -_10; > /// The above is new > > _6 = _3 != 0B; > _7 = _11 != -1; > _8 = _6 & _7; > > - CUT > before reassoc we have: > _9 = _3 != 0B; > _10 = (<<< Unknown tree: offset_type >>>) _9; > _11 = -_10; > _7 = _11 != -1; > _8 = _7 & _9; > CUT --- > > But _9 and _7 will always have the same value even. The problem is r12-1055 really which causes the offset type to used here. I need a check for INTEGRAL_TYPE_P to avoid this.
[Bug tree-optimization/100925] [12 Regression] tree check fail in make_range_step with -O1 in reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-05 CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- It was exposed by r12-1152. Phi-opt produces this now: _9 = _3 != 0B; _10 = (<<< Unknown tree: offset_type >>>) _9; _11 = -_10; /// The above is new _6 = _3 != 0B; _7 = _11 != -1; _8 = _6 & _7; - CUT before reassoc we have: _9 = _3 != 0B; _10 = (<<< Unknown tree: offset_type >>>) _9; _11 = -_10; _7 = _11 != -1; _8 = _7 & _9; CUT --- But _9 and _7 will always have the same value even.
[Bug c++/100925] tree check fail in make_range_step, at fold-const.c:5061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925 --- Comment #3 from David Binderman --- That one seems bad, so current range is (ea418485c700494c..d2d74c9fc0cf46f6), so 15 revisions left.
[Bug c/100920] bogus warnings with -Wscalar-storage-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100920 --- Comment #3 from Eric Botcazou --- > It may not be immediately obvious from my example but the the builtin_alloca > is not the only problem. > > Any malloc/calloc has the same effect. Even if one requires casts at alloc > time, any free will trigger the same warning. > > t_s12 *msg1 = (t_s12)malloc(10); > free(msg1); > > I don't understand what the incompatibility reported is with void pointers. > To my understanding they are type-less and can't be dereferenced. Yes, the compiler treats alloca/malloc/calloc the same for this purpose.
[Bug c++/100925] tree check fail in make_range_step, at fold-const.c:5061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925 --- Comment #2 from David Binderman --- (In reply to David Binderman from comment #1) > Seems ok at ea418485c700494c. Trying 7ed1cd9665d8ca0f Tried it and it seems bad. Range seems to be (ea418485c700494c, 7ed1cd9665d8ca0f). Trying d2d74c9fc0cf46f6.
[Bug target/100927] New: [sse2] floating point to integer conversion functions incorrect results w/ NaN constants + optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100927
Bug ID: 100927
Summary: [sse2] floating point to integer conversion functions
incorrect results w/ NaN constants + optimization
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
_mm_cvttpd_epi32, _mm_cvttpd_pi32, _mm_cvttps_epi32, and _mm_cvttsd_si32 are
supposed to return INT32_MIN for NaN inputs. However, when compiled with
optimization on GCC, if the values are known at compile time NaN inputs result
in 0 in the output.
Here is a quick test case, using _mm_cvttpd_epi32:
#include
#include
int main(void) {
static const double values[] = {
__builtin_nan(""), -__builtin_nan("")
};
int32_t res[4];
_mm_storeu_si128((__m128i*) res, _mm_cvttpd_epi32(_mm_loadu_pd(values)));
for (int i = 0 ; i < 4 ; i++) {
printf("%d\n", res[i]);
}
return 0;
}
Compile with `gcc -O1 -o test test.c` and you get all zeros, `gcc -O0 -o test
test.c` and the first two elements of the result are INT32_MIN as they should
be. Changing the const to volatile (and adding -Wno-discarded-qualifiers)
"fixes" the issue.
[Bug c++/100925] tree check fail in make_range_step, at fold-const.c:5061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925 --- Comment #1 from David Binderman --- Seems ok at ea418485c700494c. Trying 7ed1cd9665d8ca0f
[Bug target/100926] New: PPCLE: Inefficient code for vec_xl_be(unsigned short *) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100926
Bug ID: 100926
Summary: PPCLE: Inefficient code for vec_xl_be(unsigned short
*) < P9
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
Input:
vector unsigned short load_be(unsigned short *c)
{
return vec_xl_be(0L, c);
}
creates:
_Z7load_bePt:
.LFB6:
.cfi_startproc
.LCF6:
0: addis 2,12,.TOC.-.LCF6@ha
addi 2,2,.TOC.-.LCF6@l
.localentry _Z7load_bePt,.-_Z7load_bePt
addis 9,2,.LC4@toc@ha
lxvw4x 34,0,3
addi 9,9,.LC4@toc@l
lvx 0,0,9
vperm 2,2,2,0
blr
Optimal sequence:
vector unsigned short load_be_opt2(unsigned short *c)
{
vector signed int vneg16;
__asm__("vspltisw %0,-16":"=v"(vneg16));
vector unsigned int tmp = vec_xl_be(0L, (unsigned int *)c);
tmp = vec_rl(tmp, (vector unsigned int)vneg16);
return (vector unsigned short)tmp;
}
creates:
_Z12load_be_opt2Pt:
.LFB8:
.cfi_startproc
lxvw4x 34,0,3
#APP
# 77 "vec.C" 1
vspltisw 0,-16
# 0 "" 2
#NO_APP
vrlw 2,2,0
blr
rotate left (-16) = rotate right (+16) as only the 5 bits get evaluated.
Please note that the inline assembly is required, because vec_splats(-16) gets
converted into a very inefficient constant generation.
vector unsigned short load_be_opt(unsigned short *c)
{
vector signed int vneg16 = vec_splats(-16);
vector unsigned int tmp = vec_xl_be(0L, (unsigned int *)c);
tmp = vec_rl(tmp, (vector unsigned int)vneg16);
return (vector unsigned short)tmp;
}
creates:
_Z11load_be_optPt:
.LFB7:
.cfi_startproc
li 9,48
lxvw4x 34,0,3
vspltisw 0,0
mtvsrd 33,9
xxspltw 33,33,1
vsubuwm 0,0,1
vrlw 2,2,0
blr
[Bug c/100920] bogus warnings with -Wscalar-storage-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100920 --- Comment #2 from George Thopas --- (In reply to Eric Botcazou from comment #1) > The warning on the union is indeed an oversight, but the other is > conservatively correct, although we may make a special case for > __builtin_alloca. Hi Eric, first of all, thanks for looking into this. It may not be immediately obvious from my example but the the builtin_alloca is not the only problem. Any malloc/calloc has the same effect. Even if one requires casts at alloc time, any free will trigger the same warning. t_s12 *msg1 = (t_s12)malloc(10); free(msg1); I don't understand what the incompatibility reported is with void pointers. To my understanding they are type-less and can't be dereferenced.
[Bug c++/100925] New: tree check fail in make_range_step, at fold-const.c:5061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100925
Bug ID: 100925
Summary: tree check fail in make_range_step, at
fold-const.c:5061
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C++ code:
struct QScopedPointerDeleter {
static void cleanup(int *);
};
class QScopedPointer {
typedef int *QScopedPointer::*RestrictedBool;
public:
operator RestrictedBool() { return d ? nullptr : ::d; }
void reset() {
if (d)
QScopedPointerDeleter::cleanup(d);
}
int *d;
};
class DOpenGLPaintDevicePrivate {
public:
QScopedPointer fbo;
} DOpenGLPaintDeviceresize_d;
void DOpenGLPaintDeviceresize() {
if (DOpenGLPaintDeviceresize_d.fbo)
DOpenGLPaintDeviceresize_d.fbo.reset();
}
compiled with recent gcc trunk, does this:
$ /home/dcb/gcc/results.20210605//bin/g++ -c -w -O1 bug722.cc 2>&1 | more
during GIMPLE pass: reassoc
bug722.cc: In function ‘void DOpenGLPaintDeviceresize()’:
bug722.cc:19:6: internal compiler error: tree check: expected boolean_type or
enumeral_type or integer_type, have offset_type in make_range_step, at fold-co
nst.c:5061
19 | void DOpenGLPaintDeviceresize() {
| ^~~~
0x8a9565 tree_check_failed(tree_node const*, char const*, int, char const*, ..
.)
../../trunk.git/gcc/tree.c:8684
0x7a0a73 any_integral_type_check(tree_node*, char const*, int, char const*)
../../trunk.git/gcc/tree.h:3617
0x7ad465 any_integral_type_check(tree_node*, char const*, int, char const*)
../../trunk.git/gcc/tree.h:3485
0x7ad465 make_range_step(unsigned int, tree_code, tree_node*, tree_node*, tree
_node*, tree_node**, tree_node**, int*, bool*)
../../trunk.git/gcc/fold-const.c:5061
The problem first seems to occur sometime between date 20210527 and 20210604.
Git hashes 6c67afaf524a5e0e and ad3f0ad4bafe3770.
I will have my usual go at refining the range of the git hashes.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from John David Anglin --- Fixed.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #13 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:a0864ce8662bb9d715b51513697309f198f1da19 commit r12-1240-ga0864ce8662bb9d715b51513697309f198f1da19 Author: John David Anglin Date: Sat Jun 5 15:48:04 2021 + Use libiberty snprintf and vsnprintf on hppa*-*-hpux*. libiberty/ChangeLog: PR target/100734 * configure.ac: Use libiberty snprintf and vsnprintf on hppa*-*-hpux*. * configure: Regenerate.
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 John David Anglin changed: What|Removed |Added Component|middle-end |target --- Comment #12 from John David Anglin --- Using libiberty snprintf and vsnprintf on hppa*-*-hpux* works.
[Bug ipa/100529] [11/12 Regression] ICE at -O3: in force_constant_size, at gimplify.c:733 since r11-4494-ga4223abb3deb24e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100529
--- Comment #3 from Chengnian Sun ---
Another duplicate.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210605 (experimental) [master revision
:438cdd67a:600f90cbbbf2f1e4511d72a23a5d637d11e9f28b] (GCC)
$ cat mutant.c
foo(char a) {
union C {
int d[map()];
char *e;
};
bar((union C) & a);
}
$ gcc-trunk mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | foo(char a) {
| ^~~
mutant.c: In function ‘foo’:
mutant.c:3:11: warning: implicit declaration of function ‘map’
[-Wimplicit-function-declaration]
3 | int d[map()];
| ^~~
mutant.c:6:3: warning: implicit declaration of function ‘bar’
[-Wimplicit-function-declaration]
6 | bar((union C) & a);
| ^~~
mutant.c:6:3: internal compiler error: in force_constant_size, at
gimplify.c:736
6 | bar((union C) & a);
| ^~
0x6d844a force_constant_size
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:736
0xc2c537 gimple_add_tmp_var(tree_node*)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:774
0xbf557b create_tmp_var(tree_node*, char const*)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimple-expr.c:485
0xc36200 create_tmp_from_val
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:567
0xc36200 lookup_tmp_var
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:585
0xc36200 internal_get_tmp_var
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:638
0xc2fd57 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:15065
0xc31676 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:14526
0xc3e1f4 gimplify_expr
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:15111
0xc40105 gimplify_call_expr
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:3527
0xc30f13 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:14048
0xc3410a gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:6863
0xc3170b gimplify_statement_list
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:1885
0xc3170b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:14521
0xc3410a gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:6863
0xc3493e gimplify_bind_expr
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:1424
0xc30b73 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:14277
0xc3410a gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:6863
0xc35703 gimplify_body(tree_node*, bool)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:15321
0xc35b51 gimplify_function_tree(tree_node*)
/tmp/tmp.YBPd3t5p5G-gcc-builder/gcc/gcc/gimplify.c:15475
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/100920] bogus warnings with -Wscalar-storage-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100920 Eric Botcazou changed: What|Removed |Added Summary|bogus warn on |bogus warnings with |-Wscalar-storage-order |-Wscalar-storage-order Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED Version|unknown |12.0
[Bug c/100920] bogus warn on -Wscalar-storage-order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100920 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-06-05 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- The warning on the union is indeed an oversight, but the other is conservatively correct, although we may make a special case for __builtin_alloca.
[Bug fortran/100914] Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-05 Status|UNCONFIRMED |WAITING --- Comment #2 from Dominique d'Humieres --- On my system I get % gfc pr100914.f90 pr100914.c pr100914.c: In function 'c_vrfy_float_complex': pr100914.c:61:22: warning: implicit declaration of function 'CMPLXF' [-Wimplicit-function-declaration] 61 | if ((cabsf (*ip-(CMPLXF((float)(i+1), (float)(2*(i+1)>(float)0.0)) | ^~ pr100914.c: In function 'c_vrfy_double_complex': pr100914.c:98:21: warning: implicit declaration of function 'CMPLX' [-Wimplicit-function-declaration] 98 | if ((cabs (*ip-(CMPLX((double)(i+1), (double)(2*(i+1)>(double)0.0)) | ^ Undefined symbols for architecture x86_64: "_CMPLX", referenced from: _c_vrfy_double_complex in ccFYXXYa.o _c_vrfy_float128_complex in ccFYXXYa.o "_CMPLXF", referenced from: _c_vrfy_float_complex in ccFYXXYa.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
[Bug fortran/100910] Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-06-05 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- On my system I get % gfc pr100910.f90 pr100910.c pr100910.c: In function 'c_vrfy_long_double_complex': c_vrfy_long_double_complex': pr100910.c:49:43: warning: implicit declaration of function 'CMPLX' [-Wimplicit-function-declaration] 49 | if ((cabsl (*ip-(long double complex)(CMPLX((double)(i+1), (double)(2*(i+1)>(long double)0.0)) | ^ Undefined symbols for architecture x86_64: "_CMPLX", referenced from: _c_vrfy_long_double_complex in ccyI5oZ3.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-06-05 --- Comment #2 from Dominique d'Humieres --- On my system I get % gfc pr100907.f90 pr100907.c pr100907.c:4:10: fatal error: uchar.h: No such file or directory 4 | #include | ^ compilation terminated.
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
Dominique d'Humieres changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING |RESOLVED
--- Comment #9 from Dominique d'Humieres ---
I don't know if the test is coming from a real world problem. The modified test
program power
implicit none
real :: sum, sum1, n, q
integer :: i, j
integer :: limit
real :: start, finish
sum = 0d0
sum1 = 0d0
limit = 1
n = 2.0
q = 0.5
call CPU_TIME(start)
do i=1, limit
n = n*q
sum1 = sum1 + (i ** (0.05 + n))
end do
do i=1, limit
sum = sum + (i ** 0.05)
end do
sum = sum1 + (limit-1)*sum
call CPU_TIME(finish)
print *, sum, n, sum1
print '("Time = ",f6.3," seconds.")',finish-start
end program power
yields
150945680. 0. 15095.7852
Time = 0.000 seconds.
[Bug tree-optimization/100923] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100923 --- Comment #1 from Zhendong Su --- It seems to affect all versions since 9.*, but not 8.*.
[Bug c/100924] GCC 11.1.1 internal compiler error: segfault at VLA function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100924 --- Comment #3 from Christian Holme --- Created attachment 50952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50952=edit Compilation log with gcc master, including exact version and command line
[Bug c/100924] GCC 11.1.1 internal compiler error: segfault at VLA function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100924 --- Comment #2 from Christian Holme --- Created attachment 50951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50951=edit Source prepocessed with gcc 11.1.1
[Bug c/100924] GCC 11.1.1 internal compiler error: segfault at VLA function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100924 --- Comment #1 from Christian Holme --- Created attachment 50950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50950=edit Compilation log with gcc 11.1.1, including exact version and command line
[Bug c/100924] New: GCC 11.1.1 internal compiler error: segfault at VLA function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100924 Bug ID: 100924 Summary: GCC 11.1.1 internal compiler error: segfault at VLA function definition Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: christian.holme at med dot uni-goettingen.de Target Milestone: --- Created attachment 50949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50949=edit Failing source Hey, when compiling the attached vlatest_min.c, I encounter an internal compiler error: segmentation fault with gcc 11.1.1. The precise version information (collected with gcc -v) can be found in the attached compilation log. With gcc master from 2021-06-02 it compiles without error. Changing optimization level from -O3 to -O1 also removes the segfault, but -O2 still segfaults. I have also attached the compiler output for both gcc 11 and 12 (master) and the preprocessed files in both cases. Since a fix for it exists on master, I am submitting this bug report in the hopes that it will make it easier to fix in the next release of gcc 11. Best regards
[Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #2 from Jonathan Wakely --- Yes, or use "-Wl,-rpath,$HOME/usr/lib64" when linking. I won't be able to test this myself until Monday
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:96963713f6a648a0ed890450e02ebdd8ff583b14 commit r12-1232-g96963713f6a648a0ed890450e02ebdd8ff583b14 Author: Jonathan Wakely Date: Sat Jun 5 11:42:01 2021 +0100 libstdc++: Fix return type of ranges::ssize for 128-bit integer [PR 100824] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100824 * include/bits/ranges_base.h (_SSize): Return signed type. * testsuite/std/ranges/access/ssize.cc: Check with __int128.
[Bug tree-optimization/100923] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100923
Bug ID: 100923
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[560] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210605 (experimental) [master revision
549d7f4310f:e97b11a9189:f31729d794c4150f6cba97f33ec125e180abd7dd] (GCC)
[561] %
[561] % gcctk -O1 small.c; ./a.out
[562] %
[562] % gcctk -Os small.c
[563] % ./a.out
Floating point exception
[564] %
[564] % cat small.c
int a = 1, b, c, *d = , *e = , f;
void g(int h) {}
void k(int *l) {
int ***j;
if (c) {
*j =
***j;
}
g(*l);
*e = f;
if (*l) {
int i = b / a;
a = i;
}
}
int main() {
k(d);
return 0;
}
[Bug tree-optimization/100922] CSE leads to fully redundant (back to back) zero-extending loads of the same thing in a loop, or a register copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100922 --- Comment #3 from Andrew Pinski --- (In reply to Peter Cordes from comment #2) > Possibly also related: Fully unrelated.
[Bug tree-optimization/100922] CSE leads to fully redundant (back to back) zero-extending loads of the same thing in a loop, or a register copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100922
--- Comment #2 from Peter Cordes ---
Possibly also related:
With different surrounding code, this loop can compile to asm which has two
useless movz / mov register copies in the loop at -O2
(https://godbolt.org/z/PTcqzM6q7). (To set up for entry into the next loop in
over-complicated ways, and doing this in the loop is unnecessary.)
while( lut[(unsigned char)*str] == 0 ){ // also catches terminating 0
str++;
}
.L19:
movzbl 1(%rdi), %edx
addq$1, %rdi
movzbl %dl, %ecx
movl%edx, %eax
cmpb$0, -120(%rsp,%rcx)
je .L19
from source
void remove_chars(char *restrict str, const char *restrict remove)
{
char lut[256] = {0};
do {
lut[(unsigned char)*remove] = -1;
}while(*remove++);
/*** Over complicated asm in this loop */
while( lut[(unsigned char)*str] == 0 ){ // also catches terminating 0
str++;
}
// str points at first char to *not* keep (or the terminating 0)
const char *in = str;
char *out = str;
while (*in)
{
char mask = lut[(unsigned char)*in];
unsigned char cin = *in, cout = *out;
*out = mask ? cout : cin;
out += mask + 1;
in++;
}
*out = *in;
}
[Bug tree-optimization/100922] CSE leads to fully redundant (back to back) zero-extending loads of the same thing in a loop, or a register copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100922 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-05 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Pre takes: [local count: 1073741824]: # str_9 = PHI # out_10 = PHI str_16 = str_9 + 1; c_17 = *str_9; _5 = (sizetype) c_17; _6 = keep_lut_14(D) + _5; inc_18 = *_6; *out_10 = c_17; _7 = (sizetype) inc_18; out_20 = out_10 + _7; if (c_17 != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 955630224]: goto ; [100.00%] Changes it to: [local count: 1073741824]: # str_9 = PHI # out_10 = PHI # prephitmp_60 = PHI str_16 = str_9 + 1; c_17 = *str_9; _5 = (sizetype) c_17; _6 = keep_lut_14(D) + _5; *out_10 = c_17; _7 = (sizetype) prephitmp_60; out_20 = out_10 + _7; if (c_17 != 0) goto ; [89.00%] else goto ; [11.00%] [local count: 955630224]: pretmp_55 = MEM[(char *)str_9 + 1B]; _57 = (sizetype) pretmp_55; _58 = keep_lut_14(D) + _57; pretmp_59 = *_58; goto ; [100.00%] And then ch_vect changes it to (basically undoing the PRE): [local count: 850510900]: [local count: 955630224]: # str_42 = PHI # str_41 = PHI # out_38 = PHI pretmp_55 = MEM[(char *)str_42 + 1B]; _57 = (sizetype) pretmp_55; _58 = keep_lut_14(D) + _57; pretmp_59 = *_58; str_16 = str_41 + 1; c_17 = *str_41; *out_38 = c_17; _7 = (sizetype) pretmp_59; out_20 = out_38 + _7; if (c_17 != 0) goto ; [89.00%] else goto ; [11.00%] And then IVOPTS comes around and does: [local count: 850510900]: [local count: 955630224]: # str_41 = PHI # out_38 = PHI pretmp_55 = MEM[(char *)str_41]; _57 = (sizetype) pretmp_55; _58 = keep_lut_14(D) + _57; pretmp_59 = *_58; str_16 = str_41 + 1; c_17 = MEM[(char *)str_16 + -1B]; *out_38 = c_17; _7 = (sizetype) pretmp_59; out_20 = out_38 + _7; if (c_17 != 0) goto ; [89.00%] else goto ; [11.00%] Which is fine except FRE (and DOM), don't recognize the MEM[(char *)str_16 + -1B] and MEM[(char *)str_41] being the same. For FRE, it almost looks like TARGET_MEM_REF is not handled
[Bug tree-optimization/100922] New: CSE leads to fully redundant (back to back) zero-extending loads of the same thing in a loop, or a register copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100922
Bug ID: 100922
Summary: CSE leads to fully redundant (back to back)
zero-extending loads of the same thing in a loop, or a
register copy
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Created attachment 50948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50948=edit
redundant_zero_extend.c
It's rarely a good idea to load the same thing twice; generally better to copy
a register. Or to read the same register twice when a copy isn't needed. So
the following asm should never happen, but it does with current trunk, and
similar with GCC as old as 4.5
movzbl (%rax), %edx
movzbl (%rax), %ecx# no branch target between these instructions
or
ldrbw4, [x2]
ldrbw3, [x2], 1 # post-indexed *x2++
(Happens at -O3. With -O2 we have a redundant register copy, so either way
still a wasted instruction. And there are other differences earlier in the
function with -O2 vs. -O3.)
https://godbolt.org/z/jT7WaWeK8 - minimal test case. x86-64 and AArch64 trunk
show basically identical code structure. x86-64 gcc (Compiler-Explorer-Build)
12.0.0 20210603 and aarch64-unknown-linux-gnu-gcc (GCC) 12.0.0 20210524
void remove_chars_inplace(char *str, const unsigned char keep_lut[256])
{
while(keep_lut[(unsigned char)*str]){ // can be an if() and still repro
str++;// keep_lut[0] is false
}
char *out = str;
unsigned char c; /* must be unsigned char for correctness. */
do {
c = *str++;
unsigned char inc = keep_lut[c]; // unsigned long doesn't help
*out = c;
out += inc; // inc=0 or 1 to let next char overwrite or not
} while(c);
}
x86-64 asm:
remove_chars_inplace:
jmp .L8
.L3:# top of search loop for first char to remove
addq$1, %rdi
.L8:# loop entry point
movzbl (%rdi), %eax
cmpb$0, (%rsi,%rax) # un-laminates and doesn't macro-fuse ...
jne .L3
cmpb$0, (%rdi) # 2nd loop body can be skipped if *str == 0
# should be test %al,%al - this char was
already loaded.
leaq1(%rdi), %rax# even -march=znver2 fails to move this
earlier or later to allow cmp/je fusion. (Intel won't macro-fuse cmp imm,mem /
jcc)
je .L1
.L5: # TOP OF 2ND LOOP
movzbl (%rax), %edx
movzbl (%rax), %ecx # redundant load of *str
addq$1, %rax
movzbl (%rsi,%rdx), %edx # inc = lut[c]
movb%cl, (%rdi)
addq%rdx, %rdi # out += inc
testb %cl, %cl
jne .L5# }while(c != 0)
.L1:
ret
IDK if it's interesting or not that the cmpb $0, (%rdi) is also a redundant
load. The first loop left *str, i.e. (%rdi), in EAX. Putting the LEA between
cmp and je (even with -march=znver2) is a separate missed optimization.
(unless that's working around Intel's JCC erratum)
With only -O2 instead of -O3, we get better asm in that part: it takes
advantage of having the char in AL, and jumps into the middle of the next loop
after xor-zeroing the `inc` variable.
Replacingc = *str++; with
c = *str;
str++;
results in a wasted register copy with trunk, instead of a 2nd load (on x86-64
and arm64). Still a missed opt, but less bad. GCC7 and earlier still do an
extra load with either way of writing that.
Removing the first loop, or making its loop condition something like *str &&
keep_lut[*str], removes the problem entirely. The CSE possibility is gone.
(Same even if we use lut[*(unsigned char*)str] - type-pun the pointer to
unsigned char instead of casting the signed char value to unsigned char, on x86
where char is signed, but not on arm64 where char is unsigned.)
---
I didn't find any clear duplicates; the following are barely worth mentioning:
* pr94442 looks like extra spilling, not just redundant loading.
* pr97366 is due to vectors of different types, probably.
* pr64319 needs runtime aliasing detection to avoid, unlike this.
The AArch64 version of this does seem to demo pr71942 (a useless and x4, x2,
255 on an LDRB result) when you get it to copy a register instead of doing a
2nd load.
[Bug libstdc++/100824] ranges::size should treat the subexpression as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100824 --- Comment #8 from Jonathan Wakely --- Doh yes, that's just a brain fart
[Bug rtl-optimization/88770] Redundant load opt. or CSE pessimizes code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88770 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #2 from Peter Cordes --- Note that mov r64, imm64 is a 10-byte instruction, and can be slow to read from the uop-cache on Sandybridge-family. The crap involving OR is clearly sub-optimal, but *if* you already have two spare call-preserved registers across this call, the following is actually smaller code-size: movabs rdi, 21474836483 mov rbp, rdi movabs rsi, 39743127552 mov rbx, rsi calltest mov rdi, rbp mov rsi, rbx calltest This is more total uops for the back-end though (movabs is still single-uop, but takes 2 entries the uop cache on Sandybridge-family; https://agner.org/optimize/). So saving x86 machine-code size this way does limit the ability of out-of-order exec to see farther, if the front-end isn't the bottleneck. And it's highly unlikely to be worth saving/restoring two regs to enable this. (Or to push rdi / push rsi before call, then pop after!) Setting up the wrong value and then fixing it twice with OR is obviously terrible and never has any advantage, but the general idea to CSE large constants isn't totally crazy. (But it's profitable only in such limited cases that it might not be worth looking for, especially if it's only helpful at -Os)
