[Bug bootstrap/54447] gmp in source does not work on alphaev68-dec-osf5.1a

[htl10 at users dot sourceforge.net]

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

--- Comment #2 from Hin-Tak Leung  ---
Sorry I no longer recall the details from 5 years ago, but it seems that I have
managed to build later versions of gcc 3 years ago:

https://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00048.html

and I seemed to have figure out bug 44959 also, so this is perhaps no longer
relevant, especially given that the alpha platform is no longer supported.

Please feel free to close.

[Bug target/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

coypu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from coypu  ---
OK, after asking and learning how an alpha IEEE754 implementation should work
(with the kernel completing parts), it seems that it's a netbsd kernel bug.

Sorry for the noise.

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  ---
I think this is getting closer:

Index: constexpr.c
===
--- constexpr.c (revision 251607)
+++ constexpr.c (working copy)
@@ -3671,7 +3671,9 @@ static bool
 returns (tree *jump_target)
 {
   return *jump_target
-&& TREE_CODE (*jump_target) == RETURN_EXPR;
+&& (TREE_CODE (*jump_target) == RETURN_EXPR
+   || (TREE_CODE (*jump_target) == LABEL_DECL
+   && LABEL_DECL_CDTOR (*jump_target)));
 }

 static bool
@@ -4554,7 +4556,9 @@ cxx_eval_constant_expression (const constexpr_ctx

 case GOTO_EXPR:
   *jump_target = TREE_OPERAND (t, 0);
-  gcc_assert (breaks (jump_target) || continues (jump_target));
+  gcc_assert (breaks (jump_target) || continues (jump_target)
+ /* Allow for jumping to a cdtor_label.  */
+ || returns (jump_target));
   break;

 case LOOP_EXPR:
Index: cp-tree.h
===
--- cp-tree.h   (revision 251607)
+++ cp-tree.h   (working copy)
@@ -3833,6 +3833,11 @@ more_aggr_init_expr_args_p (const aggr_init_expr_a
 #define LABEL_DECL_CONTINUE(NODE) \
   DECL_LANG_FLAG_1 (LABEL_DECL_CHECK (NODE))

+/* Nonzero if NODE is the target for genericization of 'return' stmts
+   in constructors/destructors of targetm.cxx.cdtor_returns_this targets.  */
+#define LABEL_DECL_CDTOR(NODE) \
+  DECL_LANG_FLAG_2 (LABEL_DECL_CHECK (NODE))
+
 /* True if NODE was declared with auto in its return type, but it has
started compilation and so the return type might have been changed by
return type deduction; its declared return type should be found in
Index: decl.c
===
--- decl.c  (revision 251607)
+++ decl.c  (working copy)
@@ -15072,7 +15073,10 @@ start_preparsed_function (tree decl1, tree attrs,
   if (DECL_DESTRUCTOR_P (decl1)
   || (DECL_CONSTRUCTOR_P (decl1)
  && targetm.cxx.cdtor_returns_this ()))
-cdtor_label = create_artificial_label (input_location);
+{
+  cdtor_label = create_artificial_label (input_location);
+  LABEL_DECL_CDTOR (cdtor_label) = true;
+}

   start_fname_decls ();

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[zeccav at gmail dot com]

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

--- Comment #9 from Vittorio Zecca  ---
Applying the proposed fix and compiling the test case with
-fsanitize=undefined I get

testcase.c:8:3: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long int'
testcase.c:9:5: runtime error: negation of -9223372036854775808 cannot
be represented in type 'long int'; cast to an unsigned type to negate
this value to itself

as it should be.

[Bug libquadmath/81848] Add PowerPC support to libquadmath

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Author: meissner
Date: Fri Sep  1 22:10:57 2017
New Revision: 251613

URL: https://gcc.gnu.org/viewcvs?rev=251613=gcc=rev
Log:
2017-09-01  Michael Meissner  

PR libquadmath/81848
* configure.ac (powerpc*-linux*): Use attribute mode KC to create
complex __float128 on PowerPC instead of attribute mode TC.
* quadmath.h (__complex128): Likewise.
* configure: Regenerate.
* math/cbrtq.c (CBRT2): Use __float128 not long double.
(CBRT4): Likewise.
(CBRT2I): Likewise.
(CBRT4I): Likewise.
* math/j0q.c (U0): Likewise.
* math/sqrtq.c (sqrtq): Don't depend on implicit conversion
between __float128, instead explicitly convert the __float128
value to long double because the PowerPC does not allow __float128
and long double in the same expression.


Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/configure
trunk/libquadmath/configure.ac
trunk/libquadmath/math/cbrtq.c
trunk/libquadmath/math/j0q.c
trunk/libquadmath/math/sqrtq.c
trunk/libquadmath/quadmath.h

[Bug ipa/82027] [5/6/7/8 Regression] wrong code with -O3 -flto

[ssbssa at yahoo dot de]

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

--- Comment #4 from Domani Hannes  ---
(In reply to Martin Liška from comment #3)
> Note that original function does:
> 
> void calcPercent( const char *name,int pos,int size )
> {
>   int percent = 100*pos/size;
>   if( percent!=m_percent )
> m_percent = percent;
> }
> 
> So arguments are shifted by one. Martin can you please take a look?

In div0.exe.ltrans0.000i.cgraph it looks like this:

calcPercent.constprop (struct Combined * const this, int pos, int size)

Could this have anything to do with the argument shift?

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  ---
Uhm, no, we are not completely safe. Because in general, per 10.1.5, a
constexpr function is *not* supposed to contain goto statements, and our code
reflects that in various implicit/subtle ways. Thus the only completely Ok way
I see to fully fix the problem would be modeling somehow such special goto +
return this as plain returns, for example the returns helper function should
return true for those: the cxx_eval_statement_list loop would break as soon as
one is seen, consistently for the various targets.

[Bug target/82048] GCC bootstrap fails in stage1 on sparc-unknown-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX
Summary|[7 Regression] GCC  |GCC bootstrap fails in
   |bootstrap fails in stage1   |stage1 on
   |on sparc-unknown-linux-gnu  |sparc-unknown-linux-gnu

--- Comment #4 from Eric Botcazou  ---
> That's  (only 
> applies if you are building for 64-bit with the headers installed from a 
> 32-bit glibc build).

Is there any workaround other than downgrading to glibc 2.24 on SPARC?

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #10 from Paolo Carlini  ---
Well, if we are Ok with loosening a bit the gcc_assert which is firing for such
targets, I don't think we risk miscompiling anything, I think we are already
handling correctly the case of a return in user code which boils down to a goto
to a label immediately followed by return this.

I'm adding Jakub in CC, he hacked quite a bit related constexpr.c code in order
to completely fix constexpr-77467.C

Index: constexpr.c
===
--- constexpr.c (revision 251607)
+++ constexpr.c (working copy)
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
+#include "target.h"
 #include "cp-tree.h"
 #include "varasm.h"
 #include "c-family/c-objc.h"
@@ -4554,7 +4555,14 @@ cxx_eval_constant_expression (const constexpr_ctx

 case GOTO_EXPR:
   *jump_target = TREE_OPERAND (t, 0);
-  gcc_assert (breaks (jump_target) || continues (jump_target));
+  gcc_assert (breaks (jump_target) || continues (jump_target)
+ /* Allow for jumping to a cdtor_label.  */
+ || (targetm.cxx.cdtor_returns_this ()
+ && *jump_target
+ && TREE_CODE (*jump_target) == LABEL_DECL
+ && DECL_ARTIFICIAL (*jump_target)
+ && (DECL_CONSTRUCTOR_P (DECL_CONTEXT (*jump_target))
+ || DECL_DESTRUCTOR_P (DECL_CONTEXT
(*jump_target);
   break;

 case LOOP_EXPR:

[Bug sanitizer/82079] missing pointer overflow detection with -fsanitize=pointer-overflow

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
I forgot that pointer offsets are treated internally as signed even if they are
unsigned in the source code.  That seems like an important detail for the new
option to document.

Although to be honest, even regardless of the signedness issue, I'm having a
hard time coming up with a use case for this sort of instrumentation.  When is
it useful to only have pointer arithmetic overflow diagnosed without diagnosing
all expressions that form out-of-bounds/invalid pointers from valid ones?

[Bug target/82048] [7 Regression] GCC bootstrap fails in stage1 on sparc-unknown-linux-gnu

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Fri, 1 Sep 2017, aaro.koskinen at iki dot fi wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82048
> 
> --- Comment #2 from Aaro Koskinen  ---
> (In reply to Eric Botcazou from comment #1)
> > This looks like an issue with your libc.  Where does __nldbl_fprintf come
> > from?
> 
> It seems this was introduced by GLIBC 2.25. GCC does not define
> __LONG_DOUBLE_128__ with -m64 on SPARC so functions are redirected to 
> __nldbl_*
> versions.

That's  (only 
applies if you are building for 64-bit with the headers installed from a 
32-bit glibc build).  Someone using 2.25/2.26 branches on SPARC may wish 
to backport my fix to those branches following the usual glibc release 
branch rules (use git cherry-pick -x, post to libc-stable when 
backporting, remember to update the NEWS file on the branch to include the 
entry for the fix that scripts/list-fixed-bugs.py would add at release 
time since we don't make point releases from branches or track branch 
state of bugs in Bugzilla).

[Bug target/82048] [7 Regression] GCC bootstrap fails in stage1 on sparc-unknown-linux-gnu

[aaro.koskinen at iki dot fi]

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

--- Comment #2 from Aaro Koskinen  ---
(In reply to Eric Botcazou from comment #1)
> This looks like an issue with your libc.  Where does __nldbl_fprintf come
> from?

It seems this was introduced by GLIBC 2.25. GCC does not define
__LONG_DOUBLE_128__ with -m64 on SPARC so functions are redirected to __nldbl_*
versions.

[Bug c++/82080] New: ICE: Segmentation fault

[jamrial at gmail dot com]

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

Bug ID: 82080
   Summary: ICE: Segmentation fault
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamrial at gmail dot com
  Target Milestone: ---

Created attachment 42105
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42105=edit
Preprocessed output created with -freport-bug

[jamrial@ArchVM ~]$ c++ -std=c++17 -c ccBqWFGo.ii
/home/jamrial/range-v3/test/algorithm/partial_sort_copy.cpp: In lambda
function:
/home/jamrial/range-v3/test/algorithm/partial_sort_copy.cpp:50:44: internal
compiler error: Segmentation fault
 int* e = output + std::min(N, M);
^
0xd8570f crash_signal
/home/jamrial/gcc-svn/gcc/toplev.c:341
0x62730f hash_table<hash_map<tree_node*, tree_node*,
simple_hashmap_traits<default_hash_traits<tree_node*>, tree_node*>
>::hash_entry, xcallocator>::find_slot_with_hash(tree_node* const&, unsigned
int, insert_option)
/home/jamrial/gcc-svn/gcc/hash-table.h:874
0x6274ec hash_map<tree_node*, tree_node*,
simple_hashmap_traits<default_hash_traits<tree_node*>, tree_node*>
>::put(tree_node* const&, tree_node* const&)
/home/jamrial/gcc-svn/gcc/hash-map.h:136
0x775c09 register_local_specialization(tree_node*, tree_node*)
/home/jamrial/gcc-svn/gcc/cp/pt.c:1906
0x775c09 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:18153
0x7750ba tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:17549
0x77524c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/jamrial/gcc-svn/gcc/cp/pt.c:17070
0x624723 fold_non_dependent_expr(tree_node*)
/home/jamrial/gcc-svn/gcc/cp/constexpr.c:4936
0x761b21 build_non_dependent_expr(tree_node*)
/home/jamrial/gcc-svn/gcc/cp/pt.c:24955
0x81a82a build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code,
tree_node*, tree_code, tree_node**, int)
/home/jamrial/gcc-svn/gcc/cp/typeck.c:3954
0x71bcee cp_parser_binary_expression
/home/jamrial/gcc-svn/gcc/cp/parser.c:9271
0x71c474 cp_parser_assignment_expression
/home/jamrial/gcc-svn/gcc/cp/parser.c:9404
0x71c8a7 cp_parser_constant_expression
/home/jamrial/gcc-svn/gcc/cp/parser.c:9674
0x71d934 cp_parser_initializer_clause
/home/jamrial/gcc-svn/gcc/cp/parser.c:21765
0x71ed2b cp_parser_initializer
/home/jamrial/gcc-svn/gcc/cp/parser.c:21705
0x744710 cp_parser_init_declarator
/home/jamrial/gcc-svn/gcc/cp/parser.c:19547
0x74bc66 cp_parser_simple_declaration
/home/jamrial/gcc-svn/gcc/cp/parser.c:12980
0x74cbe5 cp_parser_block_declaration
/home/jamrial/gcc-svn/gcc/cp/parser.c:12805
0x74d6e9 cp_parser_declaration_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:12399
0x727253 cp_parser_statement
/home/jamrial/gcc-svn/gcc/cp/parser.c:10877

[jamrial@ArchVM ~]$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/lib/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/jamrial/gcc-svn/configure --prefix=/usr/local
--libdir=/usr/local/lib --libexecdir=/usr/local/lib
--mandir=/usr/local/share/man --infodir=/usr/local/share/info
--enable-languages=c,c++,lto --enable-shared --enable-threads=posix
--disable-bootstrap --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib
--disable-werror
Thread model: posix
gcc version 8.0.0 20170901 (experimental) (GCC)

[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Jakub Jelinek from comment #3)
> This is only with -O0, when we do not optimize away the dead loop.
> 
> Perhaps at -O0 we could just punt if it is a conditional memory use (and we
> haven't e.g. found a CLOBBER guarded with the same condition), though it
> could mean we wouldn't also warn for many places where we should warn.

It seems an acceptable trade-off as long as we warn with higher optimization
levels. That general limitation already exists with -O0.

[Bug c/82063] issues with arguments enabled by -Wall

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to jim.wilson from comment #2)
> I did already look at examples, and read the docs, and step through
> code in the debugger.  Posarg and negarg are integers, which are
> ignored for options that take a string as an argument.  So no, this
> doesn't work.

Ah, yes you are right!

> Note in optc-gen.awk, where the handle_generated_option call is
> generated, the fourth argument is always NULL. This is "const char
> *arg" which is the argument for options that take string arguments.
> The fifth argument, int value, is where the posarg/negarg value gets
> passed.  Also, note, in the file opts-common.c, in the function
> set_options, in the case CLVC_STRING, it uses only arg, it does not
> use value.  Since the posarg/negarg values end up in value here, they
> are ignored, and are useless.

It should be possible to change the behavior to adjust handle_generated_option
according to CLVC_STRING.

Alternatively, we could actually have overloads of handle_generated_option() so
that it does the right thing independently of what is passed.

The above seems a bug on its own independent of
-Walloc-alloc-size-larger-than=.

[Bug sanitizer/82079] missing pointer overflow detection with -fsanitize=pointer-overflow

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
That is not a bug, but how it is meant to work and how it works in clang too.

The IL doesn't make any distinction between s + 18446603339198873381UL and
s + -1317290203L or s -1317290203L, therefore we have to consider offsets with
MSB set as negative.  s + -1317290203L is perfectly fine for say s = malloc
(1317290213L) + 1317290211L;  -fsanitize=pointer-overflow is just a fast
overflow check, doesn't know the boundaries of anything, and works as if
((ssize_t) offset < 0 ? (uintptr_t) (ptr + offset) > ptr : (uintptr_t) (ptr +
offset) < ptr) runtime_failure (); with optimizations if offset is constant.

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  ---
I meant constexpr-77467.C

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  ---
Thanks.

What I quickly hacked can't be completely correct because it breaks
constexpr-7747.C on x86_64-linux. That most likely implies that since we are
using DECL_ARTIFICIAL labels in other cases we need at least something more
accurate to tell the special labels created for such targets.

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

--- Comment #4 from coypu  ---
sorry, I attached an object file rather than assembly. I am guessing it's good
enough.

I am passing only -mieee to make it fail.

(If I use instead -mieee -mfp-trap-mode=n, it doesn't fail, and I get a very
similar object, also attached).

It won't be surprising if the problem is not GCC, but I don't know enough about
alpha to know.

[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3

[dclarke at blastwave dot org]

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

--- Comment #30 from Dennis Clarke  ---
If that is on gcc master I have to backport to 7.2.0 and then 
give it a try.

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

--- Comment #3 from coypu  ---
Created attachment 42104
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42104=edit
-mieee -mfp-trap-mode=n, doesn't assert

[Bug sanitizer/82079] New: missing pointer overflow detection with -fsanitize=pointer-overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 82079
   Summary: missing pointer overflow detection with
-fsanitize=pointer-overflow
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor 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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

I've been experimenting with the new -fsanitize=pointer-overflow option to
better understand what it detects.  For example, I would expect both instances
of overflow/wrapping in the following test case to trigger an error at runtime
but only the second one does.  So either I don't understand what problems the
option is supposed to detect or it doesn't quite work.

$ cat t.c && /opt/notnfs/msebor/build/gcc-git-ubsan/gcc/xgcc -B
/opt/notnfs/msebor/build/gcc-git-ubsan/gcc -O2 -Wall -fsanitize=undefined
-fsanitize=pointer-overflow -L
/opt/notnfs/msebor/build/gcc-git-ubsan/x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs
t.c &&
LD_LIBRARY_PATH=/opt/notnfs/msebor/build/gcc-git-ubsan/x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs
./a.out
void __attribute__ ((noclone, noinline))
f (const char *s)
{
  volatile __SIZE_TYPE__ n = __SIZE_MAX__ - (__SIZE_TYPE__)s + 2;

  const char *p = s + n;

  __builtin_printf ("%p + %zu = %p\n", s, n, p);
}

int main (void)
{
  const char a[] = "123";
  f (a); // overflow not detected

  f ((char*)__SIZE_MAX__ - 1);   // overflow detected
}
0x7fff4e8440dc + 18446603339198873381 = 0x1
t.c:6:15: runtime error: pointer index expression with base 0xfffe
overflowed to 0x0001
0xfffe + 3 = 0x1

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[coypu at sdf dot org]

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

--- Comment #2 from coypu  ---
Created attachment 42103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42103=edit
-mieee, asserts

[Bug c/82078] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #5 from Andrew Pinski  ---
.

[Bug c/82078] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #4 from Zhendong Su  ---
So, it is indeed a bug and appears to be a recent regression.

[Bug c/82078] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Zhendong Su  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #3 from Zhendong Su  ---
Andrew, the miscompilation is still there by changing 

  struct S0 e[5][5];

to 

  struct S0 e[5][6];


$ gcc-trunk -O3 small.c
$ ./a.out
2
$ 
$ cat small.c
int printf(const char *, ...);
struct S0 {
  signed f4;
  signed f9 : 5;
} a[6][5], b = {2}

;
int c, d;
int fn1() {
  struct S0 e[5][6];
  struct S0 f;
  b = f = e[2][5] = a[5][0];
  if (d)
;
  else
return f.f9;
  e[c][45] = a[4][4];
}

int main() {
  fn1();
  printf("%d\n", b.f4);
  return 0;
}
$

[Bug c/82078] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> >  b = f = e[2][5] = a[5][0];
> 
> 
> You are writing past the array bounds of e[2] and reading past the array
> bounds of a there.

Actually not reading past the array bounds of a.  But past the bounds of e[2]
still stands.

[Bug c/82078] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
>  b = f = e[2][5] = a[5][0];


You are writing past the array bounds of e[2] and reading past the array bounds
of a there.

[Bug c/82078] New: wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu

[chengniansun at gmail dot com]

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

Bug ID: 82078
   Summary: wrong code at -O3 in both 32-bit and 64-bit modes on
x86_64-linux-gnu
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.0 20170901 (experimental) [trunk revision 251580] (GCC)
$ gcc-trunk -O3 small.c ; ./a.out
2
$ gcc-trunk -O0 small.c ; ./a.out
0
$ cat small.c
int printf(const char *, ...);
struct S0 {
  signed f4;
  signed f9 : 5;
} a[6][5], b = {2}

;
int c, d;
int fn1() {
  struct S0 e[5][5];
  struct S0 f;
  b = f = e[2][5] = a[5][0];
  if (d)
;
  else
return f.f9;
  e[c][45] = a[4][4];
}

int main() {
  fn1();
  printf("%d\n", b.f4);
  return 0;
}
$

[Bug fortran/82077] New: [7.1 Regression]: ICE on associating polymorphic array dummy with a type-guarded array section

[damian at sourceryinstitute dot org]

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

Bug ID: 82077
   Summary: [7.1 Regression]: ICE on associating polymorphic array
dummy with a type-guarded array section
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

$ cat poly-array-section-arg.f90 
 !! Gfortran 7.1.0 and 8.0.0 20170731 report an ICE when a
 !! polymorphic 1D array dummy argument of a child type is
 !! associated with a type-guarded, 1D section of a 2D
 !! polymorphic array actual argument declared as the parent
 !! type. Gfortran 5.4.0 and 6.4.0 compile the code without
 !! reporting any errors.
type parent
end type parent
type, extends(parent) :: child
end type
class(parent), allocatable :: foo(:,:)
allocate(child::foo(1,1))
select type(foo)
  class is (child)
call gfortran7_ICE(foo(1,:))
end select
contains
subroutine gfortran7_ICE(bar)
  class(child) bar(:)
end subroutine
end

$ gfortran --version
GNU Fortran (GCC) 8.0.0 20170731 (experimental)

$ gfortran poly-array-section-arg.f90 
poly-array-section-arg.f90:15:0:

 call gfortran7_ICE(foo(1,:))

internal compiler error: Segmentation fault
0xd933ef crash_signal
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/toplev.c:338
0x91d09d gfc_conv_scalarized_array_ref
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-array.c:3228
0x91e284 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-array.c:3382
0x94fa1d gfc_conv_variable
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-expr.c:2680
0x94beea gfc_conv_expr(gfc_se*, gfc_expr*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-expr.c:7816
0x92b7b6 gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-array.c:7138
0x948348 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-expr.c:5319
0x987b7a gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:406
0x9142e5 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans.c:1885
0x98c188 gfc_trans_block_construct(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:1934
0x914097 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans.c:1913
0x984643 gfc_trans_if_1
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:1434
0x98bc1a gfc_trans_if(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:1465
0x914107 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans.c:1905
0x98e53d gfc_trans_select_type_cases
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:2532
0x98e53d gfc_trans_select_type(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:3242
0x914007 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans.c:1933
0x98c188 gfc_trans_block_construct(gfc_code*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-stmt.c:1934
0x914097 trans_code
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans.c:1913
0x93dc68 gfc_generate_function_code(gfc_namespace*)
   
/home/rouson/Desktop/Builds/opencoarrays/prerequisites/downloads/gcc-teams/gcc/fortran/trans-decl.c:6365
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #42065|0   |1
is obsolete||

--- Comment #29 from Eric Botcazou  ---
Created attachment 42102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42102=edit
Tentative fix

Tested on Linux so far.

[Bug bootstrap/81926] [7 regression] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||6.4.0
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |7.3
Summary|go/parse.o differs between  |[7 regression] go/parse.o
   |stage2 and stage3   |differs between stage2 and
   ||stage3
  Known to fail||7.2.0

--- Comment #28 from Eric Botcazou  ---
This is a similar issue as PR bootstrap/77995, i.e. garbage collection:
  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00541.html
but for build_offset_type instead of build_complex_type.

[Bug sanitizer/82076] New: inconsistencies between sanitizer and -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 82076
   Summary: inconsistencies between sanitizer and
-Wstringop-overflow
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor 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, marxin at 
gcc dot gnu.org
  Target Milestone: ---

The two options, -fsanitize=undefined, and -Wstringop-overflow, detect disjoint
subsets of undefined accesses.  The inconsistency is due to GCC folding some
calls to functions like memset but not others.  For memcpy, the folder only
folds calls with constant sizes that are powers of 2.  This defeats the
-Wstringop-overflow warning which only considers calls to functions that
weren't folded.  The folded copy expressions (MEM_REFs) are then instrumented
and invalid access are detected.  Calls that aren't folded (i.e., those with
non-constant sizes or with constant sizes that aren't a power of 2), on the
other hand, are examined by -Wstringop-overflow, but they are not subject to
instrumentation.

This makes each option considerably less useful than it could be.  The
sanitizer would be improved by also instrumenting calls to the known memory and
string functions.  -Wstringop-overflow would benefit from delayed folding
(e.g., the folding could be deferred until after the tree-ssa-strlen pass has
run; that would have the nice effect of exposing optimization opportunities in
the strlen pass such as those discussed in bug 81703).

The example below shows the problem.  The first invocation of the compiler
issues a warning but the instrumented program runs to completion without
detecting the out-of-bounds access.  The second GCC invocation doesn't detect
the read past the end but the instrumented program does.  It would be an
improvement if all invocations (i.e., that of the compiler and the sanitized
program) detected the problem.  (It's understood that -Wstringop-overflow can
only detect invalid accesses when the size is either constant or in some range;
similarly, the sanitizer can only detect accesses that actually take place at
runtime, so neither solution can detect 100% of invalid accesses in every
program.)

$ cat t.c && set -x && for N in 3 4; do gcc -DN=$N -O2 -Wall
-fsanitize=undefined t.c && ./a.out ; done
int main (void)
{
char a[4];
const char *s = "1";
__builtin_memcpy (a, s, N);
__builtin_printf ("%s\n", a);
}
+ for N in 3 4
+ gcc -DN=3 -O2 -Wall -fsanitize=undefined t.c
t.c: In function ‘main’:
t.c:5:5: warning: ‘__builtin_memcpy’ reading 3 bytes from a region of size 2
[-Wstringop-overflow=]
 __builtin_memcpy (a, s, N);
 ^~
+ ./a.out
1
+ for N in 3 4
+ gcc -DN=4 -O2 -Wall -fsanitize=undefined t.c
+ ./a.out
t.c:5:5: runtime error: load of address 0x00400724 with insufficient space
for an object of type 'char'
0x00400724: note: pointer points here
  01 00 02 00 31 00 74 2e  63 00 00 00 01 1b 03 3b  30 00 00 00 05 00 00 00  34
fe ff ff 7c 00 00 00
  ^ 
1
++ printf '\033]0;%s on %s %s:%s\007' 'fc-25 (Twenty' x86_64 tor
/opt/notnfs/msebor/build/tmp

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[dclarke at blastwave dot org]

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

--- Comment #27 from Dennis Clarke  ---
Okay .. thank you.  So that should not be needed for a release version
bootstrap.

[Bug rtl-optimization/82024] [8 Regression] wrong code with -Og -fgcse-sm -frerun-cse-after-loop --param=max-combine-insns=3

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail|8.0 |

--- Comment #6 from Segher Boessenkool  ---
Fixed on trunk; backports pending.

[Bug rtl-optimization/82024] [8 Regression] wrong code with -Og -fgcse-sm -frerun-cse-after-loop --param=max-combine-insns=3

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Author: segher
Date: Fri Sep  1 16:54:53 2017
New Revision: 251607

URL: https://gcc.gnu.org/viewcvs?rev=251607=gcc=rev
Log:
combine: Fix for PR82024

With the testcase in the PR, with all the command line options mentioned
there, a (comparison) instruction becomes dead in fwprop1 but is not
deleted until all the way in rtl_dce.

Before combine this insn look like:

20: flags:CC=cmp(r106:DI,0x)
  REG_DEAD r106:DI
  REG_UNUSED flags:CC
  REG_EQUAL cmp(0,0x)

(note the only output is unused).

Combining some earlier insns gives

13: r106:DI=0
14: r105:DI=r101:DI+r103:DI

14+13+20 then gives

(parallel [
(set (reg:CC 17 flags)
(compare:CC (const_int 0 [0])
(const_int -1 [0x])))
(set (reg:DI 105)
(plus:DI (reg/v:DI 101 [ e ])
(reg:DI 103)))
])

which doesn't match; but the set of flags is dead, so combine makes the
set of r105 the whole new instruction, which it then places at i3.  But
that is wrong, because r105 is used after i2 but before i3!  We forget
to check for that in this case.

This patch fixes it.


PR rtl-optimization/82024
* combine.c (try_combine): If the combination result is a PARALLEL,
and we only need to retain the SET in there that would be placed
at I2, check that we can place that at I3 instead, before doing so.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

--- Comment #26 from Eric Botcazou  ---
> Ehere is this "BUILD_CONFIG" documented?

It's a developer option so it's not documented but in the configure script:

./configure --help

[...]

  --with-build-config='NAME NAME2...'
  use config/NAME.mk build configuration

[Bug target/81766] [8 Regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:924 caused by r250815

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  1 16:49:26 2017
New Revision: 251606

URL: https://gcc.gnu.org/viewcvs?rev=251606=gcc=rev
Log:
PR target/81766
* config/i386/i386.c (ix86_init_large_pic_reg): Return label instead of
void.
(ix86_init_pic_reg): Remember label from ix86_init_large_pic_reg, if
non-NULL
and preceded by NOTE_INSN_BASIC_BLOCK, swap the note and label.

* gcc.target/i386/pr81766.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr81766.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82071] Error in assign-ops in combination with FLT_EVAL_METHOD

[jsm28 at gcc dot gnu.org]

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

--- Comment #3 from Joseph S. Myers  ---
Author: jsm28
Date: Fri Sep  1 16:29:49 2017
New Revision: 251603

URL: https://gcc.gnu.org/viewcvs?rev=251603=gcc=rev
Log:
Fix excess precision handling of compound assignments (PR c/82071).

PR c/82071 reports how compound assignment operators such as += handle
excess precision inconsistently with the same operation done with a
plain assignment and binary operator.

There were (at least) two problems with how compound assignments
handled excess precision.  The EXCESS_PRECISION_EXPR for an argument
with excess precision was removed too early, resulting in
build_binary_op being called with an rhs operand whose type reflected
the evaluation format, so not having sufficient information to achieve
the intended semantics in all cases, and then the code called
c_fully_fold on the results of build_binary_op without allowing for
the possibility of an EXCESS_PRECISION_EXPR as the result, so leading
to double rounding of the result (first to its semantic type, then to
the type of the LHS of the assignment) instead of the intended single
rounding.

This patch fixes those problems by keeping EXCESS_PRECISION_EXPRs
further through build_modify_expr (and build_atomic_assign which it
calls) and only removing them locally where appropriate.

Note that while this patch should achieve *consistency*, that's
consistency with the understanding of C99 semantics that I originally
intended to implement.  For the particular case in the testcase, C11
semantics (from N1531) differ from that understanding of C99
semantics, in that an implicit conversion of an integer to floating
point can have excess precision.  I intend to implement those C11
semantics separately (conditional on flag_isoc11) (which will also
mean that building conditional expressions can produce a result with
excess precision even when the arguments lack excess precision, where
previously it could not), and not to close the bug until that is also
done.

Tested for x86_64-pc-linux-gnu.

PR c/82071
gcc/c:
* c-typeck.c (build_atomic_assign): Handle argument with excess
precision.  Ensure any EXCESS_PRECISION_EXPR is present in
argument passed to build_binary_op and convert_for_assignment but
not for call to c_fully_fold.
(build_modify_expr): Do not remove EXCESS_PRECISION_EXPR early.
Ensure build_binary_op is called with argument with original
semantic type.  Avoid calling c_fully_fold with an
EXCESS_PRECISION_EXPR from build_binary_op.

gcc/testsuite:
* gcc.target/i386/excess-precision-7.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/excess-precision-7.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82068] wrong double to uint64_t conversion with -mieee

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
It works for me.

Can you please post exact compile flags and perhaps failing assembly file?

[Bug c/82063] issues with arguments enabled by -Wall

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71905,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80545,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81650

--- Comment #3 from Martin Sebor  ---
There are a few outstanding problems here.  The option should be in -Wall but
is apparently enabled by default (this could be related to 80545).  Unsigned
arguments are accepted but the result is silently [mis]interpreted as signed
(ssize_t) which can have surprising effects.  One such effect is that there's
no way to specify sizes in excess of SSIZE_MAX (the handler should either treat
the value as unsigned or it should warn when the values is in excess of
SSIZE_MAX, and ignore the setting).  Suffixes other than KB and KiB are ignored
(looks like because of a typo in the test for "KB").

The suffix handling is only superficially tested so it's not too surprising
there are bugs in it.  It should be tested better and with the bugs fixed the
function should be moved to the option processing infrastructure where other
similar options can make use of it (this is tracked in bug 71905).

That said, I think the UNIT variable is handled correctly.  It's initialized to
1 and only reset to zero when the suffix is not recognized.  The handler
probably should issue a warning in that case.

Jim, since you've spent some time on this already and understand the problems,
please feel to propose a patch.  If you don't get to it I'll see if I can find
the time to fix at least some of these problems in stage 3.

[Bug c++/82067] G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[jupitercuso4 at gmail dot com]

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

--- Comment #3 from jupitercuso4 at gmail dot com ---
Created attachment 42101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42101=edit
Preprocessed source that triggers the internal error.

Preprocessed source attached. Compile it with g++ -std=c++11 -O3 test.i to
reproduce the error.

Thanks!

[Bug target/82074] [aarch64] vmlsq_f32 compiled into 2 instructions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

URL|https://godbolt.org/g/jWvmx |
   |S   |
 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
(In reply to ktkachov from comment #1)
> I believe the solution here is to fix the RTL pattern of the fnma4
> insn in aarch64-simd.md

I did spot that too:
https://gcc.gnu.org/ml/gcc/2017-06/msg00126.html

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Marek Polacek from comment #6)
> > This should fix the two issues above: 
> > 
> > --- a/gcc/convert.c
> > +++ b/gcc/convert.c
> > @@ -434,6 +434,12 @@ do_narrow (location_t loc,
> >  typex = lang_hooks.types.type_for_size (TYPE_PRECISION (typex),
> > TYPE_UNSIGNED (typex));
> >  
> > +  /* The type demotion below might cause doing unsigned arithmetic
> > + instead of signed, and thus hide overflow bugs.  */
> > +  if (!TYPE_UNSIGNED (typex)
> > +  && sanitize_flags_p (SANITIZE_SI_OVERFLOW))
> > +return NULL_TREE;
> > +
> 
> Shouldn't we check ex_form here too, and only punt if it is an operation
> problematic for the particular ubsan sanitization?
> There is no reason why we can't e.g. narrow BIT_AND_EXPR.

Good idea.

> Have you checked the shift and division cases?

I did, but try as I might, I'm not able to trigger a similar bug.

[Bug c++/82075] New: structured binding fails with empty base class

[barry.revzin at gmail dot com]

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

Bug ID: 82075
   Summary: structured binding fails with empty base class
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

struct B { };
struct D : B { int i; };

int main() {
auto [i] = D{};
}

On gcc 7.2, this fails with:

sb.cxx:5:10: error: cannot decompose class type ‘D’: both it and its base class
‘D’ have non-static data members
 auto [i] = D{};
  ^~~

But this is well-formed - all of D's non-static data members are public direct
members of D.

[Bug target/82012] [8 Regression] libitm build fails for s390x-linux-gnu

[krebbel at gcc dot gnu.org]

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

--- Comment #9 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Sep  1 15:58:05 2017
New Revision: 251601

URL: https://gcc.gnu.org/viewcvs?rev=251601=gcc=rev
Log:
S/390: PR82012: Implement CAN_INLINE_P target hook.

TARGET_CAN_INLINE_P must be implemented when supporting target
attributes.

gcc/ChangeLog:

2017-09-01  Andreas Krebbel  

PR target/82012
* config/s390/s390.c (s390_can_inline_p): New function.

gcc/testsuite/ChangeLog:

2017-09-01  Andreas Krebbel  

PR target/82012
* gcc.target/s390/target-attribute/pr82012.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/target-attribute/pr82012.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/82052] [8 Regression] ICE with "-O3 -m32" on x86_64-linux-gnu (internal compiler error: in pop_to_marker, at tree-ssa-scopedtables.c:71)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug tree-optimization/82052] [8 Regression] ICE with "-O3 -m32" on x86_64-linux-gnu (internal compiler error: in pop_to_marker, at tree-ssa-scopedtables.c:71)

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Fri Sep  1 15:32:15 2017
New Revision: 251600

URL: https://gcc.gnu.org/viewcvs?rev=251600=gcc=rev
Log:
PR tree-optimization/82052
* tree-ssa-scopedtables.c (avail_exprs_stack::lookup_avail_expr):
Always initialize the returned slot after a hash table miss
when INSERT is true.

PR tree-optimization/82052
* gcc.c-torture/compile/pr82052.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr82052.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-scopedtables.c

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Marek Polacek from comment #6)
> This should fix the two issues above: 
> 
> --- a/gcc/convert.c
> +++ b/gcc/convert.c
> @@ -434,6 +434,12 @@ do_narrow (location_t loc,
>  typex = lang_hooks.types.type_for_size (TYPE_PRECISION (typex),
> TYPE_UNSIGNED (typex));
>  
> +  /* The type demotion below might cause doing unsigned arithmetic
> + instead of signed, and thus hide overflow bugs.  */
> +  if (!TYPE_UNSIGNED (typex)
> +  && sanitize_flags_p (SANITIZE_SI_OVERFLOW))
> +return NULL_TREE;
> +

Shouldn't we check ex_form here too, and only punt if it is an operation
problematic for the particular ubsan sanitization?
There is no reason why we can't e.g. narrow BIT_AND_EXPR.

Have you checked the shift and division cases?

>/* But now perhaps TYPEX is as wide as INPREC.
>   In that case, do nothing special here.
>   (Otherwise would recurse infinitely in convert.  */
> @@ -895,7 +901,12 @@ convert_to_integer_1 (tree type, tree expr, bool dofold)
> TYPE_UNSIGNED (typex));
>  
>   if (!TYPE_UNSIGNED (typex))
> -   typex = unsigned_type_for (typex);
> +   {
> + /* Using unsigned arithmetic may hide overflow bugs.  */
> + if (sanitize_flags_p (SANITIZE_SI_OVERFLOW))
> +   break;
> + typex = unsigned_type_for (typex);
> +   }
>   return convert (type,
>   fold_build1 (ex_form, typex,
>convert (typex,

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
This should fix the two issues above: 

--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -434,6 +434,12 @@ do_narrow (location_t loc,
 typex = lang_hooks.types.type_for_size (TYPE_PRECISION (typex),
TYPE_UNSIGNED (typex));

+  /* The type demotion below might cause doing unsigned arithmetic
+ instead of signed, and thus hide overflow bugs.  */
+  if (!TYPE_UNSIGNED (typex)
+  && sanitize_flags_p (SANITIZE_SI_OVERFLOW))
+return NULL_TREE;
+
   /* But now perhaps TYPEX is as wide as INPREC.
  In that case, do nothing special here.
  (Otherwise would recurse infinitely in convert.  */
@@ -895,7 +901,12 @@ convert_to_integer_1 (tree type, tree expr, bool dofold)
TYPE_UNSIGNED (typex));

  if (!TYPE_UNSIGNED (typex))
-   typex = unsigned_type_for (typex);
+   {
+ /* Using unsigned arithmetic may hide overflow bugs.  */
+ if (sanitize_flags_p (SANITIZE_SI_OVERFLOW))
+   break;
+ typex = unsigned_type_for (typex);
+   }
  return convert (type,
  fold_build1 (ex_form, typex,
   convert (typex,

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Yeah, one thing is the trunc1: case that uses do_narrow (for
MINUS_EXPR/PLUS_EXPR/MULT_EXPR), another thing is that the LSHIFT/RSHIFT_EXPR
narrowing might be problematic for -fsanitize=shift (needs to be verified),
another thing is the NEGATE_EXPR case, and another thing to verify is the
division narrowing.

[Bug target/82074] [aarch64] vmlsq_f32 compiled into 2 instructions

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Target||aarch64
 Status|UNCONFIRMED |NEW
   Keywords|TREE|missed-optimization
   Last reconfirmed||2017-09-01
  Component|tree-optimization   |target
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.4.1, 6.4.1, 7.2.1,
   ||8.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all releases that I have access to.
Interestingly things go bad in combine. Before combine the correct RTL is
formed and the expected fnmav4sf4 insn is matched:

(insn 8 5 13 2 (set (reg:V4SF 78)
(fma:V4SF (reg/v:V4SF 76 [ b ])
(neg:V4SF (reg/v:V4SF 77 [ c ]))
(reg/v:V4SF 75 [ a ]))) "vmls.c":25 1562 {fnmav4sf4}
 (expr_list:REG_DEAD (reg/v:V4SF 77 [ c ])
(expr_list:REG_DEAD (reg/v:V4SF 76 [ b ])
(expr_list:REG_DEAD (reg/v:V4SF 75 [ a ])
(nil)


but after combine we end up with:
(insn 4 3 5 2 (set (reg/v:V4SF 77 [ c ])
(neg:V4SF (reg:V4SF 34 v2 [ c ]))) "vmls.c":24 1532 {negv4sf2}
 (expr_list:REG_DEAD (reg:V4SF 34 v2 [ c ])
(nil)))

(insn 13 8 14 2 (set (reg/i:V4SF 32 v0)
(fma:V4SF (reg/v:V4SF 77 [ c ])
(reg:V4SF 33 v1 [ b ])
(reg:V4SF 32 v0 [ a ]))) "vmls.c":26 1542 {fmav4sf4}
 (expr_list:REG_DEAD (reg/v:V4SF 77 [ c ])
(expr_list:REG_DEAD (reg:V4SF 33 v1 [ b ])
(nil


Combine tries and fails to match:
Trying 2 -> 8:
Failed to match this instruction:
(set (reg:V4SF 78)
(fma:V4SF (neg:V4SF (reg/v:V4SF 77 [ c ]))
(reg/v:V4SF 76 [ b ])
(reg:V4SF 32 v0 [ a ])))


What I think is going on is that the target pattern for fnmav4sf4 specifies
non-canonical RTL because in:
(fma:V4SF (reg/v:V4SF 76 [ b ])
(neg:V4SF (reg/v:V4SF 77 [ c ]))
(reg/v:V4SF 75 [ a ])))

The first two operands of an fma are the multiplication operands, which are
commutative, so by RTL canonicalization rules the more complex expression must
go into the first operand, that would be the neg.
So combine/simplify-rtx canonicalizes the expression and tries to match it and
then breaks it up when it doesn't match.

I believe the solution here is to fix the RTL pattern of the fnma4 insn
in aarch64-simd.md

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
But that's only a half of the problem here, for

  i = -lmin;

we produce

  i = (int) -(unsigned int) lmin;

thus again hiding that overflow.

[Bug tree-optimization/82052] [8 Regression] ICE with "-O3 -m32" on x86_64-linux-gnu (internal compiler error: in pop_to_marker, at tree-ssa-scopedtables.c:71)

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
What an interesting little bug.  A patch is in testing.

The reason it's so hard to trigger is you need a very specific and presumably
unusual set of circumstances to trigger the bug.

Enter object1 into slot X
Enter object2 into slot Y (after rehashing due to conflict)

Y must be < X to trigger the bug because the next step requires a reallocation
of the table.  WHen we reallocate we walk through the old table from first to
last and insert the objects into the new table.

That results in object2 going into slot X and object1 going into slot Y in the
new table.

Then we remove object2 from the hash table.  This leaves slot X in a deleted
state.

Then we lookup object3 and get back slot X which will be put into an empty
state.  Since we didn't get a hit in the table, we try to lookup an alternate
form that would allow us to prove object3 has a constant value.  That succeeds
and we never re-initialize slot X, leaving it in the deleted state.

The deleted state is important as it also means uninitialized.  The generic
bits of hash-table.h (reasonably) assume that a slot in the empty/uninitialized
state  implies that no other objects with a conflicting hash are in the table.

So when we try to lookup object1 in the table, it misses because slot1 is
uninitialized/empty -- which triggers the assert as we know object1 must be in
the hash table.

The fix is to ensure we initialize the slot properly after a miss, but when we
are able to prove the expression has a constant value.

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
(In reply to Jakub Jelinek from comment #2)
> This is the effect of premature optimization in convert.c, perhaps for
> -fsanitize=signed-integer-overflow we should punt in do_narrow if the
> argument type is signed.

This was my first idea too.  I'll send a patch for that.

[Bug tree-optimization/82074] New: [aarch64] vmlsq_f32 compiled into 2 instructions

[gcc.account at lemaitre dot re]

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

Bug ID: 82074
   Summary: [aarch64] vmlsq_f32 compiled into 2 instructions
   Product: gcc
   Version: 7.2.0
   URL: https://godbolt.org/g/jWvmxS
Status: UNCONFIRMED
  Keywords: TREE
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.account at lemaitre dot re
  Target Milestone: ---

Created attachment 42100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42100=edit
simplest example showing the bug

On aarch64, the Neon intrinsic "vmlsq_f32" is compiled into:
fneg  v1.4s, v1.4s
fmla  v0.4s, v1.4s, v2.4s

instead of:
fmls  v0.4s, v1.4s, v2.4s

The same output is produced by all the following expressions:
vmlsq_f32(a, b, c)
a - b*c
vsubq_f32(a, vmulq_f32(b, c))


The example has been compiled with gcc -O3
I tested on GCC 4.8.5, GCC 6.3.0 and GCC 7.2.0. All of them has the bug.
The bug is also present at -O1, but with a slightly different output:
fmulv1.4s, v1.4s, v2.4s
fsubv0.4s, v0.4s, v1.4s

If it can help, here is a godbolt link that shows the bug:
https://godbolt.org/g/jWvmxS

Sometimes, depending on the surrounding, it is successfully converted into the
FMLS instruction, but never on the attached example.

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Why do you use LLONG_MIN for long variable?
Better testcase:
int
main ()
{
  long long l = -__LONG_LONG_MAX__ - 1;
  int i = 0;
  i -= l;
  i = -l;
  return 0;
}

This is the effect of premature optimization in convert.c, perhaps for
-fsanitize=signed-integer-overflow we should punt in do_narrow if the argument
type is signed.

[Bug sanitizer/82072] sanitizer does not detect an overflow from LLONG_MIN

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

We have
i = i - lmin
where i is int and lmin is long int, so what we should produce is
i = (int) ((long int) i - lmin)
but instead we produce
i = (int) ((unsigned int) i - (unsigned int) lmin);

This is do_narrow at work.

[Bug tree-optimization/82073] New: internal compiler error: in pop_to_marker, at tree-ssa-scopedtables.c

[vsevolod.livinskij at frtk dot ru]

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

Bug ID: 82073
   Summary: internal compiler error: in pop_to_marker, at
tree-ssa-scopedtables.c
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

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

The testcase is huge and weird, but it seems to be key to this ICE. Also
Creduce has failed to reduce it even further.

>$ g++ -std=c++11 -w -c -O2 repr.cpp 
during GIMPLE pass: dom
repr.cpp: In function ‘void foo()’:
repr.cpp:176:6: internal compiler error: in pop_to_marker, at
tree-ssa-scopedtables.c:71
 void foo() {
  ^~~
0x104bc3e avail_exprs_stack::pop_to_marker()
/home/vsevolod/workspace/gcc-dev/trunk/gcc/tree-ssa-scopedtables.c:71
0xf9cbb3 dom_opt_dom_walker::after_dom_children(basic_block_def*)
/home/vsevolod/workspace/gcc-dev/trunk/gcc/tree-ssa-dom.c:1379
0x15716e7 dom_walker::walk(basic_block_def*)
/home/vsevolod/workspace/gcc-dev/trunk/gcc/domwalk.c:325
0xfa0dc8 execute
/home/vsevolod/workspace/gcc-dev/trunk/gcc/tree-ssa-dom.c:691
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/81902] new -fsanitize=pointer-overflow option undocumented

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  1 13:47:04 2017
New Revision: 251596

URL: https://gcc.gnu.org/viewcvs?rev=251596=gcc=rev
Log:
PR sanitizer/81902
* doc/invoke.texi: Document -fsanitize=pointer-overflow.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  1 13:46:14 2017
New Revision: 251595

URL: https://gcc.gnu.org/viewcvs?rev=251595=gcc=rev
Log:
PR sanitizer/81923
* asan.c (create_odr_indicator): Strip name encoding from assembler
name before appending it after __odr_asan_.

* gcc.dg/asan/pr81923.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr81923.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug target/82015] PowerPC should check if 2nd argument to __builtin_unpackv1ti and similar functions is 0 or 1

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bill Schmidt  ---
Fixed.

[Bug ipa/81128] Function multi-versioning does not work with -O

[billy.o.mahony at intel dot com]

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

--- Comment #12 from Billy O'Mahony  ---
Thanks, Martin. That's great. Can you update the ticket with the fixed versions
when you get a chance? 

(In reply to Martin Liška from comment #11)
> (In reply to Billy O'Mahony from comment #10)
> > Hi All,
> > 
> > thanks to Martin, Nathan and Richard for working on and fixing this issue.
> > 
> > Can anyone say if the fix will be back ported to future point releases of
> > the 5.x, 6.x, 7.x versions? 
> > 
> > Regards,
> > Billy
> 
> Well, in general I don't tend to backport multiversioning patches as many
> dependent patches were applied in GCC 8 cycle. But this one is quite
> independent. I'm planning to do backports next week.

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[dclarke at blastwave dot org]

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

--- Comment #25 from Dennis Clarke  ---
So this seems to be related to some env var BUILD_CONFIG ? 

Ehere is this "BUILD_CONFIG" documented?

[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This is only with -O0, when we do not optimize away the dead loop.

Perhaps at -O0 we could just punt if it is a conditional memory use (and we
haven't e.g. found a CLOBBER guarded with the same condition), though it could
mean we wouldn't also warn for many places where we should warn.

[Bug c++/81917] internal compiler error: in finish_member_declaration, at cp/semantics.c:3004

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The reporter claimed the source isn't valid.  Can't try clang because it
doesn't handle libstdc++ C++17 deductions.

[Bug sanitizer/82072] New: sanitizer does not detect on overflow from LLONG_MIN

[zeccav at gmail dot com]

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

Bug ID: 82072
   Summary: sanitizer does not detect on overflow from LLONG_MIN
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
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, marxin at 
gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
 Build: trunk 251201

/* sanitizer should emit runtime error messages */
#include 
int main()
{
long lmin=LLONG_MIN;
int  i=0;
i -= lmin; /*signed integer overflow*/
i = -lmin; /*negation of -9223372036854775808 cannot be represented in type
'long'*/
return 0;
}

[Bug ipa/81128] Function multi-versioning does not work with -O

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška  ---
(In reply to Billy O'Mahony from comment #10)
> Hi All,
> 
> thanks to Martin, Nathan and Richard for working on and fixing this issue.
> 
> Can anyone say if the fix will be back ported to future point releases of
> the 5.x, 6.x, 7.x versions? 
> 
> Regards,
> Billy

Well, in general I don't tend to backport multiversioning patches as many
dependent patches were applied in GCC 8 cycle. But this one is quite
independent. I'm planning to do backports next week.

[Bug tree-optimization/82059] [8 Regression] ICE in dump_profile, at gimple-pretty-print.c:89

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
Fixed.

[Bug tree-optimization/82059] [8 Regression] ICE in dump_profile, at gimple-pretty-print.c:89

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Fri Sep  1 13:02:37 2017
New Revision: 251591

URL: https://gcc.gnu.org/viewcvs?rev=251591=gcc=rev
Log:
Fix profile update in tree-ssa-isolate-paths.c (PR tree-optimization/82059).

2017-09-01  Martin Liska  

PR tree-optimization/82059
* gimple-ssa-isolate-paths.c (isolate_path): Add profile and
frequency only when an edge is redirected.
2017-09-01  Martin Liska  

PR tree-optimization/82059
* gcc.dg/tree-ssa/pr82059.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr82059.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-isolate-paths.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/82062] [8 regression] simple conditional expressions no longer folded

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
That would be nice, but to fix this PR, I think all we need is to re-add the
optimization I removed in PR81814 (but only if the precision match).

[Bug c/82071] Error in assign-ops in combination with FLT_EVAL_METHOD

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-01
   Assignee|unassigned at gcc dot gnu.org  |jsm28 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Joseph S. Myers  ---
Working on patches (first making compound assignments consistent with
arithmetic operators in implementing the understanding of C99 semantics where
integer conversions to floating point has no excess precision and 0x10001241 is
the right answer, then making binary operators and conditional expressions also
support post-N1531 C11 semantics where such implicit conversions have excess
precision and 0x10001235 is the right answer).

[Bug bootstrap/82045] [8 regression] SPARC bootstrap broken: ICE in emit_library_call_value_1, at calls.c:4565

[rsandifo at gcc dot gnu.org]

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

--- Comment #12 from rsandifo at gcc dot gnu.org  
---
(In reply to r...@cebitec.uni-bielefeld.de from comment #11)
> Unfortunately, the patch breaks x86 bootstrap (e.g. for the 32-bit
> _multc3.o), both in i386-pc-solaris2.* and x86_64-pc-linux-gnu compilers:
> 
> $ cc1 -fpreprocessed libgcc2.i -quiet -o libgcc2.s
> 
> Thread 2 hit Breakpoint 1, fancy_abort (
> file=0x98dbb80 "/vol/gcc/src/hg/trunk/local/gcc/calls.c", line=4571, 
> function=0x98dc691  libcall_type, machine_mode, int, std::pair machine_mode>*)::__FUNCTION__> "emit_library_call_value") at
> /vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:1488
> 1488  internal_error ("in %s, at %s:%d", function, trim_filename (file),
> line);
> 
> #0  fancy_abort (file=0x98dbb80 "/vol/gcc/src/hg/trunk/local/gcc/calls.c", 
> line=4571, 
> function=0x98dc691  libcall_type, machine_mode, int, std::pair machine_mode>*)::__FUNCTION__> "emit_library_call_value") at
> /vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:1488
> #1  0x085fa6de in emit_library_call_value (retval=1, orgfun=0xfe7894a0, 
> value=0x0, fn_type=LCT_CONST, outmode=E_TFmode, nargs=3, args=0x8046970)
> at /vol/gcc/src/hg/trunk/local/gcc/calls.c:4570
> #2  0x085e8409 in emit_library_call_value (fun=0xfe7894a0, value=0x0, 
> fn_type=LCT_CONST, outmode=E_TFmode, arg1=0xfe789460,
> arg1_mode=E_TFmode, 
> arg2=0xfe789480, arg2_mode=E_TFmode)
> at /vol/gcc/src/hg/trunk/local/gcc/rtl.h:3873
> #3  0x089ed51e in expand_binop (mode=E_TFmode, binoptab=smul_optab, 
> op0=0xfe789460, op1=0xfe789480, target=0xfe789440, unsignedp=0, 
> methods=OPTAB_LIB_WIDEN) at /vol/gcc/src/hg/trunk/local/gcc/optabs.c:1763
> #4  0x08738653 in expand_mult (mode=E_TFmode, op0=0xfe789460,
> op1=0xfe789480, 
> target=0xfe789440, unsignedp=0)
> at /vol/gcc/src/hg/trunk/local/gcc/expmed.c:3455
> #5  0x0875ddb3 in expand_expr_real_2 (ops=0x8047190, target=0xfe789440, 
> tmode=E_TFmode, modifier=EXPAND_NORMAL)
> at /vol/gcc/src/hg/trunk/local/gcc/expr.c:8827
> #6  0x08611992 in expand_gimple_stmt_1 (stmt=0xfe610104)
> at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3691
> #7  0x08611bbc in expand_gimple_stmt (stmt=0xfe610104)
> at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3751
> #8  0x0861898c in expand_gimple_basic_block (bb=0xfe784080, 
> disable_tail_calls=false)
> at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5750
> #9  0x0861a160 in (anonymous namespace)::pass_expand::execute
> (this=0xa31ea30, 
> fun=0xfe758068) at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6357
> #10 0x08a21b8e in execute_one_pass (pass=0xa31ea30)
> at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2495
> #11 0x08a21ec9 in execute_pass_list_1 (pass=0xa31ea30)
> at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2584
> #12 0x08a21f43 in execute_pass_list (fn=0xfe758068, pass=0xa31c300)
> at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2595
> #13 0x0865bdec in cgraph_node::expand (this=0xfe777000)
> at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2054
> #14 0x0865c7c6 in output_in_order ()
> at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2296
> #15 0x0865cf5a in symbol_table::compile (this=0xfe6070c8)
> at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2537
> #16 0x0865d1b2 in symbol_table::finalize_compilation_unit (this=0xfe6070c8)
> at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2631
> #17 0x08b327b5 in compile_file ()
> at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:496
> #18 0x08b34b12 in do_compile ()
> at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2037
> #19 0x08b34dd8 in toplev::main (this=0x80475fe, argc=6, argv=0x804762c)
> at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2172
> #20 0x0963505a in main (argc=6, argv=0x804762c)
> at /vol/gcc/src/hg/trunk/local/gcc/main.c:39
> 
> (gdb) p mode
> $12 = E_BLKmode
> (gdb) p val
> $13 = (rtx) 0x0

Yeah, I've been testing a fixed version today.  I hope to post soon
once I've got a bit more coverage.

[Bug c/65455] typeof _Atomic fails

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-01
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/82045] [8 regression] SPARC bootstrap broken: ICE in emit_library_call_value_1, at calls.c:4565

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Unfortunately, the patch breaks x86 bootstrap (e.g. for the 32-bit
_multc3.o), both in i386-pc-solaris2.* and x86_64-pc-linux-gnu compilers:

$ cc1 -fpreprocessed libgcc2.i -quiet -o libgcc2.s

Thread 2 hit Breakpoint 1, fancy_abort (
file=0x98dbb80 "/vol/gcc/src/hg/trunk/local/gcc/calls.c", line=4571, 
function=0x98dc691 *)::__FUNCTION__> "emit_library_call_value") at
/vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:1488
1488  internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);

#0  fancy_abort (file=0x98dbb80 "/vol/gcc/src/hg/trunk/local/gcc/calls.c", 
line=4571, 
function=0x98dc691 *)::__FUNCTION__> "emit_library_call_value") at
/vol/gcc/src/hg/trunk/local/gcc/diagnostic.c:1488
#1  0x085fa6de in emit_library_call_value (retval=1, orgfun=0xfe7894a0, 
value=0x0, fn_type=LCT_CONST, outmode=E_TFmode, nargs=3, args=0x8046970)
at /vol/gcc/src/hg/trunk/local/gcc/calls.c:4570
#2  0x085e8409 in emit_library_call_value (fun=0xfe7894a0, value=0x0, 
fn_type=LCT_CONST, outmode=E_TFmode, arg1=0xfe789460, arg1_mode=E_TFmode, 
arg2=0xfe789480, arg2_mode=E_TFmode)
at /vol/gcc/src/hg/trunk/local/gcc/rtl.h:3873
#3  0x089ed51e in expand_binop (mode=E_TFmode, binoptab=smul_optab, 
op0=0xfe789460, op1=0xfe789480, target=0xfe789440, unsignedp=0, 
methods=OPTAB_LIB_WIDEN) at /vol/gcc/src/hg/trunk/local/gcc/optabs.c:1763
#4  0x08738653 in expand_mult (mode=E_TFmode, op0=0xfe789460, op1=0xfe789480, 
target=0xfe789440, unsignedp=0)
at /vol/gcc/src/hg/trunk/local/gcc/expmed.c:3455
#5  0x0875ddb3 in expand_expr_real_2 (ops=0x8047190, target=0xfe789440, 
tmode=E_TFmode, modifier=EXPAND_NORMAL)
at /vol/gcc/src/hg/trunk/local/gcc/expr.c:8827
#6  0x08611992 in expand_gimple_stmt_1 (stmt=0xfe610104)
at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3691
#7  0x08611bbc in expand_gimple_stmt (stmt=0xfe610104)
at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:3751
#8  0x0861898c in expand_gimple_basic_block (bb=0xfe784080, 
disable_tail_calls=false)
at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:5750
#9  0x0861a160 in (anonymous namespace)::pass_expand::execute (this=0xa31ea30, 
fun=0xfe758068) at /vol/gcc/src/hg/trunk/local/gcc/cfgexpand.c:6357
#10 0x08a21b8e in execute_one_pass (pass=0xa31ea30)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2495
#11 0x08a21ec9 in execute_pass_list_1 (pass=0xa31ea30)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2584
#12 0x08a21f43 in execute_pass_list (fn=0xfe758068, pass=0xa31c300)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2595
#13 0x0865bdec in cgraph_node::expand (this=0xfe777000)
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2054
#14 0x0865c7c6 in output_in_order ()
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2296
#15 0x0865cf5a in symbol_table::compile (this=0xfe6070c8)
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2537
#16 0x0865d1b2 in symbol_table::finalize_compilation_unit (this=0xfe6070c8)
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2631
#17 0x08b327b5 in compile_file ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:496
#18 0x08b34b12 in do_compile ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2037
#19 0x08b34dd8 in toplev::main (this=0x80475fe, argc=6, argv=0x804762c)
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2172
#20 0x0963505a in main (argc=6, argv=0x804762c)
at /vol/gcc/src/hg/trunk/local/gcc/main.c:39

(gdb) p mode
$12 = E_BLKmode
(gdb) p val
$13 = (rtx) 0x0

[Bug bootstrap/81926] go/parse.o differs between stage2 and stage3

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparc64-sun-solaris2.10 |
   Host|sparc64-sun-solaris2.10 |
  Build|sparc64-sun-solaris2.10 |

--- Comment #24 from Eric Botcazou  ---
This can be reproduced on x86-64/Linux with --with-build-config=no:

Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc-7.2.0/configure --build=x86_64-suse-linux
--prefix=/home/eric/install/gcc-7.2.0 --enable-languages=c,c++,go
--enable-__cxa_atexit --disable-nls --with-build-config=no
Thread model: posix
gcc version 7.2.0 (GCC) 

make[3]: Leaving directory '/home/eric/build/gcc-7.2.0'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/go/parse.o differs
Makefile:24421: recipe for target 'compare' failed
make[2]: *** [compare] Error 1

[Bug c/81887] pragma omp ordered simd ignored under -fopenmp-simd

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Sep  1 11:25:39 2017
New Revision: 251585

URL: https://gcc.gnu.org/viewcvs?rev=251585=gcc=rev
Log:
PR c/81887
c-family/
* c-pragma.c (omp_pragmas): Move "ordered" entry from here to ...
(omp_pragmas_simd): ... here.
* c-omp.c (c_finish_omp_ordered): If clauses isn't simd clause alone,
create new clauses list containing just simd clause.
c/
* c-parser.c (c_parser_omp_ordered): Handle -fopenmp-simd.
cp/
* parser.c (cp_parser_omp_ordered): Handle -fopenmp-simd.
fortran/
* parse.c (decode_omp_directive): Use matchs instead of matcho for
end ordered and ordered directives, except for ordered depend.  For
-fopenmp-simd and ordered depend, reject the stmt.
* trans-openmp.c (gfc_trans_omp_ordered): For -fopenmp-simd ignore
threads clause and if simd clause isn't present, just translate the
body.
testsuite/
* c-c++-common/gomp/pr81887.c: New test.
* gfortran.dg/gomp/pr81887.f90: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr81887.c
trunk/gcc/testsuite/gfortran.dg/gomp/pr81887.f90
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-omp.c
trunk/gcc/c-family/c-pragma.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/trans-openmp.c
trunk/gcc/testsuite/ChangeLog

[Bug c/82071] Error in assign-ops in combination with FLT_EVAL_METHOD

[willemw at ace dot nl]

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

--- Comment #1 from Willem Wakker  ---
That's the problem when you have too many answers: the right answer should be
0x10001235

[Bug c/82071] New: Error in assign-ops in combination with FLT_EVAL_METHOD

[willemw at ace dot nl]

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

Bug ID: 82071
   Summary: Error in assign-ops in combination with
FLT_EVAL_METHOD
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willemw at ace dot nl
  Target Milestone: ---

Compiler:
  Target: i686-linux-gnu
  GNU C (Ubuntu 4.8.4-2ubuntu1~14.04.3) version 4.8.4 (i686-linux-gnu)
  Compile option: -std=c99

The 4 expressions in the program below should give all the same answer.
When using the mentioned compiler that has FLT_EVAL_METHOD=2 gives
3 different answers.

The program:

# include 
# include 

int
main()
{
float f = 1.0;
double d = 1.0;
int i, j;

#ifdef FLT_EVAL_METHOD
printf("FLT_EVAL_METHOD: %d\n", FLT_EVAL_METHOD );
#endif

i = 0x10001234;
i += f;
printf("i += f;  \t0x%x\n", i );

i = 0x10001234;
i += 1.0f;
printf("i += 1.0f;\t0x%x\n", i );

i = 0x10001234;
i = i + f;
printf("i = i + f;\t0x%x\n", i );

i = 0x10001234;
i = i + 1.0f;
printf("i = i + 1.0f;\t0x%x\n", i );

}

The results:

FLT_EVAL_METHOD: 2
i += f; 0x10001240
i += 1.0f;  0x10001235
i = i + f;  0x10001241
i = i + 1.0f;   0x10001241

The correct answers is 0x10001241: the expression should be evaluated in long
double.

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #27 from Xi Ruoyao  ---
(In reply to Jonathan Wakely from comment #26)
> The demangled names are not in a canonical/standardized format, or
> unambiguous, or portable between different compilers, so that isn't a
> complete solution.

Yes.  Could GDB search the symbol with linkage name?

[Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely  ---
The demangled names are not in a canonical/standardized format, or unambiguous,
or portable between different compilers, so that isn't a complete solution.

[Bug c++/81942] ICE on empty constexpr constructor with C++14

[thopre01 at gcc dot gnu.org]

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

--- Comment #7 from Thomas Preud'homme  ---
Hi Paolo,

Thanks for working on this.

(In reply to Paolo Carlini from comment #6)
> It would be nice if somebody with a fully functional ARM toolchain could
> check whether something like the below at least avoids the ICE without
> causing any regressions. I hope it does.
> 
> Index: constexpr.c
> ===
> --- constexpr.c   (revision 251553)
> +++ constexpr.c   (working copy)
> @@ -3679,7 +3679,7 @@ breaks (tree *jump_target)
>  {
>return *jump_target
>  && ((TREE_CODE (*jump_target) == LABEL_DECL
> -  && LABEL_DECL_BREAK (*jump_target))
> +  && (LABEL_DECL_BREAK (*jump_target) || DECL_ARTIFICIAL (*jump_target)))
>   || TREE_CODE (*jump_target) == EXIT_EXPR);
>  }

The patch works for me on the testcase I provided, that is compilation process
returns a success error code instead of ICEing.

Best regards.

[Bug ipa/81128] Function multi-versioning does not work with -O

[billy.o.mahony at intel dot com]

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

--- Comment #10 from Billy O'Mahony  ---
Hi All,

thanks to Martin, Nathan and Richard for working on and fixing this issue.

Can anyone say if the fix will be back ported to future point releases of the
5.x, 6.x, 7.x versions? 

Regards,
Billy

[Bug c++/82040] [7/8 Regression] ICE with -Wbool-operation and ~

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Sep  1 09:24:54 2017
New Revision: 251582

URL: https://gcc.gnu.org/viewcvs?rev=251582=gcc=rev
Log:
PR c++/82040
* typeck.c (cp_build_unary_op): Avoid re-entering reporting routines.

* g++.dg/warn/Wbool-operation-1.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/warn/Wbool-operation-1.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/typeck.c

[Bug c++/82040] [7/8 Regression] ICE with -Wbool-operation and ~

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/82040] [7/8 Regression] ICE with -Wbool-operation and ~

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Fri Sep  1 09:22:57 2017
New Revision: 251581

URL: https://gcc.gnu.org/viewcvs?rev=251581=gcc=rev
Log:
PR c++/82040
* typeck.c (cp_build_unary_op): Avoid re-entering reporting routines.

* g++.dg/warn/Wbool-operation-1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wbool-operation-1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/82070] [8 Regression] inaccessible within this context in lambda rejects valid

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
   Target Milestone|--- |8.0

[Bug c++/82070] New: [8 Regression] inaccessible within this context in lambda rejects valid

[marxin at gcc dot gnu.org]

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

Bug ID: 82070
   Summary: [8 Regression] inaccessible within this context in
lambda rejects valid
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

Starting from r251433 we reject (reduced from Firefox):

$ cat pkixcert.ii
namespace a {
template 
void
c (int, int, b d)
{
  [d] { [d] {}; };
}
}
void
e ()
{
  int f;
  a::c (f, 3, [] {});
}

$ g++ pkixcert.ii -c -std=gnu++11
pkixcert.ii: In instantiation of ‘void a::c(int, int, b) [with b =
e()::]’:
pkixcert.ii:13:20:   required from here
pkixcert.ii:6:5: error: ‘e():: a::c(int, int, b) [with b =
e()::]::__lambda0::’ is inaccessible within this context
   [d] { [d] {}; };
 ^
pkixcert.ii:6:4: note: declared here
   [d] { [d] {}; };
^
pkixcert.ii:6:5: error: invalid use of nonstatic data member ‘a::c(int, int, b)
[with b = e()::]::__lambda0::’
   [d] { [d] {}; };
 ^

[Bug c++/82067] G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
i.e. read what the crash said:

(In reply to jupitercuso4 from comment #0)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

[Bug middle-end/82062] [8 regression] simple conditional expressions no longer folded

[rguenther at suse dot de]

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

--- Comment #2 from rguenther at suse dot de  ---
On Fri, 1 Sep 2017, mpolacek at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
> 
> --- Comment #1 from Marek Polacek  ---
> So do we want to add this folding to match.pd?

Ideally we'd move fold_cond_expr_with_comparison there, combining it
with operand_equal_for_comparison_p.  Not sure how this ends up
as patterns.  At least fold_cond_expr_with_comparison in isolation
looks straight-forward to convert (minus the usual STRIP_NOPs
complication involving conditional converts and constants)

[Bug middle-end/82062] [8 regression] simple conditional expressions no longer folded

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
So do we want to add this folding to match.pd?

[Bug c++/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[marxin at gcc dot gnu.org]

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

--- Comment #36 from Martin Liška  ---
Please provide one more test-case that still fails and I will take a look. Feel
free to reopen it.

[Bug tree-optimization/82060] [7/8 Regression] ICE in refs_may_alias_p_1 with devirtualization enabled

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r246866, maybe useful info.

[Bug tree-optimization/82060] [7/8 Regression] ICE in refs_may_alias_p_1 with devirtualization enabled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-09-01
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
#1  0x01329897 in refs_may_alias_p_1 (ref1=0x7fffd4b0, 
ref2=0x7fffd2a0, tbaa_p=true) at /tmp/trunk2/gcc/tree-ssa-alias.c:1538
1538  gcc_unreachable ();
(gdb) p ref2->ref
$3 = 
(gdb) p ref2->base
$4 = 

because

(gdb) p debug_gimple_stmt (stmt)
# .MEM_10 = VDEF <.MEM_4>
MEM[(struct B *)].ma = OBJ_TYPE_REF(_2;(struct D)d_6(D)->0) (d_6(D));
$11 = void

has an unfolded LHS:

 
...
arg:0 
public unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x769e83f0>

arg:0 

arg:0 

arg:0 
arg:0 >

propagated by PRE.  So this ends up running into


  /* Visit indirect calls and turn them into direct calls if
 possible using the devirtualization machinery.  */
  if (gcall *call_stmt = dyn_cast  (stmt))
{

before we fold (and thus canonicalize) the stmt:

  if (gimple_modified_p (stmt))
{
...

[Bug middle-end/82062] [8 regression] simple conditional expressions no longer folded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-09-01
 CC||mpolacek at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

[Bug c/69389] bit field incompatible with OpenMP atomic update

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug tree-optimization/81744] [8 Regression] ICE: verify_ssa failed, at tree-ssa.c:1186

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Assuming this is fixed now.

[Bug c++/82067] G++ has an internal compiler error in possible_polymorphic_call_targets, at ipa-devirt.c:1557

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-09-01
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
First of all GCC 4.9 is no longer maintained, please update to GCC 5+.  Second,
we need a testcase (preprocessed source) to investigate any such issue.

[Bug c++/82069] New: [8 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Bug ID: 82069
   Summary: [8 Regression] ICE: Segmentation fault
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

More r251433 outfall:

trippels@gcc2-power8 llvm_build % cat MapFile.ii
template  struct A { T operator[](int); };
void toString();
namespace lld {
void toString(int);
}
using namespace lld;
template  void getSymbolStrings(A Syms) {
  [&] { toString(*Syms[0]); };
}

trippels@gcc2-power8 llvm_build % g++ -c MapFile.ii
MapFile.ii: In lambda function:
MapFile.ii:8:18: internal compiler error: Segmentation fault
   [&] { toString(*Syms[0]); };
0x10bc9783 crash_signal
../../gcc/gcc/toplev.c:341
0x1027fed4 hash_table, tree_node*>
>::hash_entry, xcallocator>::find_slot_with_hash(tree_node* const&, unsigned
int, insert_option)
../../gcc/gcc/hash-table.h:878
0x10280193 hash_map, tree_node*>
>::put(tree_node* const&, tree_node* const&)
../../gcc/gcc/hash-map.h:137
0x10429847 register_local_specialization(tree_node*, tree_node*)
../../gcc/gcc/cp/pt.c:1906
0x10429847 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:18153
0x1042890f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17911
0x1042990f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17533
0x10427aa7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17070
0x10428edf tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:17549
0x1027e32b fold_non_dependent_expr(tree_node*)
../../gcc/gcc/cp/constexpr.c:4936
0x1040cc0b build_non_dependent_expr(tree_node*)
../../gcc/gcc/cp/pt.c:24955
0x10495f1b finish_expr_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:693
0x103baa07 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11127
0x103c899f cp_parser_statement
../../gcc/gcc/cp/parser.c:10887
0x103c9d03 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11214
0x103caa67 cp_parser_lambda_body
../../gcc/gcc/cp/parser.c:10624
0x103caa67 cp_parser_lambda_expression
../../gcc/gcc/cp/parser.c:10079
0x103cba0b cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:5085
0x103ce58f cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6907
0x103eebbf cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:8248