[Bug c/86719] New: case label does not reduce to an integer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86719
Bug ID: 86719
Summary: case label does not reduce to an integer constant
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 sample is as follow:
int main(void)
{
const int nFOO = 1;
int nFoo = 0;
switch(nFoo){
case nFOO:
exit(1);
}
exit(0);
}
gcc rejects the code:
gcc code1.c
code1.c: In function 'main':
code1.c:7:2: error: case label does not reduce to an integer constant
case nFOO:
^~~~
code1.c:8:2: warning: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
exit(1);
^~~~
code1.c:8:2: warning: incompatible implicit declaration of built-in function
'exit'
code1.c:8:2: note: include '' or provide a declaration of 'exit'
code1.c:1:1:
+#include
int main(void)
code1.c:8:2:
exit(1);
^~~~
code1.c:10:2: warning: incompatible implicit declaration of built-in function
'exit'
exit(0);
^~~~
code1.c:10:2: note: include '' or provide a declaration of 'exit'
The code looks legal. clang accepts it
[Bug c/86719] case label does not reduce to an integer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86719 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- So this is not valid C. constant expressions in C is different from C++ constant expressions. In C, const int variables are not constant expressions.
[Bug c/2534] const int variables in case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2534 Andrew Pinski changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #3 from Andrew Pinski --- *** Bug 86719 has been marked as a duplicate of this bug. ***
[Bug c/86719] case label does not reduce to an integer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86719 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 2534. *** This bug has been marked as a duplicate of bug 2534 ***
[Bug c/2534] const int variables in case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2534 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Andrew Pinski --- .
[Bug c/201] Switch statement will not accept constant integer variable as case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201 Andrew Pinski changed: What|Removed |Added CC||bug1 at optushome dot com.au --- Comment #4 from Andrew Pinski --- *** Bug 2534 has been marked as a duplicate of this bug. ***
[Bug c/2534] const int variables in case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2534 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 201. *** This bug has been marked as a duplicate of bug 201 ***
[Bug c/201] Switch statement will not accept constant integer variable as case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #3 from Andrew Pinski --- .
[Bug c/201] Switch statement will not accept constant integer variable as case label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=201 Andrew Pinski changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #5 from Andrew Pinski --- *** Bug 86719 has been marked as a duplicate of this bug. ***
[Bug c/86719] case label does not reduce to an integer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86719 --- Comment #3 from Andrew Pinski --- Actually bug 201. *** This bug has been marked as a duplicate of bug 201 ***
[Bug c/32040] Including a header file inside a function block results compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32040 --- Comment #3 from Andrew Pinski --- (In reply to Suma Sharma from comment #2) > (In reply to comment #1) > > This works as designed. > > > > > Thank you for your reply. > Please confirm whether it is expected behaviour (that means it is not a bug). > > But it was also observed that > 1. there is a difference in result when compiled with -O0 option(with all > -O2 flags enabled) and compiled with -O2 ? > 2. there is a difference in result when compiled with -O2 option(with all > -O2 flags disabled) and compiled with -O0 ? There is a define which is defined when using -O1 and above (__OPTIMIZED__), the GNU libc uses that define to define some inline function versions of the standard functions.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #25 from Xi Ruoyao --- This attribute should also apply to objects.
[Bug c/86720] New: Missing symbol name in directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86720
Bug ID: 86720
Summary: Missing symbol name in directive
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:
unsigned char foo (unsigned char x)
{
static volatile unsigned char P1OUT __asm ("0x0021");
unsigned char tmp = P1OUT;
P1OUT = x;
return tmp;
}
clang accepts the code. gcc rejects it with some strange messages:
gcc -c test.c
/tmp/ccOWvef3.s: Assembler messages:
/tmp/ccOWvef3.s:26: Error: Missing symbol name in directive
/tmp/ccOWvef3.s:26: Error: junk at end of line, first unrecognized character is
`0'
/tmp/ccOWvef3.s:27: Error: expected symbol name
Even if the code is illegal, please refine the error messages.
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 A. Wilcox (awilfox) changed: What|Removed |Added Known to fail||6.4.0 --- Comment #2 from A. Wilcox (awilfox) --- We applied the fix from PR78911 (rev 246059: https://code.foxkit.us/adelie/packages/blob/master/system/gcc/lra-pentium.patch is what we applied). We were running through a mass rebuild and just 52 minutes in, we've already tripped over this bug again, compiling the test suite for nettle-3.4: awilcox on ciall [pts/2 Sun 29 3:40] testsuite: gcc -I.. -I.. -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -DHAVE_CONFIG_H -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -g -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT ecc-mul-a-test.o -MD -MP -MF ecc-mul-a-test.o.d -c ecc-mul-a-test.c -fchecking -Q -save-temps Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (100%) wall 549 kB (98%) ggc TOTAL : 0.00 0.00 0.01 558 kB Extra diagnostic checks enabled; compiler may run slowly. realpath fgets fread fwrite vsnprintf vsprintf snprintf sprintf bcopy bzero memcpy memmove memset stpcpy stpncpy strcat strcpy strncat strncpy strlcat strlcpy __gmpz_abs __gmpz_fits_uint_p __gmpz_fits_ulong_p __gmpz_fits_ushort_p __gmpz_get_ui __gmpz_getlimbn __gmpz_neg __gmpz_perfect_square_p __gmpz_popcount __gmpz_set_q __gmpz_size __gmpq_abs __gmpq_neg __gmpn_add __gmpn_add_1 __gmpn_cmp __gmpn_zero_p __gmpn_sub __gmpn_sub_1 __gmpn_neg test_main Analyzing compilation unit Performing interprocedural optimizations <*free_lang_data> Assembling functions: test_main Attaching to process 20502 Reading symbols from /usr/libexec/gcc/i586-foxkit-linux-musl/6.4.0/cc1...(no debugging symbols found)...done. Reading symbols from /usr/lib/libisl.so.15...(no debugging symbols found)...done. Reading symbols from /usr/lib/libmpc.so.3...(no debugging symbols found)...done. Reading symbols from /usr/lib/libmpfr.so.4...(no debugging symbols found)...done. Reading symbols from /usr/lib/libgmp.so.10...(no debugging symbols found)...done. Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done. Reading symbols from /lib/ld-musl-i386.so.1...Reading symbols from /usr/lib/debug//lib/ld-musl-i386.so.1.debug...done. done. 0x084faee6 in lra_assign() () (gdb) bt #0 0x084faee6 in lra_assign() () #1 0x084f67f6 in lra(_IO_FILE*) () #2 0x084b1f97 in ?? () #3 0x08584ab4 in execute_one_pass(opt_pass*) () #4 0x08585068 in ?? () #5 0x08585078 in ?? () #6 0x085850da in execute_pass_list(function*, opt_pass*) () #7 0x082ebfe4 in cgraph_node::expand() () #8 0x082ed656 in ?? () #9 0x082ef189 in symbol_table::finalize_compilation_unit() () #10 0x086404fc in ?? () #11 0x081bd7f4 in toplev::main(int, char**) () #12 0x081bf8c8 in main ()
[Bug c/86721] New: use of undeclared identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86721
Bug ID: 86721
Summary: use of undeclared identifier
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 g() {
__builtin_printf(
u8R"abcd(%.)abcd"
"*d");
}
gcc accepts it, but clang rejects it:
code1.c:3:2: error: use of undeclared identifier 'u8R'
u8R"abcd(%.)abcd"
^
1 error generated.
This diagnostic seems to be right?
[Bug fortran/86704] Segmentation fault when using matmul in combination with transpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86704 --- Comment #3 from Stanislav Paláček --- Also tried with gcc-7.2.0 - no problem gcc-8.1.0,gcc-8-2-0 - this bug appeared
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 Andris Pavenis changed: What|Removed |Added CC||andris at gcc dot gnu.org --- Comment #12 from Andris Pavenis --- Did some testing with gcc-8.2.0 built as both native compiler for DJGPP and as Linux to DJGPP cross-compiler on Arch Linux (same build as one gets using https://aur.archlinux.org/packages/djgpp-gcc/) and new one with proposed patch applied additionally (added -msse to command line to avoid some unnecessary warnings) Arch Linux: 1) without proposed patch and -g (where n missing or greater than 1): lto-wrapper: vakava virhe: simple_object_copy_lto_debug_sections not implemented: Virheellinen argumentti 2) with -g0 (patch do not have any influence in this case) or with proposed patch applied: lto1: virhe: two or more sections for .gnu.lto__ZNSt8__detail16_Hashtable_allocISaINS_10_Hash_nodeISt4pairIKhN2jw2io3keyEELb0E21_M_deallocate_bucketsEPPNS_15_Hash_node_baseEm.e29cca957c80c524 (null):0: hämmentynyt aikaisemmista virheistä, poistutaan lto-wrapper: vakava virhe: i686-pc-msdosdjgpp-g++ returned 1 exit status DJGPP native compiler (only tested with patch applied): lto1.exe: error: two or more sections for .gnu.lto__ZNSt16allocator_traitsISaINSt8__detail10_Hash_nodeISt4pairIKhN2jw2io3keyEELb0E7destroyIS7_EEvRS9_PT_.e5d8ced6 (null):0: confused by earlier errors, bailing out lto-wrapper.exe: fatal error: C:\DJGPP\BIN/gpp.exe returned 1 exit status compilation terminated. collect2.exe: fatal error: lto-wrapper returned 1 exit status Compiling simple program did not work earlier for native compiler fir DJGPP target before when both -flto and -g where specified but works after proposed patch is applied. So we have 2 bugs and patch only fixes one of them.
[Bug fortran/86704] [8/9 Regression] Segmentation fault when using matmul in combination with transpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86704 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|WAITING |NEW CC||jvdelisle at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Known to work||7.3.0 Target Milestone|--- |8.3 Summary|Segmentation fault when |[8/9 Regression] |using matmul in combination |Segmentation fault when |with transpose |using matmul in combination ||with transpose Known to fail||8.2.0, 9.0 --- Comment #4 from Dominique d'Humieres --- I need an instrumented compiler to see the problem: ==61049==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200550 at pc 0x0001085550a0 bp 0x7ffee7c84ae0 sp 0x7ffee7c84ad8 WRITE of size 4 at 0x60200550 thread T0 #0 0x10855509f in matmul_r4_avx matmul_r4.c:381 #1 0x10857ba70 in _gfortran_matmul_r4 matmul_r4.c:2377 #2 0x107f7ad33 in testmatmul.3772 (a.out:x86_64+0x10d33) #3 0x107f7ade4 in MAIN__ (a.out:x86_64+0x10de4) #4 0x107f7ae4a in main (a.out:x86_64+0x10e4a) #5 0x7fff6de71014 in start (libdyld.dylib:x86_64+0x1014) Address 0x60200550 is a wild pointer. SUMMARY: AddressSanitizer: heap-buffer-overflow matmul_r4.c:381 in matmul_r4_avx I see this behavior for m=15.
[Bug c/86720] Missing symbol name in directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86720 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab --- The error message is coming from the assembler.
[Bug c++/86716] use of parameter outside function body before ‘++’ token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86716 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- No, this is not valid C++.
[Bug target/86722] New: ifcvt produces x&0 that is never cleaned up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86722
Bug ID: 86722
Summary: ifcvt produces x&0 that is never cleaned up
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(could be rtl-optimization or target)
void f(double*d,double*e){
for(;d
[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 #3 from Jason Merrill --- Created attachment 44460 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44460&action=edit fix
[Bug c++/86723] New: G++ not optimizing with bswap when inlining with constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86723 Bug ID: 86723 Summary: G++ not optimizing with bswap when inlining with constexpr Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kiwixz at outlook dot com Target Milestone: --- Created attachment 44461 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44461&action=edit souce.cpp Compiling attachment with `-std=c++17 -O3`, I expect g++ to optimize the swap_unsigned function to a bswap instruction. It does so, like for equivalent functions (not included here) for 32/16 bits swap. Unfortunately, if I add constexpr to the 64 bits swap_unsigned function, it gets inlined and no longer use bswap. Interestingely, using __attribute__((noinline)) will force g++ to use bswap.
[Bug tree-optimization/86723] not optimizing with bswap when casting to/from int to unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86723 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization URL|https://godbolt.org/g/qxLP8 | |r | Component|c++ |tree-optimization Summary|G++ not optimizing with |not optimizing with bswap |bswap when inlining with|when casting to/from int to |constexpr |unsigned long long Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- https://godbolt.org/g/qxLP8r
[Bug tree-optimization/86723] not optimizing with bswap, that casts to int aftwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86723 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-29 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug tree-optimization/86723] not optimizing with bswap, that casts to int aftwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86723
Andrew Pinski changed:
What|Removed |Added
Summary|not optimizing with bswap |not optimizing with bswap,
|when casting to/from int to |that casts to int aftwards
|unsigned long long |
--- Comment #2 from Andrew Pinski ---
Shorter testcase (which shows it is unrelated to inlining):
int swap_unsigned(unsigned long long value)
{
return ((value & 0x00ffull) << 56)
| ((value & 0xff00ull) << 40)
| ((value & 0x00ffull) << 24)
| ((value & 0xff00ull) << 8)
| ((value & 0x00ffull) >> 8)
| ((value & 0xff00ull) >> 24)
| ((value & 0x00ffull) >> 40)
| ((value & 0xff00ull) >> 56);
}
[Bug tree-optimization/86724] New: Compilation error with new isl 0.20 (missing includes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86724 Bug ID: 86724 Summary: Compilation error with new isl 0.20 (missing includes) Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rainer.jung at kippdata dot de Target Milestone: --- Compilation of 8.2.0 breaks in gcc/graphite-isl-ast-to-gimple.c .../graphite-isl-ast-to-gimple.c:83:7: error: 'isl_id_free' was not declared in this scope .../graphite-isl-ast-to-gimple.c:262:3: error: 'isl_id_free' was not declared in this scope .../graphite-isl-ast-to-gimple.c:598:5: error: 'isl_id_free' was not declared in this scope .../graphite-isl-ast-to-gimple.c:638:53: error: 'isl_id_get_user' was not declared in this scope .../graphite-isl-ast-to-gimple.c:641:7: error: 'isl_id_free' was not declared in this scope .../graphite-isl-ast-to-gimple.c:802:31: error: 'isl_id_get_user' was not declared in this scope .../graphite-isl-ast-to-gimple.c:808:3: error: 'isl_id_free' was not declared in this scope .../graphite-isl-ast-to-gimple.c:1367:19: error: 'isl_space_dim' was not declared in this scope .../graphite-isl-ast-to-gimple.c:1371:3: error: 'isl_space_free' was not declared in this scope .../graphite-isl-ast-to-gimple.c:1372:16: error: 'isl_id_alloc' was not declared in this scope In isl 0.19, other isl header files already included by gcc/graphite.h included the isl header file id.h and space.h. In 0.20 this is no longer the case. Proposed patch: --- .../gcc/graphite.h 2018-01-03 11:03:58.0 + +++ .../gcc/graphite.h 2018-07-29 17:42:55.836121000 + @@ -37,6 +37,8 @@ #include #include #include +#include +#include typedef struct poly_dr *poly_dr_p; Regards, Rainer
[Bug tree-optimization/86724] Compilation error with new isl 0.20 (missing includes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86724 --- Comment #1 from Rainer Jung --- For the sake of completeness, I think the following isl change removed the implicit include chain that made the code work before isl 0.20: http://repo.or.cz/isl.git/commitdiff/406f2e9e067adb901c45284c65bfdc32e29a1383 Before several already included isl header files included isl/local_space.h which itself included the needed isl/space.h which in turn included the needed isl/id.h. After the change, isl/local_space.h no longer includes space.h.
[Bug c/86617] [6/7/8 Regression] Volatile qualifier is ignored sometimes for unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86617 --- Comment #9 from Bernd Edlinger --- Author: edlinger Date: Sun Jul 29 16:44:24 2018 New Revision: 263055 URL: https://gcc.gnu.org/viewcvs?rev=263055&root=gcc&view=rev Log: gcc: 2018-07-29 Bernd Edlinger Backport from mainline 2018-07-23 Bernd Edlinger PR c/86617 * genmatch.c (dt_operand::gen_match_op): Avoid folding volatile values. testsuite: 2018-07-29 Bernd Edlinger Backport from mainline 2018-07-23 Bernd Edlinger PR c/86617 * gcc.dg/pr86617.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr86617.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/genmatch.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug debug/86687] Wrong debug information for string types passed as parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687
--- Comment #6 from Tom de Vries ---
Not sure yet whether this is the desired fix, but using this patch:
...
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index bd45e0b0685..fbbbe9f2d2a 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -22162,6 +22162,8 @@ gen_formal_parameter_die (tree node, tree origin, bool
emit_name_p,
else if (emit_name_p)
add_name_and_src_coords_attributes (parm_die, node);
if (origin == NULL
+ || (!decl_by_reference_p (node)
+ && decl_by_reference_p (origin))
|| (! DECL_ABSTRACT_P (node_or_origin)
&& variably_modified_type_p (TREE_TYPE (node_or_origin),
decl_function_context
...
I get:
...
> ./install/bin/gdb ./a.out -batch -ex "b foo::foo" -ex "r" -ex "what dir_hint"
> -ex "info addr dir_hint" -ex "p dir_hint" -ex "p dir_hint.c_str()" -ex c
Breakpoint 1 at 0x4012ee: file bla.C, line 9.
Breakpoint 1, foo::foo (this=0x7fffdb3f, dir_hint=...) at bla.C:9
9 std::cout << dir_hint << "\n";
type = std::__cxx11::string & restrict
Symbol "dir_hint" is a complex DWARF expression:
0: DW_OP_fbreg -32
.
$1 = (std::__cxx11::string & restrict) @0x7fffdb70: {static npos =
18446744073709551615, _M_dataplus = {> =
{<__gnu_cxx::new_allocator> = {}, }, _M_p
= 0x416e90 "This is just a string"}, _M_string_length = 21, {_M_local_buf =
"\025\000\000\000\000\000\000\000\360\020@\000\000\000\000",
_M_allocated_capacity = 21}}
$2 = 0x416e90 "This is just a string"
This is just a string
[Inferior 1 (process 6355) exited normally]
...
[Bug tree-optimization/86725] New: ICE: Segmentation fault (in vect_get_vec_def_for_operand_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86725
Bug ID: 86725
Summary: ICE: Segmentation fault (in
vect_get_vec_def_for_operand_1)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20180722 snapshot (r262923), 8.1, 7.3, 6.3, 5.4, 4.9.4 all ICE
when compiling the following snippet w/ -O1 -ftree-loop-vectorize
-fno-tree-scev-cprop:
int
nr (int xe)
{
int oo, wo = 0;
for (oo = 0; oo < 4; ++oo)
{
int qq;
for (qq = 0; qq < 2; ++qq)
{
wo += 0x8000;
xe += wo;
}
}
return xe;
}
% gcc-9.0.0-alpha20180722 -O1 -ftree-loop-vectorize -fno-tree-scev-cprop -c
nglfihdk.c
during GIMPLE pass: vect
nglfihdk.c: In function 'nr':
nglfihdk.c:2:1: internal compiler error: Segmentation fault
nr (int xe)
^~
0xc967cf crash_signal
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/toplev.c:325
0xeb1a8b vect_get_vec_def_for_operand_1(gimple*, vect_def_type)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vect-stmts.c:1524
0xeb5b0d vect_get_vec_def_for_operand(tree_node*, gimple*, tree_node*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vect-stmts.c:1591
0xed75fb vectorizable_induction(gimple*, gimple_stmt_iterator*, gimple**,
_slp_tree*, vec*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vect-loop.c:7650
0xecf61a vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vect-stmts.c:9634
0xeded4b vect_transform_loop(_loop_vec_info*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vect-loop.c:8545
0xf02a4d try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vectorizer.c:783
0xf03529 vectorize_loops()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180722/work/gcc-9-20180722/gcc/tree-vectorizer.c:917
[Bug rtl-optimization/66420] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66420 --- Comment #5 from David Binderman --- Still wrong more than two years later ==15752== Conditional jump or move depends on uninitialised value(s) ==15752==at 0x9CF7DC: improve_allocation() (in /home/dcb/gcc/working/gcc/cc1) ==15752==by 0x9D59F3: color_pass(ira_loop_tree_node*) (in /home/dcb/gcc/working/gcc/cc1) ==15752==by 0x9A92D6: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (in /home/dcb/gcc/working/gcc/cc1) ==15752==by 0x9CBBDA: ira_color() (in /home/dcb/gcc/working/gcc/cc1)
[Bug other/86726] New: Undocumented option -f{,no}-tree-scev-cprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86726
Bug ID: 86726
Summary: Undocumented option -f{,no}-tree-scev-cprop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
The -f{,no}-tree-scev-cprop option was apparently introduced during the
development of the 4.3 branch. However, it still seems to be undocumented in
the user's manual as of the current top of trunk.
[Bug fortran/84674] [7/8/9 Regression] Derived type name change makes a program segfault, removing non_overridable helps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84674
--- Comment #3 from Jakub Benda ---
Bisection points to revision 254427 from 5 November 2017, which adds this chunk
of code to "fortran/resolv.c" (function "resolve_fl_derived", lines
14081-14093):
/* Generate module vtables subject to their accessibility and their not
being vtables or pdt templates. If this is not done class declarations
in external procedures wind up with their own version and so SELECT TYPE
fails because the vptrs do not have the same address. */
if (gfc_option.allow_std & GFC_STD_F2003
&& sym->ns->proc_name
&& sym->ns->proc_name->attr.flavor == FL_MODULE
&& sym->attr.access != ACCESS_PRIVATE
&& !(sym->attr.use_assoc || sym->attr.vtype || sym->attr.pdt_template))
{
gfc_symbol *vtab = gfc_find_derived_vtab (sym);
gfc_set_sym_referenced (vtab);
}
When I comment it out, the compiled program works as expected.
[Bug rtl-optimization/66420] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66420 --- Comment #6 from David Binderman --- More detail: ==11707== Conditional jump or move depends on uninitialised value(s) ==11707==at 0x8C3209: improve_allocation() (ira-color.c:2878) ==11707==by 0x8C734C: color_allocnos (ira-color.c:3201) ==11707==by 0x8C734C: color_pass(ira_loop_tree_node*) (ira-color.c:3310) ==11707==by 0x8B07D6: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1781) ==11707==by 0x8C0E02: do_coloring (ira-color.c:3461) Merely -O2 will cause the problem. -O3 -march=native not required.
[Bug c/86727] New: Struct argument in xmm0 register instead of rcx on Win64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86727 Bug ID: 86727 Summary: Struct argument in xmm0 register instead of rcx on Win64 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bart at bartjanssens dot org Target Milestone: --- Created attachment 44462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44462&action=edit Test case When passing a struct containing a single value of type double, the argument is fetched from the %xmm0 register, where the %rcx register should actually be used on 64 bit Windows. Both mingw GCC 6.4.0 and 8.2.0 read the argument like this: movsd %xmm0, 16(%rbp) Clang and MSVC both read correctly from %rcx. Attached is a self-contained example, assembly dumped with x86_64-w64-mingw32-gcc -S -o - -x c test.c shows the problem. More discussion is also at: https://github.com/JuliaLang/julia/issues/28325 When changing the field type to e.g. int or when adding extra fields to the struct the problem goes away.
[Bug target/86727] Struct argument in xmm0 register instead of rcx on Win64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86727 --- Comment #1 from Andrew Pinski --- I think this is a dup of bug 64243.
[Bug middle-end/86711] [9 Regression] wrong folding of memchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86711 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-29 CC||msebor at gcc dot gnu.org Version|8.0 |9.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86688 Summary|wrong folding of memchr |[9 Regression] wrong ||folding of memchr Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. This is another manifestation of bug 86688 introduced by r263018.
[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86714 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Version|8.0 |9.0 Resolution|--- |INVALID --- Comment #1 from Martin Sebor --- As explained in the response on the post, initializing char[3] with "1234" is undefined because of excess elements.
[Bug fortran/34705] Reuse I/O structures to save memory and help the ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34705 --- Comment #2 from Jürgen Reuter --- Is this still an open issue? 10 years gone by now.
[Bug c++/86728] New: [Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86728
Bug ID: 86728
Summary: [Regression] unexpected error: conversion from
', ...)>' to non-scalar type
'std::function' requested
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 ***/
#include
std::function a = [](int x ...) { }; // OK
std::function b = [](auto x, ...) { }; // OK
std::function c = [](auto x ...) { }; /* error: conversion from
', ...)>' to non-scalar type 'std::function'
requested */
/ END SOURCE /
The error in the last line appears with build 9.0.0 20180728 (experimental),
8.2, 8.1. This code used to compile successfully with GCC versions 6.1 - 7.3.
For comparison, the latest versions of clang and MSVC compile this code
successfully as well.
[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52869
denin at mail dot ru changed:
What|Removed |Added
CC||denin at mail dot ru
--- Comment #6 from denin at mail dot ru ---
Reproduced in 8.1.1:
$ cat nyan.cpp
struct Nyan {
constexpr Nyan &operator++() noexcept { return *this; }
constexpr void omg() noexcept(noexcept(++*this)) {}
};
int main() {}
$ g++ -Wall -Wextra nyan.cpp
nyan.cpp:3:44: error: invalid use of ‘this’ at top level
constexpr void omg() noexcept(noexcept(++*this)) {}
^~~~
$ clang++ nyan.cpp
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.1 20180531 (GCC)
$ uname -a
Linux home 4.17.10-1-ARCH #1 SMP PREEMPT Wed Jul 25 11:23:00 UTC 2018 x86_64
GNU/Linux
[Bug c/79010] -Wlarger-than ineffective for VLAs, alloca, malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79010 --- Comment #2 from Eric Gallager --- Haven't you been touching stuff in this area lately, Martin?
[Bug c/78989] Missing -Waddress warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989 --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > I suspect PR 77513 can be considered the dup. As in, that's the dup of this, or this is the dup of that?
[Bug c/52952] Wformat location info is bad (wrong column number)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #50 from Eric Gallager --- (In reply to Bernd Edlinger from comment #49) > Author: edlinger > Date: Mon Aug 22 07:34:34 2016 > New Revision: 239649 > > URL: https://gcc.gnu.org/viewcvs?rev=239649&root=gcc&view=rev > Log: > 2016-08-22 Bernd Edlinger > > PR c/52952 > * gcc.dg/cpp/pr66415-1.c: Fix sporadic failure. > > Modified: > trunk/gcc/testsuite/ChangeLog > trunk/gcc/testsuite/gcc.dg/cpp/pr66415-1.c ...so is it fixed yet?
[Bug middle-end/84823] [6 Regression] x86 LRA hang on valid code (no ICE) with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84823 --- Comment #3 from A. Wilcox (awilfox) --- Tried disabling every single optimisation that was enabled by default in sequence, yielding the following results: % for i in $(cat gcc-options); do timeout 10 gcc -I.. -I.. -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -DHAVE_CONFIG_H -O2 -ggdb -march=pentium-mmx -mtune=pentium-m -fno-omit-frame-pointer -g -g -ggdb3 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes -Wpointer-arith -Wbad-function-cast -Wnested-externs -MT ecc-mul-a-test.o -MD -MP -MF ecc-mul-a-test.o.d -c ecc-mul-a-test.c $i && printf "$i fixed it\n"; done -fno-guess-branch-probability fixed it -fno-inline fixed it -fno-tree-ter fixed it I don't know if this helps any or not.
[Bug middle-end/86714] tree-ssa-forwprop.c confused by too long initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86714 --- Comment #2 from Bernd Edlinger --- You must have overlooked this response from Jakub: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01238.html "If we just warn about the initializer and treat it some way, an optimization should not change how the initializer is treated. The memcpy and memset themselves must be valid and they should just copy whatever is in the initializer without optimizations."
[Bug target/86651] [8/9 Regression] lto-wrapper.exe: fatal error: simple_object_copy_lto_debug_sections not implemented: Invalid argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 --- Comment #13 from rguenther at suse dot de --- On Sun, 29 Jul 2018, andris at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86651 > > Andris Pavenis changed: > >What|Removed |Added > > CC||andris at gcc dot gnu.org > > --- Comment #12 from Andris Pavenis --- > Did some testing with gcc-8.2.0 built as both native compiler for DJGPP and as > Linux to DJGPP cross-compiler on Arch Linux (same build as one gets using > https://aur.archlinux.org/packages/djgpp-gcc/) and new one with proposed patch > applied additionally (added -msse to command line to avoid some unnecessary > warnings) > > Arch Linux: > > 1) without proposed patch and -g (where n missing or greater than 1): > lto-wrapper: vakava virhe: simple_object_copy_lto_debug_sections not > implemented: Virheellinen argumentti > > 2) with -g0 (patch do not have any influence in this case) or with proposed > patch applied: > lto1: virhe: two or more sections for > .gnu.lto__ZNSt8__detail16_Hashtable_allocISaINS_10_Hash_nodeISt4pairIKhN2jw2io3keyEELb0E21_M_deallocate_bucketsEPPNS_15_Hash_node_baseEm.e29cca957c80c524 > (null):0: hämmentynyt aikaisemmista virheistä, poistutaan > lto-wrapper: vakava virhe: i686-pc-msdosdjgpp-g++ returned 1 exit status That looks like an unrelated bug to me. > DJGPP native compiler (only tested with patch applied): > lto1.exe: error: two or more sections for > .gnu.lto__ZNSt16allocator_traitsISaINSt8__detail10_Hash_nodeISt4pairIKhN2jw2io3keyEELb0E7destroyIS7_EEvRS9_PT_.e5d8ced6 > (null):0: confused by earlier errors, bailing out > lto-wrapper.exe: fatal error: C:\DJGPP\BIN/gpp.exe returned 1 exit status > compilation terminated. > collect2.exe: fatal error: lto-wrapper returned 1 exit status > > Compiling simple program did not work earlier for native compiler fir DJGPP > target before when both -flto and -g where specified but works after proposed > patch is applied. > > So we have 2 bugs and patch only fixes one of them. Yes, let's track the other bug in another PR.
