[Bug c++/62153] warn for bool expression compared with integer different from 0/1

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62153

--- Comment #8 from Franz Sirl sirl at gcc dot gnu.org ---
Hmm, what about the assignment part of the merged bug 44077:

 _Bool var = 3;

Does the fix warn about this? Should I create a new bug report for this part?

[Bug tree-optimization/64034] New: [5 regression] cc1 stack-overflow with -O2 -fsanitize=undefined

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64034

Bug ID: 64034
   Summary: [5 regression] cc1 stack-overflow with -O2
-fsanitize=undefined
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org

Created attachment 34080
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34080action=edit
testcase to reproduce the bug

The attached testcase segfaults (valgrind says stack-overflow) when compiled
for x86_64 with -O2 -fsanitize=undefined. gcc-4.9.2 compiles the testcase
without problems.

gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00bf990c in copygeneric_wide_intwide_int_storage,
generic_wide_intwide_int_ref_storagefalse   (y=..., x=...) at
../../gcc/wide-int.h:1660
1660xval[i] = yval[i];
(gdb) bt
#0  0x00bf990c in copygeneric_wide_intwide_int_storage,
generic_wide_intwide_int_ref_storagefalse   (y=..., x=...) at
../../gcc/wide-int.h:1660
#1  zextgeneric_wide_intwide_int_ref_storagefalse   (offset=1023, x=...)
at ../../gcc/wide-int.h:2067
#2  wi::fits_to_tree_pgeneric_wide_intwide_int_ref_storagefalse   (x=...,
type=type@entry=0x76931d20) at ../../gcc/tree.h:4760
#3  0x00bec36f in force_fit_type (type=0x76931d20, cst=...,
overflowable=1, overflowed=optimized out) at ../../gcc/tree.c:1237
#4  0x006c2dbf in fold_negate_const (arg0=arg0@entry=0x7695c4f8,
type=type@entry=0x76931d20) at ../../gcc/fold-const.c:15423
#5  0x006f76eb in fold_negate_expr (loc=loc@entry=0,
t=t@entry=0x7695c4f8) at ../../gcc/fold-const.c:555
#6  0x006f8d28 in negate_expr (t=0x7695c4f8) at
../../gcc/fold-const.c:775
#7  0x006da1bc in fold_binary_loc (loc=loc@entry=0,
code=code@entry=MINUS_EXPR, type=type@entry=0x76931d20,
op0=op0@entry=0x7624d8c0, op1=op1@entry=0x7695c4f8)
at ../../gcc/fold-const.c:10450
#8  0x006eaafb in fold_build2_stat_loc (loc=0, code=MINUS_EXPR,
type=0x76931d20, op0=0x7624d8c0, op1=0x7695c4f8) at
../../gcc/fold-const.c:14231
#9  0x007786a9 in generic_simplify (loc=0, code=optimized out,
type=0x76931d20, op0=0x7624d8a0, op1=optimized out) at
generic-match.c:3194
#10 0x006d6852 in fold_binary_loc (loc=loc@entry=0,
code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20,
op0=op0@entry=0x7624d8a0, op1=op1@entry=0x7624d880)
at ../../gcc/fold-const.c:9729
#11 0x006eaafb in fold_build2_stat_loc (loc=loc@entry=0,
code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20, op0=0x7624d8a0,
op1=op1@entry=0x7624d880)
at ../../gcc/fold-const.c:14231
#12 0x006da203 in fold_binary_loc (loc=loc@entry=0,
code=code@entry=MINUS_EXPR, type=type@entry=0x76931d20,
op0=op0@entry=0x7624d860, op1=op1@entry=0x7695c4f8)
at ../../gcc/fold-const.c:10450
#13 0x006eaafb in fold_build2_stat_loc (loc=0, code=MINUS_EXPR,
type=0x76931d20, op0=0x7624d860, op1=0x7695c4f8) at
../../gcc/fold-const.c:14231
#14 0x007786a9 in generic_simplify (loc=0, code=optimized out,
type=0x76931d20, op0=0x7624d840, op1=optimized out) at
generic-match.c:3194
#15 0x006d6852 in fold_binary_loc (loc=loc@entry=0,
code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20,
op0=op0@entry=0x7624d840, op1=op1@entry=0x7624d820)
at ../../gcc/fold-const.c:9729
#16 0x006eaafb in fold_build2_stat_loc (loc=loc@entry=0,
code=code@entry=PLUS_EXPR, type=type@entry=0x76931d20, op0=0x7624d840,
op1=op1@entry=0x7624d820)
at ../../gcc/fold-const.c:14231
... a lot similar frames follow, seems like a folding recursion.

$ gcc-5 -v
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran --with-gxx-include-dir=/usr/include/c++/5
--enable-ssp --disable-libssp --disable-libvtv --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-5 --without-system-libunwind
--enable-multilib --with-arch-32=i586 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.0.0 20141118 (experimental) [trunk revision 217715] (SUSE Linux)


Might be related to bug 63879, but the backtrace looks totally different.

[Bug sanitizer/64906] New: -fsanitize=integer-divide-by-zero creates false -Wmaybe-uninitialized warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64906

Bug ID: 64906
   Summary: -fsanitize=integer-divide-by-zero creates false
-Wmaybe-uninitialized warning
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

This testcase produces a false warning when compiled with -O2
-fsanitize=integer-divide-by-zero -Wmaybe-uninitialized:

struct s {
__SIZE_TYPE__ size;
unsigned int flags;
};

int testf(struct s * source)
{
__SIZE_TYPE__ msize = 0;
if ((source-flags  88) ? (__SIZE_TYPE__) 43 * 8 : 0)
msize = source-size / ((source-flags  88) ? (__SIZE_TYPE__) 43 * 8:
0);
return msize;
}

test.c: In function 'testf':
test.c:11:8: warning: 'iftmp.1' may be used uninitialized in this function
[-Wmaybe-uninitialized]
  msize = source-size / ((source-flags  88) ? (__SIZE_TYPE__) 43 * 8: 0);
^

[Bug lto/64860] New: multiple definition of typeinfo in 5.0 (4.9.2 works)

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860

Bug ID: 64860
   Summary: multiple definition of typeinfo in 5.0 (4.9.2 works)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org

Created attachment 34617
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34617action=edit
Simple testcase. Use make to reproduce.

While trying to construct a testcase for a 4.8 to 4.9 change of LTO linking
behaviour, I stumbled over this (just re-tested with r220248):

g++-5 -flto -fuse-linker-plugin -O2 -Wall -Wextra -c file1.cpp
g++-5 -flto -fuse-linker-plugin -O2 -Wall -Wextra -c file2.cpp
gcc-5  -flto -fuse-linker-plugin -Wl,-r -nostdlib -o lib1.lib file1.o
gcc-5  -flto -fuse-linker-plugin -Wl,-r -nostdlib -o lib2.lib file2.o
g++-5 -flto -fuse-linker-plugin -O2 -o testexe lib1.lib lib2.lib
lib2.lib:(.rodata+0x0): multiple definition of `typeinfo name for CDialogBase'
lib1.lib:(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status

# g++-5 -v
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,fortran --with-gxx-include-dir=/usr/include/c++/5
--enable-ssp --disable-libssp --disable-libvtv --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=c++98 --enable-version-specific-runtime-libs
--enable-linker-build-id --enable-linux-futex --program-suffix=-5
--without-system-libunwind --enable-multilib --with-arch-32=i586
--with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 5.0.0 20150129 (experimental) (SUSE Linux)

gcc-4.8.3 and 4.9.2 compile and link the same code just fine.

[Bug sanitizer/65769] New: [UBSAN] qt-4.6 and qt-4.7 applications using qobject_cast may crash

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65769

Bug ID: 65769
   Summary: [UBSAN] qt-4.6 and qt-4.7 applications using
qobject_cast may crash
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

This is actually a bug in the qt headers, which contains this undefined
construct:

template class T
inline T qobject_cast(QObject *object)
{
#if !defined(QT_NO_MEMBER_TEMPLATES)  !defined(QT_NO_QOBJECT_CHECK)
   
reinterpret_castT(0)-qt_check_for_QOBJECT_macro(*reinterpret_castT(object));
#endif
return
static_castT(reinterpret_castT(0)-staticMetaObject.cast(object));
}

Here UBSAN lets the application crash like this:
/usr/include/QtCore/qobject.h:453:5: runtime error: member access within null
pointer of type 'struct QObject'   
Segmentation fault  
What happens is that UBSAN creates 2 checks here (from gimple dump of
demos/undo/mainwindow.cpp):

  UBSAN_NULL (0B, 4B, 8);
  D.90545 = 0B;
  D.90546 = D.90545-_vptr.QObject;
  D.90547 = (long unsigned int) D.90546;
  UBSAN_VPTR (0B, D.90547, 3589049094360264299, _ZTI8Document, 4B);

Naturally D.90546 = D.90545-_vptr.QObject leads to a NULL dereference.

3 workarounds are possible:
1. compile your qt code with -DQT_NO_QOBJECT_CHECK

2. change the affected header like this (maybe best for LTS distros like SLES11
or RHEL6):

template class T
inline T qobject_cast(QObject *object)
{
#if !defined(QT_NO_MEMBER_TEMPLATES)  !defined(QT_NO_QOBJECT_CHECK)
   
reinterpret_castT(object)-qt_check_for_QOBJECT_macro(*reinterpret_castT(object));
#endif
return
static_castT(reinterpret_castT(object)-staticMetaObject.cast(object));
}

There are more occurrences in the header, but I didn't check them all. Use the
fixed qt-4.8 qobject.h as a reference.

3. Change to qt = 4.8 which fixed this header.

If someone thinks it might be worth (from a QOI POV that instrumentation
shouldn't influence user code like that) changing UBSAN to skip the UBSAN_VPTR
check in case the UBSAN_NULL already reported the NULL, keep the bug open.
Otherwise it can be closed as INVALID.

[Bug c/66220] New: -Wmisleading-indentation false/inconsistent warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220

Bug ID: 66220
   Summary: -Wmisleading-indentation false/inconsistent warning
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35578
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35578action=edit
Testcase to reproduce

The following indenting style generates a false warning:

int test1(int v)
{
int res = 28;

if (v == 2)
{
res = 27;
} else
{
res = 18;
}
return res;
}

test-indent.c: In function 'test1':
test-indent.c:13:5: warning: statement is indented as if it were guarded by...
[-Wmisleading-indentation]
 return res;
  ^
test-indent.c:9:7: note: ...this 'else' clause, but it is not
 } else
^

Even though I don't like this style, I don't think it's misleading.
If you change the 'else' to 'else if ()' the warning goes away, that's why
think it's at least inconsistent.

[Bug c/66397] New: sanitize=undefined triggers extra -Warray-bounds warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66397

Bug ID: 66397
   Summary: sanitize=undefined triggers extra -Warray-bounds
warning
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 35691
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35691action=edit
testcase, warns with gcc-6 -c -O2 -fsanitize=undefined

The attached testcase derived from a C++ iterator implementation relies on the
fact that the undefined pCurrent-1 is immediately nullified again by the
following pCurrent++ by the optimizer. But in current trunk r224064 the
following warning is issued:

test.c: In function 'test':
test.c:19:53: warning: array subscript is below array bounds [-Warray-bounds]
 ths-pCurrent = (ths-pStart) ? ths-pStart - 1 : (stru *) 0;
 ^

Though the warning is not completely wrong, -Warray-bounds usually triggers
only when the value is really accessed, or? gcc-5.1 compiles the testcase
without warning.

[Bug c/66397] sanitize=undefined triggers extra -Warray-bounds warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66397

--- Comment #3 from Franz Sirl sirl at gcc dot gnu.org ---
Yeah, I feared so :-(. This is a bit unfortunate though, as for our code base
we compile with -Werror=array-bounds, now when I add -fsanitize=undefined I
need to downgrade the error to a warning again. Another special casing in the
build system... From this POV I would prefer to get only the
-fsanitize=undefined runtime error.

[Bug c/66220] -Wmisleading-indentation false/inconsistent warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66220

--- Comment #4 from Franz Sirl sirl at gcc dot gnu.org ---
Patch from #c3 works fine for our codebase, I couldn't spot any false positives
anymore.

[Bug c/66869] New: [6 regression] -Wunused-function no longer warns for static declarations without definition

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66869

Bug ID: 66869
   Summary: [6 regression] -Wunused-function no longer warns for
static declarations without definition
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Up to gcc-5.1.1 r225711 -Wunused-functions warns like that:

 echo 'static void test(void);' | LANG=C gcc-5 -c -Wunused-function -x c -
stdin:1:13: warning: 'test' declared 'static' but never defined
[-Wunused-function]


But gcc-6.0.0 r225711 remains silent:

 echo 'static void test(void);' | LANG=C gcc-6 -c -Wunused-function -x c -


BTW, maybe it would make sense to split out this part from -Wunused-function
into a separate -Wstatic-decl-without-def. That's because likely more people
would like to turn this part of the warning into an error instead of all of
-Wunused-function.

[Bug c/68845] New: -Werror=array-bounds=[12] doesn't turn warning into error

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68845

Bug ID: 68845
   Summary: -Werror=array-bounds=[12] doesn't turn warning into
error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

With trunk gcc r231490, for a simple out of bounds access like

int arr[3];

int f(void)
{
return arr[5];
}

-Werror=array-bounds=[12] don't turn the warning into an error:

# gcc-6 -c -O2 -Werror=array-bounds=2 test.c
test.c: In function 'f':
test.c:6:15: warning: array subscript is above array bounds [-Warray-bounds]
 return arr[5];
~~~^~~


gcc-5.3.0 behaves the same way, so this is likely no regression.

[Bug c/68833] [6 Regression] -Werror=format issues an error now

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68833

--- Comment #4 from Franz Sirl  ---
The fix in Comment 3 works fine for me. No testsuite regressions and also the
application where I spotted this compiles/warns as expected now.

[Bug c/68845] -Werror=array-bounds=[12] doesn't turn warning into error

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68845

--- Comment #3 from Franz Sirl  ---
Created attachment 37035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37035=edit
Alias -Warray-bounds to Warray-bounds=

Tentative patch, no regressions. Please commit if OK, I don't have valid
credentials anymore.

[Bug c/68833] New: -Werror=format issues an error now

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68833

Bug ID: 68833
   Summary: -Werror=format issues an error now
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This little example issues an error now on trunk r231490:

# gcc -c -Werror=format -x c - 

[Bug lto/69003] Undefined reference with gcc -r incremental linking

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69003

--- Comment #2 from Franz Sirl  ---
Only gcc-4.8 works (4.8.3 20140627 [gcc-4_8-branch revision 212064]), gcc-4.9
onwards all show the same behaviour.

[Bug lto/69003] New: Undefined reference with gcc -r incremental linking

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69003

Bug ID: 69003
   Summary: Undefined reference with gcc -r incremental linking
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37096
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37096=edit
Testcase, use 'gmake all'.

The attached testcase doesn't link with gcc-6 r231874 on x86_64-linux-gnu:

gcc-6 -flto -fuse-linker-plugin -O2 -fno-common -Wall -Wextra -c file1.c
gcc-6 -flto -fuse-linker-plugin -O2 -fno-common -Wall -Wextra -c file2.c
file3.c
gcc-6 -flto -fuse-linker-plugin -O2 -fno-common -Wall -Wextra -DSTATICMODE -c
file3.c -o file3s.o
g++-6 -flto -fuse-linker-plugin  -r -nostdlib -o lib1.lib file1.o file3.o
g++-6 -flto -fuse-linker-plugin  -r -nostdlib -o lib2.lib file2.o file3s.o
g++-6 -flto -fuse-linker-plugin  -O2 -o testexe lib1.lib lib2.lib
lib2.lib: In function `t1':
(.text+0x23): undefined reference to `mode.lto_priv.0'
collect2: error: ld returned 1 exit status

The testcase links fine without LTO.

[Bug c/68412] New: ICE with -Wall -Wextra in fold_binary_loc()

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68412

Bug ID: 68412
   Summary: ICE with -Wall -Wextra in fold_binary_loc()
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

With x86_64 gcc-6 r230524 (r230119 was still OK) compiling this little fragment
with -Wall -Wextra:

int testwarn(int *pCnShifted)
{
int cnShifted = *pCnShifted;
_Bool isNullSource = (cnShifted == ((-1) << (8)));

if (!isNullSource)
return 0;
else
return 1;
}

I see this ICE:

test.c: In function 'testwarn':
test.c:6:46: warning: left shift of negative value [-Wshift-negative-value]
 _Bool isNullSource = (cnShifted == ((-1) << (8)));
  ^~

test.c:6:5: internal compiler error: in fold_binary_loc, at fold-const.c:9085
 _Bool isNullSource = (cnShifted == ((-1) << (8)));
 ^

0x61056e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9082
0x6214d4 fold(tree_node*)
../../gcc/fold-const.c:11974
0x48ee10 warn_tautological_cmp(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/c-family/c-common.c:1927
0x454cb6 parser_build_binary_op(unsigned int, tree_code, c_expr, c_expr)
../../gcc/c/c-typeck.c:3528
0x470c08 c_parser_binary_expression
../../gcc/c/c-parser.c:6544
0x471075 c_parser_conditional_expression
../../gcc/c/c-parser.c:6187
0x471570 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6104
0x471a92 c_parser_expression
../../gcc/c/c-parser.c:8250
0x46ce4f c_parser_postfix_expression
../../gcc/c/c-parser.c:7412
0x46f45a c_parser_unary_expression
../../gcc/c/c-parser.c:6774
0x470137 c_parser_cast_expression
../../gcc/c/c-parser.c:6607
0x470355 c_parser_binary_expression
../../gcc/c/c-parser.c:6416
0x471075 c_parser_conditional_expression
../../gcc/c/c-parser.c:6187
0x471570 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6104
0x47fd5a c_parser_initializer
../../gcc/c/c-parser.c:4225
0x4690fc c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:1850
0x46c8cb c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4688
0x480fce c_parser_compound_statement
../../gcc/c/c-parser.c:4599
0x469a41 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2017
0x48460d c_parser_external_declaration
../../gcc/c/c-parser.c:1461

[Bug c++/69237] [6 Regression] strange -Wmisleading-indentation warning when building Chromium

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69237

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #2 from Franz Sirl  ---
Or the '--fcount;'. Does the warning go away if you add braces like that:

   void pop(T* elem) { SkASSERT(fCount > 0); if (elem) { *elem =
(*this)[fCount - 1]; } --fCount; }

Or add the closing brace after the '--fCount;' in case that's the correct code
behaviour. I believe the warning is justified here.

[Bug c++/69237] [6 Regression] strange -Wmisleading-indentation warning when building Chromium

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69237

--- Comment #4 from Franz Sirl  ---
For me, yes. Because as a reader knowing nothing about the code and looking for
some kind of "bug" in the code, I cannot decide easily if the _intention_ was

  if (elem)
{
  *elem = (*this)[fCount - 1];
}
  --fCount;

or:

  if (elem)
{
  *elem = (*this)[fCount - 1];
  --fCount;
}

In my understanding that matches the "misleading" in -Wmisleading-indentation.

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847

--- Comment #9 from Franz Sirl  ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 38636 [details]
> gcc7-pr70847.patch
> 
> Untested fix.

Applied to gcc-6-branch r237059, no testsuite regressions. Testcase from
comment 6 and original codebase back to normal compile times.

[Bug c++/71393] [6.1 Regression] Compilation hang

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71393

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #2 from Franz Sirl  ---
Looks like a duplicate of bug 70847 or bug 71330?

[Bug c++/70847] [6/7 Regression] exponential time in cp_fold for chained virtual function calls

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #6 from Franz Sirl  ---
Created attachment 38612
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38612=edit
Testcase for -fsanitize=alignment

For this testcase compiled with -fsanitize=alignment/-fsanitize=undefined the
patch from comment#3 only shaves off about 4 seconds. The compiletime still
roughly doubles with each string added to the operator<< chain.

1)
time g++-6 -fsanitize=alignment tc3.cpp -c -ftime-report

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1575 kB (54%) ggc
 phase parsing   : 143.08 (100%) usr   0.00 ( 0%) sys 143.09 (100%)
wall 756 kB (26%) ggc
 phase opt and generate  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
   597 kB (20%) ggc
 register information:   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 parser function body: 143.08 (100%) usr   0.00 ( 0%) sys 143.09 (100%)
wall 151 kB ( 5%) ggc
 integrated RA   :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
49 kB ( 2%) ggc
 initialize rtl  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
12 kB ( 0%) ggc
 TOTAL : 143.10 0.00   143.12  
2939 kB

real2m23.132s
user2m23.108s
sys 0m0.008s

2)
g++-6 -v
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/6/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/6
--enable-ssp --disable-libssp --disable-libvtv --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--with-default-libstdcxx-abi=gcc4-compatible
--enable-version-specific-runtime-libs --enable-linker-build-id
--enable-linux-futex --program-suffix=-6 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 6.1.1 20160531 (SUSE Linux)

[Bug lto/69003] [4.9/5/6 Regression] Undefined reference with gcc -r incremental linking

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69003

--- Comment #6 from Franz Sirl  ---
Yes, this fixes the testcase and also the real application it was derived from
here. No testsuite regressions on x86_64 either.

[Bug c/79153] -Wimplicit-fallthrough missed warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153

--- Comment #6 from Franz Sirl  ---
I see. If you really close it as WONTFIX, could this small deficiency at least
be documented in the manual? I guess the non-warning case happens only when the
switch-statement directly (no other statements in between) precedes the
case-statement?

[Bug c/79199] New: ICE with -Wduplicated-branches

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79199

Bug ID: 79199
   Summary: ICE with -Wduplicated-branches
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This creduce'd testcase crashes with -Wduplicated-branches (trunk r244773).

unsigned int a, b, c, d, e;
void fn1(void) {
  if (0) {
if (d > 4294967293)
  (void) 5;
c = d;
b = e | a;
  } else {
if (d > 4294967293)
  (void) 5;
c = d;
b = e | a;
  }
}

# gcc-trunk -S -fpreprocessed -Wduplicated-branches -xc testcase.i -W -Wall
testcase.i: In function 'fn1':
testcase.i:14:1: internal compiler error: Segmentation fault
 }
 ^
0x9d70af crash_signal
../../gcc/toplev.c:333
0x6d6bda operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:2761
0x6d9332 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:3150
0x6d6e17 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:2743
0x6d7880 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:3307
0x6d6e17 operand_equal_p(tree_node const*, tree_node const*, unsigned int)
../../gcc/fold-const.c:2743
0x554251 do_warn_duplicated_branches
../../gcc/c-family/c-warn.c:2270
0x554251 do_warn_duplicated_branches_r(tree_node**, int*, void*)
../../gcc/c-family/c-warn.c:2287
0xc99343 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, default_hash_traits<tree_node*> >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set<tree_node*, default_hash_traits<tree_node*> >*))
../../gcc/tree.c:11795
0xc98e90 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*,
default_hash_traits<tree_node*> >*))
../../gcc/tree.c:12138
0x517d12 c_genericize(tree_node*)
../../gcc/c-family/c-gimplify.c:129
0x450ebc finish_function()
../../gcc/c/c-decl.c:9361
0x4bf0fa c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2110
0x4c6fb3 c_parser_external_declaration
../../gcc/c/c-parser.c:1463
0x4c7a29 c_parser_translation_unit
../../gcc/c/c-parser.c:1344
0x4c7a29 c_parse_file()
../../gcc/c/c-parser.c:18156
0x524bb3 c_common_parse_file()
../../gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://bugs.opensuse.org/> for instructions.

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082

--- Comment #6 from Franz Sirl  ---
Created attachment 40566
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40566=edit
extended testcase

Hmm, looks like there is an off-by-one bug lurking here?
To clarify my setup, here are the warnings for the attached testcase on
Linux/x86-64 (SLES12SP2) with a bootstrapped r244773 compiler.

First, gcc-trunk -c -Wformat-truncation test-snprintf-2.c -O0:
test-snprintf-2.c: In function 'test':
test-snprintf-2.c:6:23: warning: '%2d' directive output may be truncated
writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
   ^~~
test-snprintf-2.c:6:22: note: using the range [1, -2147483648] for directive
argument
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
  ^
test-snprintf-2.c:6:2: note: format output between 3 and 12 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
  ^
test-snprintf-2.c:7:23: warning: '%2hhd' directive output may be truncated
writing between 2 and 4 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2hhd", val % 100); /* 2 */ /* should warn */
   ^
test-snprintf-2.c:7:22: note: using the range [1, -128] for directive argument
  snprintf(buffer, 3, "%2hhd", val % 100); /* 2 */ /* should warn */
  ^~~
test-snprintf-2.c:7:2: note: format output between 3 and 5 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2hhd", val % 100); /* 2 */ /* should warn */
  ^~~
test-snprintf-2.c:9:23: warning: '%2d' directive output may be truncated
writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100): val % 100); /* 3 */ /*
should not warn */
   ^~~
test-snprintf-2.c:9:22: note: using the range [1, -2147483648] for directive
argument
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100): val % 100); /* 3 */ /*
should not warn */
  ^
test-snprintf-2.c:9:2: note: format output between 3 and 12 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100): val % 100); /* 3 */ /*
should not warn */
  ^~~
test-snprintf-2.c:10:23: warning: '%2d' directive output may be truncated
writing between 2 and 11 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100)); /* 4 */ /* should not
warn */
   ^~~
test-snprintf-2.c:10:22: note: using the range [1, -2147483648] for directive
argument
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100)); /* 4 */ /* should not
warn */
  ^
test-snprintf-2.c:10:2: note: format output between 3 and 12 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100)); /* 4 */ /* should not
warn */
  ^~~~
test-snprintf-2.c:12:23: warning: '%2x' directive output may be truncated
writing between 2 and 8 bytes into a region of size 3 [-Wformat-truncation=]
  snprintf(buffer, 3, "%2x", val & 0xff); /* 5 */ /* should not warn */
   ^~~
test-snprintf-2.c:12:22: note: using the range [1, 4294967295] for directive
argument
  snprintf(buffer, 3, "%2x", val & 0xff); /* 5 */ /* should not warn */
  ^
test-snprintf-2.c:12:2: note: format output between 3 and 9 bytes into a
destination of size 3
  snprintf(buffer, 3, "%2x", val & 0xff); /* 5 */ /* should not warn */
  ^~
test-snprintf-2.c:13:23: warning: '%03x' directive output may be truncated
writing between 3 and 8 bytes into a region of size 4 [-Wformat-truncation=]
  snprintf(buffer, 4, "%03x", val & 0xfff); /* 6 */ /* should not warn */
   ^~~~
test-snprintf-2.c:13:22: note: using the range [1, 4294967295] for directive
argument
  snprintf(buffer, 4, "%03x", val & 0xfff); /* 6 */ /* should not warn */
  ^~
test-snprintf-2.c:13:2: note: format output between 4 and 9 bytes into a
destination of size 4
  snprintf(buffer, 4, "%03x", val & 0xfff); /* 6 */ /* should not warn */
  ^~~~

No idea why 8 (and maybe 7?) does not warn on my machine, certainly the buffer
is too small for anything >= 0x1000.


Second, gcc-trunk -c -Wformat-truncation test-snprintf-2.c -O2:
test-snprintf-2.c: In function 'test':
test-snprintf-2.c:6:26: warning: output may be truncated before the last format
character [-Wformat-truncation=]
  snprintf(buffer, 3, "%2d", val % 100); /* 1 */ /* should warn */
   ~~~^
test-snprintf-2.c:6:2: note: format output between 3 and 4 bytes into 

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082

--- Comment #14 from Franz Sirl  ---
I just finished testing with r245021 and now the warnings are as expected. All
warnings are there with -Wformat-truncation=2 and also -Wformat-truncation=1
behaves according to the documentation (BTW, there's a typo in invoke.texi,
"truncatation" instead of "truncation").
You can close the bug.

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082

--- Comment #9 from Franz Sirl  ---
With r244892 and -O2 -Wformat-truncation=2 I nearly get the warnings I expect. 

What remains is case 3, but this seems to be a small deficiency in VRP. For the
term I used ((val < 0) ? -(val % 100) : (val % 100)), it seems VRP cannot
deduce that both branches of the IF finally result in [0, 99]. On the other
hand, a "normal" abs()-like macro would result in (((val % 100) < 0) ? -(val %
100) : (val % 100)), which some other pass turns into an ABS_EXPR which is
handled fine by VRP and accordingly the warning goes away too.

It seems a part of 78703 is still missing, because there are still warnings at
-O0?

To make my point about the warnings at -O0 more clear, I believe a false
positive at -O0 even though the argument was already properly (!) range limited
at the spot (which I believe would be a common way for programmers to kill the
warning) is really not helpful. So with a mini-VRP at -O0 for function
arguments the warning could be acceptable at -O0. But in its current state I
believe the warning should only be turned on automatically when VRP is active.

[Bug c++/79258] New: -Wduplicated-branches false positive?

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79258

Bug ID: 79258
   Summary: -Wduplicated-branches false positive?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This code:

class Base
{
public:
  static bool state();
};

class Derived : public Base
{
};


class MyClass
{
public:
  Derived *m_Derived;
  Base *m_Base;
  bool state();
};

bool MyClass::state() 
{
  if (m_Derived != (void *) 0)
return m_Derived->state();
  else 
return m_Base->state();
}


results in this warning:
# g++-trunk -c -Wduplicated-branches -O2 test.c
test.c: In member function 'bool MyClass::state()':
test.c:22:2: warning: this condition has identical branches
[-Wduplicated-branches]
  if (m_Derived != (void *) 0)
  ^~

Should the compiler really warn here?

[Bug c/79692] New: -Wformat-overflow false positive?

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79692

Bug ID: 79692
   Summary: -Wformat-overflow false positive?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40820=edit
testcase

With trunk r245678 on x86_64 the attached testcase prints these warnings:

gcc-trunk -Wformat-overflow -O2 -c test-sprintf-2.c 
test-sprintf-2.c: In function 'test':
test-sprintf-2.c:90:32: warning: '%0*lX' directive writing between 1 and
2147483648 bytes into a region of size 76 [-Wformat-overflow=]
   sprintf (buffer, "1: %s%c%0*lX %s%c%0*lX", reg, sFrom, nFrom,
^
test-sprintf-2.c:90:24: note: directive argument in the range [0,
4611686018427387904]
   sprintf (buffer, "1: %s%c%0*lX %s%c%0*lX", reg, sFrom, nFrom,
^~~~
test-sprintf-2.c:90:24: note: directive argument in the range [0,
4611686018427387904]
test-sprintf-2.c:90:7: note: 'sprintf' output 9 or more bytes (assuming
4294967303) into a destination of size 80
   sprintf (buffer, "1: %s%c%0*lX %s%c%0*lX", reg, sFrom, nFrom,
   ^
 (uint64_t) from, reg, sTo, nTo, (uint64_t) to);
 ~~
test-sprintf-2.c:109:29: warning: '%0*lX' directive writing between 1 and
2147483648 bytes into a region of size 76 [-Wformat-overflow=]
sprintf (buffer, "2: %s%c%0*lX %0*lX", reg, sFrom, nFrom,
 ^
test-sprintf-2.c:109:21: note: directive argument in the range [0,
4611686018427387904]
sprintf (buffer, "2: %s%c%0*lX %0*lX", reg, sFrom, nFrom,
 ^~~~
test-sprintf-2.c:109:4: note: 'sprintf' output 8 or more bytes (assuming
2147483655) into a destination of size 80
sprintf (buffer, "2: %s%c%0*lX %0*lX", reg, sFrom, nFrom,
^
  (uint64_t) from, nLen, (uint64_t) len);
  ~~

To me it seems it shouldn't warn. PR 79275 looks like a variant of this problem
and was already fixed.

[Bug c/79153] New: -Wimplicit-fallthrough missed warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79153

Bug ID: 79153
   Summary: -Wimplicit-fallthrough missed warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

I believe this testcase modeled after real code should warn when falling
through into 'case 4'.

int
test (int v1, int v2)
{
  switch (v1)
{
case 3:
  switch (v2)
{
case 1:
  return 28;
case 2:
  return 38;
case 3:
  return 88;
}
case 4:
  return 168;
}
  return -1;
}

[Bug c/79082] -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082

--- Comment #4 from Franz Sirl  ---
Hmm, %hhd is not usable on some of our platforms and also only really helpful
with exact %x outputs:

  snprintf(buffer, 3, "%02hhx", val);

What about:

  snprintf(buffer, 4, "%03hx", val & 0xfff);

Here the 'h' modifier doesn't help at all and also in my eyes 'val & 0xfff' or
'abs(val % 100)' would be much more natural range limiters for warning
suppression. It's a pity there isn't at least a minimum "arguments-only-VRP"
even at -O0.

Can't we have another level or two for -Wformat-truncation that only warns when
VRP is active?

Note that I believe that

  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);

shouldn't warn when VRP is active. Seems to be a minor deficiency in VRP.

[Bug c/79152] New: -Wimplicit-fallthrough false positive triggered by goto statements

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79152

Bug ID: 79152
   Summary: -Wimplicit-fallthrough false positive triggered by
goto statements
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This strange creduce'd testcase warns with current trunk:

typedef struct {
char *   bs;
} xstruct;

void test (char ch, long handle) {
switch (ch) {
case 1:
goto label1;
goto label;
(ch) = *(((xstruct *) (handle))->bs++);
label:
label1:
((xstruct *) handle)->bs ;
}
}

# gcc-trunk -c -Wimplicit-fallthrough testcase.c
testcase.c: In function 'test':
testcase.c:10:14: warning: this statement may fall through
[-Wimplicit-fallthrough=]
 (ch) = *(((xstruct *) (handle))->bs++);
 ~^
testcase.c:11:1: note: here
 label:
 ^

I believe this is a false positive. I hope the creduce'd testcase is enough to
highlight the problem.

[Bug c/79692] [7 Regression] -Wformat-overflow false positive with unknown width

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79692

--- Comment #3 from Franz Sirl  ---
I can confirm that the patch fixes both the submitted testcase and the original
code.
Thanks for your efforts.

[Bug c/78568] New: Wtype-limits warning regression

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78568

Bug ID: 78568
   Summary: Wtype-limits warning regression
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 40179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40179=edit
testcase

The attached testcase produces warnings with gcc-4.4.7 on RHEL6, but somewhere
along the way it regressed. I've tested 4.6, 4.8, 4.9, 5, 6 and trunk, none of
them warns anymore, but they all still happily optimize the comparisons away.

gcc-4.4.7 produced:
$ gcc -O2 -Wtype-limits -c Wtype-limits.c 
Wtype-limits.c: In function 'testa':
Wtype-limits.c:4: warning: comparison is always true due to limited range of
data type
Wtype-limits.c: In function 'testb':
Wtype-limits.c:12: warning: comparison is always true due to limited range of
data type
Wtype-limits.c: In function 'testc':
Wtype-limits.c:20: warning: comparison is always true due to limited range of
data type

[Bug rtl-optimization/78735] New: profiledbootstrap with --enable-checking=yes,rtl fails on trunk due to -Werror=strict-overflow

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78735

Bug ID: 78735
   Summary: profiledbootstrap with --enable-checking=yes,rtl fails
on trunk due to -Werror=strict-overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Hi,

current trunk (tried r243299 and r243376) on x86_64 fails a profiledbootstrap
with --enable-checking=yes,rtl like that:

/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/./prev-gcc/
-B/usr/x86_64-suse-linux/bin/ -nostdinc++
-B/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs

-I/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux

-I/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include
 -I/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/libstdc++-v3/libsupc++
-L/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE -fprofile-use -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o combine.o -MT combine.o -MMD -MP -MF
./.deps/combine.TPo ../../gcc/combine.c
In file included from ../../gcc/combine.c:83:0:
../../gcc/combine.c: In function 'int recog_for_combine(rtx_def**, rtx_insn*,
rtx_def**)':
../../gcc/rtl.h:1076:17: error: assuming signed overflow does not occur when
assuming that (X - c) > X is always false [-Werror=strict-overflow]
  if (_i < 0 || _i >= GET_NUM_ELEM (_rtvec))\
 ^
../../gcc/rtl.h:702:45: note: in definition of macro 'GET_CODE'
 #define GET_CODE(RTX) ((enum rtx_code) (RTX)->code)
 ^~~
../../gcc/rtl.h:1298:28: note: in expansion of macro 'RTVEC_ELT'
 #define XVECEXP(RTX, N, M) RTVEC_ELT (XVEC (RTX, N), M)
^
../../gcc/combine.c:11088:21: note: in expansion of macro 'XVECEXP'
   if (GET_CODE (XVECEXP (pat, 0, i)) == CLOBBER
 ^~~
../../gcc/rtl.h:1076:17: error: assuming signed overflow does not occur when
assuming that (X - c) > X is always false [-Werror=strict-overflow]
  if (_i < 0 || _i >= GET_NUM_ELEM (_rtvec))\
 ^
../../gcc/rtl.h:702:45: note: in definition of macro 'GET_CODE'
 #define GET_CODE(RTX) ((enum rtx_code) (RTX)->code)
 ^~~
../../gcc/rtl.h:1298:28: note: in expansion of macro 'RTVEC_ELT'
 #define XVECEXP(RTX, N, M) RTVEC_ELT (XVEC (RTX, N), M)
^
../../gcc/combine.c:11088:21: note: in expansion of macro 'XVECEXP'
   if (GET_CODE (XVECEXP (pat, 0, i)) == CLOBBER
 ^~~
../../gcc/rtl.h:1076:17: error: assuming signed overflow does not occur when
assuming that (X - c) > X is always false [-Werror=strict-overflow]
  if (_i < 0 || _i >= GET_NUM_ELEM (_rtvec))\
 ^
../../gcc/rtl.h:702:45: note: in definition of macro 'GET_CODE'
 #define GET_CODE(RTX) ((enum rtx_code) (RTX)->code)
 ^~~
../../gcc/rtl.h:1298:28: note: in expansion of macro 'RTVEC_ELT'
 #define XVECEXP(RTX, N, M) RTVEC_ELT (XVEC (RTX, N), M)
^
../../gcc/combine.c:11088:21: note: in expansion of macro 'XVECEXP'
   if (GET_CODE (XVECEXP (pat, 0, i)) == CLOBBER
 ^~~
More of the same errors follow. A simple "make bootstrap" works fine.

The build (actually the SRCRPM from OBS with updated sources) was configured
like that:

CFLAGS='-O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE'
CXXFLAGS='-O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE'
XCFLAGS=

[Bug bootstrap/78817] stage2 bootstrap failure in vec.h:1613:5: error: argument 1 null where non-null expected after r243661

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78817

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #7 from Franz Sirl  ---
And on x86_64 a profiledbootstrap with --enable-checking=yes fails like this:

../../gcc/gengtype.c: In function 'const char*
get_file_srcdir_relative_path(const input_file*)':
../../gcc/gengtype.c:1760:14: error: argument 1 null where non-null expected
[-Werror=nonnull]
   if (strlen (f) > srcdir_len
   ~~~^~~
In file included from
/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/cstring:42:0,
 from ../../gcc/system.h:235,
 from ../../gcc/gengtype.c:26:
/usr/include/string.h:394:15: note: in a call to function 'size_t strlen(const
char*)' declared here
 extern size_t strlen (const char *__s)
   ^~
../../gcc/gengtype.c:1762:18: error: argument 1 null where non-null expected
[-Werror=nonnull]
   && strncmp (f, srcdir, srcdir_len) == 0)
  ^~~
In file included from
/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/cstring:42:0,
 from ../../gcc/system.h:235,
 from ../../gcc/gengtype.c:26:
/usr/include/string.h:143:12: note: in a call to function 'int strncmp(const
char*, const char*, size_t)' declared here
 extern int strncmp (const char *__s1, const char *__s2, size_t __n)
^~~
cc1plus: all warnings being treated as errors
Makefile:2596: recipe for target 'build/gengtype.o' failed
make[3]: *** [build/gengtype.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm fsf-funding.pod gcov.pod cpp.pod gfdl.pod gpl.pod gccgo.pod gfortran.pod
gcc.pod gcov-tool.pod
make[3]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux/gcc'
Makefile:4728: recipe for target 'all-stagefeedback-gcc' failed
make[2]: *** [all-stagefeedback-gcc] Error 2
make[2]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux'
Makefile:24232: recipe for target 'stagefeedback-bubble' failed
make[1]: *** [stagefeedback-bubble] Error 2
make[1]: Leaving directory
'/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243686/obj-x86_64-suse-linux'
Makefile:24251: recipe for target 'profiledbootstrap' failed
make: *** [profiledbootstrap] Error 2

[Bug c/79082] New: -Wformat-truncation inconsistent behaviour

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79082

Bug ID: 79082
   Summary: -Wformat-truncation inconsistent behaviour
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This small testcase warns differently for -O0/g/1/2/3 with this "gcc -c
-Wformat-truncation test.c"

extern int snprintf(char *str, __SIZE_TYPE__ size, const char *format, ...);
void test(char *buffer, int val)
{
  snprintf(buffer, 3, "%2d", val % 100);
  snprintf(buffer, 3, "%2d", (val < 0) ? -(val % 100) : val % 100);
  snprintf(buffer, 3, "%2d", __builtin_abs(val % 100));
  snprintf(buffer, 3, "%2x", val & 0xff);
}

-O0/1 produce 4 warnings, -O2/3 produce 2 warnings and -Og doesn't warn at all.
I believe it should only ever warn for the first case.

[Bug rtl-optimization/78735] profiledbootstrap with --enable-checking=yes,rtl fails on trunk due to -Werror=strict-overflow

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78735

--- Comment #1 from Franz Sirl  ---
Can be worked around by bootstrapping with --disable-werror. Last reconfirmed
with trunk r246380. Trunk is at 7.0.1, so --disable-werror is the default right
now.

I guess the only real question is if the profile-based optimization is doing
the right thing here.

[Bug c/80253] New: Optimization silences __attribute__((fallthrough)) warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80253

Bug ID: 80253
   Summary: Optimization silences __attribute__((fallthrough))
warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41073=edit
testcase

The attached testcase issues 2 warnings with -O0 and only 1 warning with -O1 or
higher. I believe 2 warnings should be issued in both cases.

# gcc-trunk -Wall -c fallthrough-1.c -O0
fallthrough-1.c: In function 'test':
fallthrough-1.c:4:21: warning: attribute 'fallthrough' not preceding a case
label or default label
 #define FALLTHROUGH __attribute__((fallthrough))
 ^
fallthrough-1.c:25:5: note: in expansion of macro 'FALLTHROUGH'
 FALLTHROUGH;
 ^~~
fallthrough-1.c:4:21: warning: attribute 'fallthrough' not preceding a case
label or default label
 #define FALLTHROUGH __attribute__((fallthrough))
 ^
fallthrough-1.c:32:4: note: in expansion of macro 'FALLTHROUGH'
FALLTHROUGH;
^~~


# gcc-trunk -Wall -c fallthrough-1.c -O1
fallthrough-1.c: In function 'test':
fallthrough-1.c:4:21: warning: attribute 'fallthrough' not preceding a case
label or default label
 #define FALLTHROUGH __attribute__((fallthrough))
 ^
fallthrough-1.c:25:5: note: in expansion of macro 'FALLTHROUGH'
 FALLTHROUGH;
 ^~~

[Bug sanitizer/79265] [7 regression] -fsanitize=undefined inserts unnecessary null pointer tests

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265

--- Comment #6 from Franz Sirl  ---
(In reply to Jakub Jelinek from comment #4)
> This is a new warning, the fact that we didn't warn on some code and now
> warn with a new warning is not necessarily a regression.

Well, I wasn't so sure either if it counts as a regression, that's why I asked
on IRC first and then changed it. If you feel otherwise, you can remove the
marker again.

I guess it is kind of a "usability regression":

- "gcc-6 -Wall -Werror": compiles
- "gcc-6 -Wall -Werror -fsanitize=undefined": compiles
- "gcc-7 -Wall -Werror": compiles
- "gcc-7 -Wall -Werror -fsanitize=undefined": doesn't compile because of false
warning

So it's no longer enough to "just add -fsanitize=undefined" and recompile, now
you have to adjust warnings as well.

If it can't be reasonably solved within the GCC-7 timeframe, I would be fine
with a stop-gap measure like removing -Wformat-overflow from -Wall when UBSAN
is active (for example).

[Bug sanitizer/79265] [7 regression] -fsanitize=undefined inserts unnecessary null pointer tests

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79265

Franz Sirl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-05
Summary|-fsanitize=undefined|[7 regression]
   |inserts unnecessary null|-fsanitize=undefined
   |pointer tests   |inserts unnecessary null
   ||pointer tests
 Ever confirmed|0   |1

--- Comment #3 from Franz Sirl  ---
Code that used to compile warning-free with "gcc-6 -Wall -fsanitize=undefined"
now throws a warning with current gcc-7.0.1.

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742

--- Comment #4 from Franz Sirl  ---
APPEARS_TO_BE_BOOLEAN_EXPR_P was introduced with r141340 (PR 7543), but I
cannot find a discussion on why this suppression makes sense. When I disable it
I only see 3 places where it triggers in trunk:

gcc/cp/lex.c:115:24: warning: suggest parentheses around operand of '!' or
change '&' to '&&' or '!' to '~' [-Wparentheses]

libdecnumber/decNumber.c:6036:11: warning: suggest parentheses around operand
of '!' or change '&' to '&&' or '!' to '~' [-Wparentheses]

libgcc/libgcc2.c:1949:36: warning: suggest parentheses around operand of '!' or
change '&' to '&&' or '!' to '~' [-Wparentheses]

To my eyes in all 3 cases a '&&' would be clearer, so the warning shouldn't be
suppressed?
If changing the behaviour of -Wparentheses after this long time is considered a
problem, maybe we could add the stricter check to the relatively new
-Wlogical-not-parentheses like clang? 

Note: clang documents -Wlogical-not-parentheses for comparison AND bitwise
operators, GCC only for comparison operators.

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742

--- Comment #5 from Franz Sirl  ---
Actually, after seeing a large bunch of justified warnings in our codebase with
the disabled APPEARS_TO_BE_BOOLEAN_EXPR_P check, I wonder if a new option like
-Wbool-bitwise-parentheses (thus not depending on the logical NOT) would make
sense?

Note that this is heavily influenced by my code reading/code debugging POV, I
really hate it if I need lots of context to decide whether a statement in a
codebase unknown to me is correct or not. A warning like
-Wbool-bitwise-parentheses encourages programmers to make their intention clear
from the start. Or, in the best case, even uncovers coding bugs or typos early.

[Bug c/46742] -Wparentheses unexpectedly misses some cases

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46742

Franz Sirl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-05
 CC||sirl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Franz Sirl  ---
Still happens with 7.1.1 and trunk. clang catches both with the
-Wlogical-not-parentheses option.

[Bug c/81779] New: bool define from stdbool.h suppresses -Wdeclaration-after-statement

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81779

Bug ID: 81779
   Summary: bool define from stdbool.h suppresses
-Wdeclaration-after-statement
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This testcase warns only once with -Wdeclaration-after-statement since at least
gcc-4.8:

#include 

bool f2(char *pRedo)
{
if (!pRedo)
return false;

bool ret = true;
return ret;
}

int f3(char *pRedo)
{
if (!pRedo)
return 0;

int ret = 1;
return ret;
}

# gcc-7 -c -Wdeclaration-after-statement Wdeclaration-after-statement.c
Wdeclaration-after-statement.c: In function 'f3':
Wdeclaration-after-statement.c:18:2: warning: ISO C90 forbids mixed
declarations and code [-Wdeclaration-after-statement]
  int ret = 1;
  ^~~

gcc-4.4 warned 2 for both occurences:
# gcc-4.4 -c -Wdeclaration-after-statement Wdeclaration-after-statement.c
Wdeclaration-after-statement.c: In function 'f2':
Wdeclaration-after-statement.c:10: warning: ISO C90 forbids mixed declarations
and code
Wdeclaration-after-statement.c: In function 'f3':
Wdeclaration-after-statement.c:17: warning: ISO C90 forbids mixed declarations
and code

Adding -Wsystem-headers shows 2 warnings also with newer GCC, but I don't think
that this option should influence -Wdeclaration-after-statement.

[Bug c/81783] New: -Wtautological-compare could do better

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81783

Bug ID: 81783
   Summary: -Wtautological-compare could do better
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This example code doesn't warn with -Wtautological-compare:

int f(int a)
{
if ((a & 0x10) == 10)
return 1;
return 0;
}

clang warns like this:
Wtautological-compare-1.c:5:17: warning: bitwise comparison always evaluates to
false [-Wtautological-compare]
if ((a & 0x10) == 10)
~~~^

[Bug c++/46476] Missing Warning about unreachable code after return

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #10 from Franz Sirl  ---
Clang does also have -Wunreachable-code-break and -Wunreachable-code-return,
which are really nice to have because you can turn them into errors separately.
But even clang misses a few cases that VS2015 can detect.

[Bug driver/80828] New: Command line option -e not documented

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828

Bug ID: 80828
   Summary: Command line option -e not documented
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

I couldn't find (also grepping under trunk/gcc/doc) any documentation on the -e
commandline option. It seems the option and it's argument are directly passed
to the linker, similar to -T (which is documented in invoke.texi).

[Bug rtl-optimization/80930] REE pass causes high memory usage via df_mir_alloc() with ASAN+UBSAN turned on

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80930

--- Comment #2 from Franz Sirl  ---
Further investigation shows that "-O2 -fsanitize=undefined" is enough to
trigger the excessive memory usage.
The big difference between GCC-6 and GCC-7 is that the function causing this
has ~20 blocks in GCC-6 and ~30 blocks in GCC-7. I'll try to
investigate the reason for this 50% increase a bit.

[Bug middle-end/80930] New: REE pass causes high memory usage via df_mir_alloc() with ASAN+UBSAN turned on

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80930

Bug ID: 80930
   Summary: REE pass causes high memory usage via df_mir_alloc()
with ASAN+UBSAN turned on
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

We have an inhouse C source where the memory usage is excessive (> 88GB, then
OOM killed) with GCC-7/x86_64 (7.1.1@r248575). With GCC-6 (6.3.1@r248575) the
memory usage is a bit better, roughly 58GB.
When stopped in gdb shortly before OOM, the backtrace looks like this

(gdb) bt
#0  bitmap_elt_insert_after (indx=1076, elt=,
head=0x7fff3aa62bd0) at ../../gcc/bitmap.c:409
#1  bitmap_set_range(bitmap_head*, unsigned int, unsigned int) () at
../../gcc/bitmap.c:1233
#2  0x00c9827b in df_mir_alloc(bitmap_head*) () at
../../gcc/df-problems.c:1914
#3  0x00c8d454 in df_analyze_problem (n_blocks=299166,
postorder=0x17168b2e0, blocks_to_consider=, dflow=0x16b830fb0)
at ../../gcc/df-core.c:1165
#4  df_analyze_1 () at ../../gcc/df-core.c:1226
#5  df_analyze() () at ../../gcc/df-core.c:1294
#6  0x0109ab81 in find_and_remove_re () at ../../gcc/ree.c:1216
#7  rest_of_handle_ree () at ../../gcc/ree.c:1310
#8  (anonymous namespace)::pass_ree::execute(function*) () at
../../gcc/ree.c:1338
#9  0x00deace1 in execute_one_pass(opt_pass*) () at
../../gcc/passes.c:2465
#10 0x0062c20c in execute_pass_list_1 (pass=0x1c94570) at
../../gcc/passes.c:2554
#11 0x0062c1dc in execute_pass_list_1 (pass=0x1c943f0) at
../../gcc/passes.c:2555
#12 execute_pass_list_1 (pass=0x1c931d0) at ../../gcc/passes.c:2555
#13 execute_pass_list (fn=, pass=) at
../../gcc/passes.c:2565
#14 0x010fcb0d in cgraph_node::expand (this=0x7fffe8ccbcf0) at
../../gcc/cgraphunit.c:2042
#15 expand_all_functions () at ../../gcc/cgraphunit.c:2178
#16 symbol_table::compile() () at ../../gcc/cgraphunit.c:2535
#17 0x00c7973f in symbol_table::finalize_compilation_unit() () at
../../gcc/cgraphunit.c:2625
#18 0x0113b6b0 in compile_file() () at ../../gcc/toplev.c:492
#19 0x00bd2afb in do_compile () at ../../gcc/toplev.c:2000
#20 toplev::main(int, char**) () at ../../gcc/toplev.c:2134
#21 0x00bd439b in main (argc=177, argv=0x7fffcbd8) at
../../gcc/main.c:39

Using -fno-ree brings down memory usage to 7GB (GCC-7) and 5GB (GCC-6).
The relevant options for the compile are:
 -g -O2 -version -fsanitize=address -fstack-protector-strong
-fsanitize=undefined -fsanitize=bounds-strict -fno-omit-frame-pointer
-fno-common -ffunction-sections -fdata-sections -faggressive-loop-optimizations

I can provide more information and do other testing, but a public testcase will
likely be impossible.

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271

--- Comment #3 from Franz Sirl  ---
The bug was introduced with r195054:

2013-01-09  Jan Hubicka  

PR tree-optimiation/55875
* tree-ssa-loop-niter.c (number_of_iterations_cond): Add
EVERY_ITERATION parameter.
(number_of_iterations_exit): Check if exit is executed every
iteration.
(idx_infer_loop_bounds): Similarly here.
(n_of_executions_at_most): Simplify
to only test for cases where statement is dominated by the
particular bound; handle correctly the "postdominance"
test.
(scev_probably_wraps_p): Use max loop iterations info
as a global bound first.

BTW, -fno-tree-vrp also suppresses the bug.

[Bug target/82271] New: loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271

Bug ID: 82271
   Summary: loop gets miscompiled on powerpc at -O2
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42211=edit
testcase

The attached testcase removes conditions in the loop when compiled for
powerpc-eabi with -O2. On the trunk the bug got fixed (went latent?) with
r247886. Applying this revision to current 7.2.1@r252980 also fixes it there.

When comparing trunk compilers r247885 and r247886 the differences start in the
ivopts dump. Further on in the vrp2 dump, the difference is easy to see,
r247886 does have "if (nAccessSize_67 == 4096)", r247885 doesn't have it.

A quick check suggests this bug is there since at least 4.7. If I read the
dumps correctly, I couldn't reproduce it with x86, either -m32 or -m64.

[Bug target/82271] [5/6/7 Regression] loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271

--- Comment #6 from Franz Sirl  ---
Actually this is likely triggered by undefined behaviour. The array m_pTemp is
too small for nAccessSize=4096. Increasing the array size to 1024 elements
makes the bug go away.
If you agree, just close the bug and sorry for the noise.

[Bug target/82271] loop gets miscompiled on powerpc at -O2

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82271

Franz Sirl  changed:

   What|Removed |Added

  Known to work||4.5.4, 4.6.4, 4.7.4
  Known to fail||4.8.0, 4.8.5, 5.4.0, 6.4.0,
   ||7.2.0

--- Comment #1 from Franz Sirl  ---
I was slightly wrong, 4.7 works. Further testing shows that 4.5.4, 4.6.4 and
4.7.4 are OK, starting with 4.8.0 the loop gets miscompiled.

[Bug c/83510] New: Recent changes for -Warray-bounds trigger false positive

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510

Bug ID: 83510
   Summary: Recent changes for -Warray-bounds trigger false
positive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 42933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42933=edit
testcase

The attached testcase started to produce a warning with trunk somewhere between
r255501 and r255678, with -O2 -Warray-bounds:

test-Warray-bounds.c: In function 'g':
test-Warray-bounds.c:18:13: warning: array subscript 4294967286 is above array
bounds of 'unsigned int[10]' [-Warray-bounds=]
   return arr[number - 0xa];
  ~~~^~

I believe it is a false positive.


unsigned int arr[10];

struct xyz {
unsigned int a0;
};

extern void wfm(struct xyz *, int, unsigned int);

static unsigned int f(struct xyz * ctx, unsigned int number)
{
switch (number) {
case 0x9:
return ctx->a0;
case 0xA: case 0xB:
case 0xC: case 0xD: case 0xE: case 0xF:
case 0x10: case 0x11: case 0x12: case 0x13:
return arr[number - 0xa];
}
return 0;
}

int g(struct xyz * ctx) {
int i;

for (i = 0; i < 10; i++) {
wfm(ctx, i, f(ctx, i));
}

return 0;
}

[Bug middle-end/85650] New: Additional warnings when -fsanitize=undefined is used with -Wstringop-truncation

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650

Bug ID: 85650
   Summary: Additional warnings when -fsanitize=undefined is used
with -Wstringop-truncation
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44067=edit
testcase 1

These 2 testcases show additional warnings when -fsanitize=undefined is added
to the commandline.

$ LANG=C gcc-8 -c -O2 -fsanitize=undefined -Wstringop-truncation  t8.c 
t8.c: In function 'ay':
t8.c:13:3: warning: 'strncpy' output may be truncated copying between 0 and
7998 bytes from a string of length 7999 [-Wstringop-truncation]
   strncpy(c, a, b);
   ^~~~


$ LANG=C gcc-8 -c -O2 -fsanitize=undefined -Wstringop-truncation t9.c 
t9.c: In function 'd':
t9.c:15:3: warning: 'strncpy' output may be truncated copying between 0 and
4094 bytes from a string of length 4094 [-Wstringop-truncation]
   strncpy(st, a.ah.a, len);
   ^~~~

Current trunk@r259927 shows the same behaviour.

[Bug middle-end/85652] New: -Wformat-overflow warning silenced by -fpic/-fPIC

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85652

Bug ID: 85652
   Summary: -Wformat-overflow warning silenced by -fpic/-fPIC
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-linux

Created attachment 44070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44070=edit
testcase

The attached creduce'd testcase warns with -Wformat-overflow:

$ g++-8 -c -O2 -Wformat-overflow t7.cpp 
t7.cpp: In function 'void f()':
t7.cpp:15:16: warning: '%s' directive writing up to 55 bytes into a region of
size 12 [-Wformat-overflow=]
t7.cpp:9:10:
   return c[d];
     
t7.cpp:15:16:
 sprintf(e, " %s / %s", "", g);
^~
t7.cpp:15:12: note: 'sprintf' output between 17 and 72 bytes into a destination
of size 28
 sprintf(e, " %s / %s", "", g);
 ~~~^~

But when -fpic or -fPIC is added, the warning vanishes. Current trunk@259927
shows the same behaviour.

[Bug middle-end/85650] Additional warnings when -fsanitize=undefined is used with -Wstringop-truncation

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650

--- Comment #1 from Franz Sirl  ---
Created attachment 44068
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44068=edit
testcase 2

[Bug tree-optimization/86232] New: ICE in record_estimate, at tree-ssa-loop-niter.c:3258

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86232

Bug ID: 86232
   Summary: ICE in record_estimate, at tree-ssa-loop-niter.c:3258
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This short creduced snippet

enum { a = 1 } b;
int c() {
  int d = a;
  for (; d;)
d &= d - 1;
  return b;
}

compiled with "gcc-9 -c -W -Wall -O2 test-loop-ICE.c" produces this ICE:

during GIMPLE pass: cddce
test-loop-ICE.c: In function 'c':
test-loop-ICE.c:7:1: internal compiler error: in record_estimate, at
tree-ssa-loop-niter.c:3258
 }
 ^
0x850415 record_estimate
../../gcc/tree-ssa-loop-niter.c:3258
0x11a3ddc estimate_numbers_of_iterations(loop*)
../../gcc/tree-ssa-loop-niter.c:4109
0x11a9dc0 max_loop_iterations(loop*,
generic_wide_int >*)
../../gcc/tree-ssa-loop-niter.c:4181
0x11a9dc0 finite_loop_p(loop*)
../../gcc/tree-ssa-loop-niter.c:2714
0x1171c3d find_obviously_necessary_stmts
../../gcc/tree-ssa-dce.c:420
0x1171c3d perform_tree_ssa_dce
../../gcc/tree-ssa-dce.c:1555
0x1171c3d tree_ssa_cd_dce
../../gcc/tree-ssa-dce.c:1612
0x1171c3d execute
../../gcc/tree-ssa-dce.c:1677

This is a recent regression between r261589 and r261688, still present in
r261783.
The backtrace with the original source looks different, but ends up in the same
place:
during GIMPLE pass: cunrolli
test-loop-ICE-full.cpp: In member function 'void MyClass12::initState()':
test-loop-ICE-full.cpp:246:6: internal compiler error: in record_estimate, at
tree-ssa-loop-niter.c:3258
 void MyClass12::initState()
  ^
0x9620d5 record_estimate
../../gcc/tree-ssa-loop-niter.c:3258
0x13b093c estimate_numbers_of_iterations(loop*)
../../gcc/tree-ssa-loop-niter.c:4109
0x13b8502 estimate_numbers_of_iterations(function*)
../../gcc/tree-ssa-loop-niter.c:4329
0x16922f6 tree_unroll_loops_completely
../../gcc/tree-ssa-loop-ivcanon.c:1441
0x139c7ae execute
../../gcc/tree-ssa-loop-ivcanon.c:1668

[Bug tree-optimization/83510] [8 Regression] Recent changes for -Warray-bounds trigger false positive

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510

--- Comment #6 from Franz Sirl  ---
The patch in comment 5 applied to r256877 fixes the warning in both the
testcase and the original code.

[Bug c/83989] New: -Wrestrict false positive with malloc-style functions

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83989

Bug ID: 83989
   Summary: -Wrestrict false positive with malloc-style functions
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43216
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43216=edit
testcase

Compiling the attached file with r256939 of trunk issues 2 warnings. I believe
they are false positives and should have been suppressed by
__attribute__((__malloc__)).
gcc-7.2.1 didn't issue a warning here.

# gcc-trunk -c -Wall -Wrestrict -O2 Wrestrict-false-positive.c
Wrestrict-false-positive.c: In function 'load1':
Wrestrict-false-positive.c:44:4: warning: 'memcpy' accessing between 384 and
25769803764 bytes at offsets 0 and 0 overlaps between 384 and 25769803764 bytes
at offset 0 [-Wrestrict]
memcpy(recmem, oldrecmem, oldsize * sizeof(record_t));
^
Wrestrict-false-positive.c: In function 'load2':
Wrestrict-false-positive.c:75:4: warning: 'memcpy' accessing between 384 and
25769803764 bytes at offsets 0 and 0 overlaps between 384 and 25769803764 bytes
at offset 0 [-Wrestrict]
memcpy(recmem, oldrecmem, oldsize * sizeof(record_t));
^

[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #15 from Franz Sirl  ---
(In reply to Bernd Edlinger from comment #8)
> $ cat part.c
> 
> const char a[2][3] = { "121", "1" };

FWIW, MSVC warns like this:

part.c(2): warning C4295: 'a': array is too small to include a terminating null
character

[Bug tree-optimization/83510] Recent changes for -Warray-bounds trigger false positive

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83510

Franz Sirl  changed:

   What|Removed |Added

  Known to work||6.4.0, 7.2.0

--- Comment #2 from Franz Sirl  ---
It started with r255649:

2017-12-14  David Malcolm  

PR tree-optimization/83312
* domwalk.h (dom_walker::dom_walker): Fix typo in comment.
* tree-cfg.c (find_taken_edge): Update to handle NULL_TREE for
"val" param, and to cope with arbitrary basic blocks.
(find_taken_edge_cond_expr): Add "cond_stmt" param and use it to
handle NULL_TREE for "val", dropping "bb" param.
(find_taken_edge_switch_expr): Make "switch_stmt" param const and
drop "bb" param.  Handle NULL_TREE for "val".
(find_case_label_for_value): Make "switch_stmt" param const.
* tree-vrp.c (class check_array_bounds_dom_walker): New subclass
of dom_walker.
(vrp_prop::check_all_array_refs): Reimplement as...
(check_array_bounds_dom_walker::before_dom_children): ...this new
vfunc.  Replace linear search through BB block list, excluding
those with non-executable in-edges via dominator walk.

[Bug c/84762] New: GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762

Bug ID: 84762
   Summary: GCC for PowerPC32 violates the SysV ABI spec for small
struct returns
   Product: gcc
   Version: 6.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: powerpc-eabi

For an example like:

struct smallstruct { char a; char b; char c; };

struct smallstruct f(void)
{
  struct smallstruct s = { 0x11, 0x22, 0x33 };

  return s;
}

r3 should look like 0x11223300, but GCC returns 0x00112233 in r3 (with the '00'
part actually being undefined).

The relevant part of the spec
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf:

Aggregates or unions whose size is less than or equal to eight bytes shall be
returned in r3 and r4, as if they were first stored in memory area and then the
low-addressed word were loaded in r3 and the high-addressed word were loaded
into r4. Bits beyond the last member of the structure or union are not defined.

Or the older http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf says
nearly the same (with an additional alignment clause):

A structure or union whose size is less than or equal to 8 bytes shall be
returned in r3 and r4, as if it were first stored in an 8-byte aligned memory
area and then the low-addressed word were loaded into r3 and the high-addressed
word into r4. Bits beyond the last member of the structure or union are not
defined.

This was discovered during parameter passing tests as a difference to a
proprietary compiler.

As it is probably too late in the game to change GCC, this is more a
documentation request I guess.
Eventually -msvr4-struct-return could be extended to
-msvr4-struct-return={sysv,gnu} with 'gnu' as the (compile-time configurable?)
default.

[Bug c/84649] New: -Wstringop-truncation shouldn't warn on strncat() when 2nd argument is a char array

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84649

Bug ID: 84649
   Summary: -Wstringop-truncation shouldn't warn on strncat() when
2nd argument is a char array
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

With gcc-8 trunk@258093 for this example

char *append_leading_digits(char *cp, int i)
{
  char buf[16];
  __builtin_sprintf(buf, "%2i ", i);
  __builtin_strncat(cp, buf, 4);
  return cp;
}

gcc warns like that:

gcc-trunk -O2 -c test-strncat.c -Wstringop-truncation
test-strncat.c: In function 'append_leading_digits':
test-strncat.c:8:2: warning: '__builtin_strncat' output may be truncated
copying 3 bytes from a string of length 15 [-Wstringop-truncation]
  __builtin_strncat(cp, buf, 4);
  ^

I believe this warning is unjustified as buf[] may contain strings of varying
lengths and the whole purpose of strncat() is to truncate the source string
after all.
Actually maybe the warning should only trigger for strncat() when BOTH the 2nd
and 3rd argument are constant (like in the example in the manual)?

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #3 from Franz Sirl  ---
Created attachment 43650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43650=edit
another testcase

On x86_64-linux, when compiled with "gcc-7 -O2 -fsanitize=address" this
testcase prints nothing. With "gcc-7 -O2 -fsanitize=address
-fsanitize=undefined" this slightly confusing message is output:

test-asan1.c:36:29: runtime error: load of address 0x00602660 with
insufficient space for an object of type 'inttype'
0x00602660: note: pointer points here
 0c 00 00 00  80 20 60 00 00 00 00 00  28 00 00 00 00 00 00 00  60 00 00 00 00
00 00 00  80 0c 40 00
  ^ 
test-asan1.c:36:29: runtime error: store to address 0x00602660 with
insufficient space for an object of type 'inttype'
0x00602660: note: pointer points here
 0c 00 00 00  80 20 60 00 00 00 00 00  28 00 00 00 00 00 00 00  60 00 00 00 00
00 00 00  80 0c 40 00
  ^

[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762

--- Comment #13 from Franz Sirl  ---
Yes, I can do a patch for GCC-9. Any idea for the option naming? Like
-msvr4-struct-return-msb? Or should I consolidate -maix-struct-return and
-msvr4-struct-return into -maggr-return-mode={aix,svr4,svr4gnu}?

[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762

Franz Sirl  changed:

   What|Removed |Added

  Known to fail||3.1.1

--- Comment #11 from Franz Sirl  ---
It is wrong since the introduction of -msvr4-struct-return during the gcc-3.1
development. Before that GCC followed a draft ABI spec and returned all
aggregates in memory for ABI_V4.
A quick check reveals that a fix is probably easy to implement with a new
option (non-default for backwards compatibility), a small change in
rs6000_return_in_msb() and an additional value in rs6000_elf_file_end() for
".gnu_attribute 12".

[Bug c/85365] New: -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85365

Bug ID: 85365
   Summary: -Wrestrict false positives with -fsanitize=undefined
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This small testcase warns 3 time when compiled with 8.0.1@r259308:

extern char a[], b[], d[];
int c, e;
char *strcpy(char *, const char *);
char *strcat(char *, const char *);
__SIZE_TYPE__ strlen(char *);

void t1(char *g) {
  strcpy(g + 4, c ? b : a);
  e = strlen(g + 4);
}

void t2(char *g) {
  strcpy(g + 4, c ? b : a);
  strcat(g + 4, d);
}

void t3(char *g) {
  strcat(g + 4, c ? b : a);
  strcat(g + 4, d);
}

# gcc-8 -c -O2 -fsanitize=undefined -Wrestrict t.c
t.c: In function 't1':
t.c:8:3: warning: 'strcpy' source argument is the same as destination
[-Wrestrict]
   strcpy(g + 4, c ? b : a);
   ^~~~
t.c: In function 't2':
t.c:13:3: warning: 'strcpy' source argument is the same as destination
[-Wrestrict]
   strcpy(g + 4, c ? b : a);
   ^~~~
t.c: In function 't3':
t.c:18:3: warning: 'strcat' source argument is the same as destination
[-Wrestrict]
   strcat(g + 4, c ? b : a);
   ^~~~

gcc-7 didn't warn for this testcase.

[Bug middle-end/85420] More -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85420

--- Comment #1 from Franz Sirl  ---
Created attachment 43951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43951=edit
C++ testcase

[Bug middle-end/85420] More -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85420

--- Comment #3 from Franz Sirl  ---
Hmm, this maybe creduce'd too much, the original source reads more like

   strcpy(b, b + a + 10);

which would be only UB for sure if strlen(b + a + 10) >= 9, or?

[Bug middle-end/85420] New: More -Wrestrict false positives with -fsanitize=undefined

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85420

Bug ID: 85420
   Summary: More -Wrestrict false positives with
-fsanitize=undefined
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43950
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43950=edit
C testcase

The attached testcases produce extra warnings of the "may overlap" kind with
-Wrestrict -fsanitize=undefined (PR85365 covers the "same destination" kind).

# gcc-8 -c -O2 -fsanitize=undefined -Wrestrict t5.c 
t5.c: In function 'c':
t5.c:6:5: warning: 'strcpy' accessing 1 byte at offsets 0 and [0, 1] may
overlap 1 byte at offset 0 [-Wrestrict]
 strcpy(b, b + a);
 ^~~~


g++-8 -c -O2 -fsanitize=undefined -Wrestrict t6.cpp 
t6.cpp: In member function 'int c::m_fn1()':
t6.cpp:13:9: warning: 'char* strcat(char*, const char*)' accessing 4096 or more
bytes at offsets 0 and 4095 may overlap 1 byte at offset 4095 [-Wrestrict]
   strcat(e, d.b);
   ~~^~~~

[Bug c/85094] New: -g with any optimization suppresses -Wduplicated-branches

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85094

Bug ID: 85094
   Summary: -g with any optimization suppresses
-Wduplicated-branches
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This small testcase doesn't warn if compiled with -g and -O1 or higher. Only
"-g -O0" or for example -O2 without -g warn for the testcase. This is trunk at
r258870. gcc-7 warns as expected.

extern int g;

void f(int r)
{
  if (r < 64)
g -= 48;
  else if (r < 80)
g -= 64 - 45;
  else
g -= 80 - 61;
}

[Bug lto/85078] LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078

--- Comment #1 from Franz Sirl  ---
The ICE was introduced between r257623 and r257685.

[Bug lto/85078] New: LTO ICE: tree check: expected tree that contains 'decl minimal' structure, have 'identifier_node' in decl_mangling_context, at cp/mangle.c:878

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85078

Bug ID: 85078
   Summary: LTO ICE: tree check: expected tree that contains 'decl
minimal' structure, have 'identifier_node' in
decl_mangling_context, at cp/mangle.c:878
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 43760
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43760=edit
testcase

The attached testcase ICEs with trunk@r258851. 7.3.1 compiles the testcase
without problems.

g++-8 -flto -c -O2  test-LTO-ICE.cpp 
during IPA pass: visibility
test-LTO-ICE.cpp:20:8: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'identifier_node' in
decl_mangling_context, at cp/mangle.c:878
   void c (int, const char *, a &);
^
0xa22890 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/tree.c:9494
0x4b05dc contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3249
0x4b05dc decl_mangling_context
../../gcc/cp/mangle.c:878
0x4b05dc write_name
../../gcc/cp/mangle.c:906
0xfd6cea write_class_enum_type
../../gcc/cp/mangle.c:2809
0xfd6cea write_type
../../gcc/cp/mangle.c:
0xfd743b write_array_type
../../gcc/cp/mangle.c:3600
0xfd743b write_type
../../gcc/cp/mangle.c:2146
0xfd6ea8 write_type
../../gcc/cp/mangle.c:2255
0xfd7de8 write_method_parms
../../gcc/cp/mangle.c:2796
0xfd2af4 write_bare_function_type
../../gcc/cp/mangle.c:2732
0xfd2af4 write_encoding
../../gcc/cp/mangle.c:847
0xfd220e write_mangled_name
../../gcc/cp/mangle.c:790
0xfd220e mangle_decl_string
../../gcc/cp/mangle.c:3792
0xfd1cd5 get_mangled_id
../../gcc/cp/mangle.c:3814
0xfd1cd5 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3852
0x1451e5d decl_assembler_name(tree_node*)
../../gcc/tree.c:687
0x10f55e0 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/symtab.c:174
0x10f55e0 symtab_node::register_symbol()
../../gcc/symtab.c:386
0x10fd244 cgraph_node::create(tree_node*)
../../gcc/cgraph.c:520
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug tree-optimization/84670] [8 Regression] ICE: in compute_antic_aux, at tree-ssa-pre.c:2148 with -O2 -fno-tree-dominator-opts

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #2 from Franz Sirl  ---
Created attachment 43548
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43548=edit
another testcase

You just beat me to open this report :D

I'm adding another (but not so small) testcase.

[Bug c/86345] New: Likely false warning with -Wstringop-overflow and memset

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86345

Bug ID: 86345
   Summary: Likely false warning with -Wstringop-overflow and
memset
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44335=edit
testcase

The attached testcase warns like this with trunk@262215:

gcc-trunk -c -O2 -Wstringop-overflow test-stringop-overflow.c
test-stringop-overflow.c: In function 'func2':
test-stringop-overflow.c:56:3: warning: 'memset' specified size between
18446744071562067968 and 18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
   memset ((buf), 0, (len));
   ^~~~

This is a relatively new regression on trunk (gcc-8-branch is fine). The code
is quite sensitive to changes, so I didn't reduce it further.

[Bug c/88993] [9 Regression] GCC 9 -Wformat-overflow=2 should reflect real libc limits

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #12 from Franz Sirl  ---
What about moving this part of -Wformat-overflow=2 under -Woverlength-strings?
Or let it trigger only when -Wformat-overflow=2 and -Woverlength-strings are in
effect?

[Bug c/92290] New: Inconsistent -Warray-bounds warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92290

Bug ID: 92290
   Summary: Inconsistent -Warray-bounds warning
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47133=edit
testcase

The attached creduced testcases recently started to warn differently in trunk
(9 and earlier don't warn) depending on variable signedness. But I believe the
possible range of the loop counter values should be the same.

int a, b;
unsigned short t1 (void)
{
  int j;
  unsigned short pu = 0;
  unsigned int p[6] = { 0 };
  unsigned int v;
  for (j = 0; j < 1234; j++)
{
  v = a;
  if (((v >> 16) & 7) > 0)
{
  int i;
  b = p[0];
  for (i = 0; i < 6 - (int) ((v >> 16) & 0x07); i++)
p[i] = p[i + ((v >> 16) & 0x07)];
}
  pu >>= (int) ((v >> 16) & 0x07) * 2;
}
  return pu;
}


Compiled with -O2 -Warray-bounds, GCC trunk@277601 warns like this:

testcase.c: In function 't1':
testcase.c:17:14: warning: array subscript 6 is above array bounds of 'unsigned
int[6]' [\-Warray-bounds=\]
   17 |  p[i] = p[i + ((v >> 16) & 0x07)];
  | ~^~~~
testcase.c:7:16: note: while referencing ?p?
7 |   unsigned int p[6] = { 0 };
  |^

t2() is a slight modification with re-arranged loop condition and gives the
same warning.
t3() uses an unsigned loop variable and doesn't warn, which seems the correct
behaviour to me.

[Bug c/92380] New: Bogus -Warray-bounds warning with structures

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92380

Bug ID: 92380
   Summary: Bogus -Warray-bounds warning with structures
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47176=edit
testcase

This code:

typedef struct {
char cs[256];
} inner_small_struct;

typedef struct {
char cl[512];
} inner_large_struct;

typedef union {
inner_large_struct large;
inner_small_struct small;
} inner_union;

typedef struct {
int y;
inner_union inner;
} outer_struct;

typedef struct  {
int x;
char s[];
} flexarr_struct;

char *t1(outer_struct *p, char str[240])
{
flexarr_struct *l = (flexarr_struct *) ((char *) p + sizeof(*p) -
(sizeof(inner_large_struct) - sizeof(inner_small_struct)));
__builtin_strcpy(l->s, str);
return l->s;
}

warns with trunk@277817 like that:

> gcc-trunk -c -O2 -W -Wall -Warray-bounds=1 testcase.c
testcase.c: In function 't1':
testcase.c:28:2: warning: '__builtin_strcpy' offset 264 from the object at 'p'
is out of the bounds of referenced subobject 's' with type 'char[0]' at offset
264 [\-Warray-bounds=\]
   28 |  __builtin_strcpy(l->s, str);
  |  ^~~
testcase.c:22:7: note: subobject 's' declared here
   22 |  char s[];
  |   ^

Since gcc already knows about 'p' and the offset, it should also consider
sizeof(*p) when deciding to warn. Otherwise it's unfortunate that a flexible
array (compared to a size 1 array s[1]) suppresses UBSAN warnings, but
-Warray-bounds now warns.

[Bug c/97157] [11 Regression] -Wduplicated-branches: C ICE in hash_operand, at fold-const.c:3768 since r11-3302-g3696a50beeb73f4d

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97157

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #3 from Franz Sirl  ---
Isn't this a duplicate of PR97125? With patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554343.html ?

[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073

--- Comment #5 from Franz Sirl  ---
(In reply to Jakub Jelinek from comment #3)
> This broke in between r102000 (still good) and r104000 (already
> miscompiled), so I don't believe that 6.3.1 worked.

Hmm, maybe something in 6.3.1 is masking the bug? Yesterday I used "gcc version
6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)" from
devtoolset-6-gcc-6.3.1-3.1.el7.x86_64 to try.

But in the meantime I built 6.5.0 myself and surely enough it shows the bug
too?

[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073

Franz Sirl  changed:

   What|Removed |Added

  Known to work|6.3.1   |

--- Comment #7 from Franz Sirl  ---
No, my fault. At that machine I still used a testcase much closer to the
original code and that one passed. With the testcase in the bugreport it also
aborts.
Sorry for not re-checking!

[Bug middle-end/97073] [8/9/10/11 Regression] Miscompilation with -m32 -O1 -march=i686

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073

--- Comment #8 from Franz Sirl  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 49236 [details]
> gcc11-pr97073.patch
> 
> Untested fix.

I can confirm that this patch applied to the gcc-8 branch fixes the testcase
and the original problem in the affected application.

[Bug c/97073] New: Miscompilation with -m32 -O1 -march=i686

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97073

Bug ID: 97073
   Summary: Miscompilation with -m32 -O1 -march=i686
   Product: gcc
   Version: 8.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49229
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49229=edit
Testcase demonstrating the problem.

Hi,

the attached simple testcase aborts when compiled with every version since
gcc-7 (last tested r11-3232).
Compiled with gcc-6.3.1 the testcase doesn't abort.
Also adding either -fno-tree-ter or -msse2 prevents the abort.

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #5 from Franz Sirl  ---
Wstring-compare seems to depend a lot on the optimizations. In the following
testcase warnings are also inconsistent and fragile (slight changes make the
warning disappear):

int c, d, e;
void f(void) {
  const char *file = (c & 7) ? "file1234.txt" : "x";
  const char *file2 = (c & 7) ? "y" : "file12.txt";
  if (c == 2)
if (d
|| __builtin_strcmp(file, "file123.txt")
|| __builtin_strcmp(file2, "file123.txt")
   )
  e = 2;
}

With "gcc -c -O2 -Wstring-compare testcase.c" current trunk shows:

testcase.c: In function 'f':
testcase.c:8:12: warning: '__builtin_strcmp' of a string of length 11 and an
array of size 11 evaluates to nonzero [-Wstring-compare]
8 | || __builtin_strcmp(file2, "file123.txt")
  |^~

There is no warning for line 7 ('file').
Maybe the warning could also be a bit more verbose when the information is
available, like for example:

warning: '__builtin_strcmp' of a string ('file2' with content "y" ||
"file12.txt") and an array ("file123.txt") of size 11 always evaluates to
nonzero [-Wstring-compare]

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #17 from Franz Sirl  ---
(In reply to Segher Boessenkool from comment #13)
> Author: segher
> Date: Mon Jul 15 20:57:53 2019
> New Revision: 273498
> 
> URL: https://gcc.gnu.org/viewcvs?rev=273498=gcc=rev
> Log:
> rs6000: Always output .machine
> 
> We now can always output .machine (if we output it at all for the
> current target).
> 
> 
>   PR target/91050
>   * config/rs6000/rs6000.c (rs6000_file_start): Never skip emitting a
>   .machine directive.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/rs6000/rs6000.c

This caused PR target/101393

[Bug inline-asm/101393] New: PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

Bug ID: 101393
   Summary: PowerPC32 inline assembly broken by commit
2d94f7dea9c73ef3c116a0ddc722724578a860fe
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

A PowerPC32 GCC configured with "--target=powerpc-unknown-eabi
--enable-languages=c,c++ --with-cpu=403" compiling this snippet:

void test(void)
{
__asm__ __volatile__("dcread 3,3,0");
}

with "powerpc-unknown-eabi-gcc-10 -c test-ppc.c -o test-ppc-gcc10.o" results
in:

> objdump -d test-ppc-gcc10.o

test-ppc-gcc10.o: file format elf32-powerpc


Disassembly of section .text:

 :
   0:   7c 63 02 8c dcread  r3,r3,r0
   4:   4e 80 00 20 blr

With "powerpc-unknown-eabi-gcc-9 -c test-ppc.c -o test-ppc-gcc9.o":

> objdump -d test-ppc-gcc9.o 

test-ppc-gcc9.o: file format elf32-powerpc


Disassembly of section .text:

 :
   0:   7c 63 03 cc dcread  r3,r3,r0
   4:   4e 80 00 20 blr

Note the changed encoding for dcread, GCC-9 correctly produces an opcode for
PPC403/PPC440, while GCC-10 onwards produces the opcode for PPC476.
This is caused by the unconditional output of ".machine ppc" by GCC-10,
seemingly overriding the commandline to gas (-m403 -many).

[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #5 from Franz Sirl  ---
For the naming I suggest __builtin_debugtrap() to align with clang. Maybe with
an aliased __debugbreak() on Windows platforms.

[Bug c++/99251] New: Strange -Wnonnull warning behaviour with dynamic_cast

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251

Bug ID: 99251
   Summary: Strange -Wnonnull warning behaviour with dynamic_cast
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

With this testcase:

class cl1 {
  virtual void m();
};
class cl2 : public cl1 {
public:
  int g();
  int h();
  int i();
};
class cl3 {
  cl1 *p;
  int g();
  int h();
  int i();
};
int cl3::g() {
  if (!p)
return 0;
  cl2 *x = dynamic_cast(p);
  return x->g();
}
int cl3::h() {
  if (!p)
return 0;
  return (dynamic_cast(p))->h();
}
int cl3::i() {
  if (!p)
return 0;
  return dynamic_cast(p)->i();
}

compiled with g++-trunk@r11-7356 -Wnonnull this warning is issued:

testcase.cpp: In member function 'int cl3::i()':
testcase.cpp:30:36: warning: 'this' pointer is null [-Wnonnull]
   30 |   return dynamic_cast(p)->i();
  |^
testcase.cpp:8:7: note: in a call to non-static member function 'int cl2::i()'
8 |   int i();
  |   ^

I believe there should be no warning for cl3::i() like with g++-10.2.

[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299

--- Comment #8 from Franz Sirl  ---
(In reply to Segher Boessenkool from comment #7)
> (In reply to Franz Sirl from comment #5)
> > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe
> > with an aliased __debugbreak() on Windows platforms.
> 
> Those are terrible names.  This would *not* be used more often than
> __builtin_trap, for debugging.
> 
> In general, builtins should say what they *do*, nott what you imagine they
> will be used for.

Let me re-phrase it. If the result of this discussion will result in a builtin
that will be eqivalent to an "int 3" (or was it ud2? on x86) without "noreturn"
as it is with clang, I would really prefer it to be called
__builtin_debugtrap() even if the name is not great. Having different naming
between GCC and clang seems worse to me.

[Bug rtl-optimization/98144] REE needs 6GB DF memory when compiling insn-extract.c with RTL checking enabled

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98144

--- Comment #13 from Franz Sirl  ---
Some data for the inhouse testcase in Bug 80930 with ASAN+UBSAN:

 gcc-9@r9-8944:   OOM killed after 15min at ~85 GB
 gcc-10@r10-9345: takes ~25min to compile, max mem ~6.5GB

Thanks for this nice improvement!

[Bug c/99159] New: Confusing -Warray-bounds warning

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99159

Bug ID: 99159
   Summary: Confusing -Warray-bounds warning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Hi,

with this minimized testcase, compiled with -O2 -Warray-bounds:

struct s1
{
  char b[12];
};

struct s2
{
  int x;
  struct s1 y;
} *pb, c;

extern struct s2 *es;

void test1 (int f)
{
  struct s2 *p = f ? 0 : es;
  __builtin_memcpy (>y, p->y.b, sizeof(struct s1));
}

void test2 ()
{
  struct s2 *p = 0;
  __builtin_memcpy (>y, p->y.b, sizeof(struct s1));
}

trunk@r11-7270 warns like this:
testcase.c: In function 'test2':
testcase.c:23:3: warning: '__builtin_memcpy' offset [0, 11] is out of the
bounds [0, 0] [-Warray-bounds=]
   23 |   __builtin_memcpy (>y, p->y.b, sizeof(struct s1));
  |   ^~~~

I believe -Warray-bounds shouldn't warn here (or at least not with this
message) and gcc-10.2 and also trunk@r11-3693 don't.
Note that the real code is more like test1(), where it's not clear that 'p' is
always zero.

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

Franz Sirl  changed:

   What|Removed |Added

  Attachment #51164|0   |1
is obsolete||

--- Comment #7 from Franz Sirl  ---
Created attachment 51189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51189=edit
More complete trial patch to overhaul ASM_CPU_SPEC

This patch should be more complete now. It does the following basic things:

 - Only pass -many to the assembler when -massembler-any is given
 - Unify the non-AIX (for now) asm_cpu spec settings into rs6000-cpus.def.
Currently this uses a "static inline" function because I developed on GCC10, on
GCC11 and later using a constexpr would be much nicer.

Now, the other stuff to reliably handle -many would need some gas support,
where I likely need some help, because I've no expertise there.

First, I suggest to introduce 2 assembler warning options:

 -wany-duplicates: Warn if the mnemonic to assemble has duplicates because of
-many, this should limit the warnings to the most difficult cases. In the patch
it's automatically enabled when -massembler-any is used.
 -wany-strict: Warn if any mnemonic to assemble is only fulfilled because of
-many.

And also some additional/changed options for .machine:

 .machine "resetsticky": Reset the sticky flags (eg. VSX, AltiVec, ANY)
 .machine "pushsticky": Push CPU+sticky settings, reset the sticky flags
 .machine "push": Change to push CPU+sticky, keep the sticky flags
 .machine "pop": Change to pop CPU+sticky

The attached patch tries to make use of such a TBD change to gas.

Alternatively, gas could be changed to have -madditive-sticky and/or '.machine
"additive-sticky"' to make any '.machine "realcpu"' reset the sticky flags and
they have to be re-added again afterwards if needed. Maybe this push/pop-less
solution would be even easier to handle in the compiler?

What do you think? I hope I addressed most of your concerns, suggestions
welcome.

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

--- Comment #9 from Franz Sirl  ---
(In reply to Segher Boessenkool from comment #8)
> I don't think it is a good idea to add workaround upon workaround to avoid
> some of the not-so-useful behaviours of -many.  Instead, we should just
> not use -many?

As I understand it -many is just one variation of the general problem with the
sticky flags. If we remove -many from the assembler, there are still other
sticky flags like -mvsx. Turning of any sticky flag is currently not supported
by the assembler AFAICS. So for example it's impossible to switch from a VSX
supporting assembler mode to an assembler mode without VSX via the .machine
pseudo-op. Or did I misread the the assembler source?

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

--- Comment #12 from Franz Sirl  ---
The emitted .machine is easy to fix, what's not so easy to fix is the intention
behind Segher's change that caused the wrong .machine.

Consider this source compiled with -mcpu=7400:

void ppcaltivecfunc (void) __attribute__ ((__target__ ("cpu=7400,altivec")));
void ppcaltivecfunc (void)
{
  asm ("lvx 0,0,11");
}


void ppc403func (void) __attribute__ ((__target__ ("cpu=403")));
void ppc403func (void)
{
  asm ("lvx 0,0,11");
}

Even though the compiler emitted a .machine "403" (or currently the buggy
"ppc"), the assembler won't barf on "lvx 0,0,11" in ppc403func(), because of
the sticky altivec flag.

That's why I suggested more control over the sticky flags via .machine
pseudo-ops, -mdotmachine-realcpu-resets-sticky or similar. That way the users
of pure assembly sources won't see a change in behaviour, but the compiler
still gains the full control it needs.
And I hope the suggested warning options to help the users of existing sources
with multi-cpu inline asm, since they maybe affected when the compiler switches
the assembler to a different mode by default.

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

--- Comment #16 from Franz Sirl  ---
Created attachment 51199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51199=edit
Patch version with minimum changes against GCC10

This is the minimum version of the patch, it fixes this PR but still avoids
code duplication. If this patch is acceptable, I'll fixup the formatting for
submission.

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

--- Comment #15 from Franz Sirl  ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to Franz Sirl from comment #12)
> > The emitted .machine is easy to fix, what's not so easy to fix is the
> > intention behind Segher's change that caused the wrong .machine.
> > 
> > Consider this source compiled with -mcpu=7400:
> > 
> > void ppcaltivecfunc (void) __attribute__ ((__target__ 
> > ("cpu=7400,altivec")));
> > void ppcaltivecfunc (void)
> > {
> >   asm ("lvx 0,0,11");
> > }
> > 
> > 
> > void ppc403func (void) __attribute__ ((__target__ ("cpu=403")));
> > void ppc403func (void)
> > {
> >   asm ("lvx 0,0,11");
> > }
> 
> "7400" and "403" are not supported target attribute values, fwiw (says the
> manual).

Hmm, I don't understand what you mean. As I read the manual any -mcpu= option
is allowed? And certainly this seems to do something as you can see in the
assembler source. The only strange thing is that -mppc is passed to the
assembler for -mcpu=7400, but in the assembler source it selects ".machine
power7"?

> > That's why I suggested more control over the sticky flags via .machine
> > pseudo-ops, -mdotmachine-realcpu-resets-sticky or similar. That way the
> > users of pure assembly sources won't see a change in behaviour, but the
> > compiler still gains the full control it needs.
> 
> We should just make this stuff work better / more intuitively :-)  We do
> not need to preserve unworkable (or buggy) semantics, in general.

In that case I'll send a minimum patch for now.

[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe

[sirl at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393

--- Comment #3 from Franz Sirl  ---
(In reply to Segher Boessenkool from comment #1)
> The -many is problematic, that is the whole point of this.  As in this
> example: on different subtargets there are different machine code
> translations for the same mnemonic!

But the way gas works there are never 2 active translations for the same
mnemonic, or? For example, for "-m403 -many" or "-many -m403" first the 403
mnemonics are added to the hash. Then, for -many, all the mnemonics are added
but duplicates are simply skipped.

Actually, since -many is sticky and always (except when CHECKING_P?? or AIX)
part of ASM_CPU_SPEC, the ".machine ppc" doesn't really help since -many is
also active for the .machine pseudo-op.

Maybe you meant to also remove -many from ASM_CPU_SPEC? In that case we would
have seen at least an assembler error, since there is no dcread for -mppc.