[Bug sanitizer/88426] [8/9 Regression] Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
   Target Milestone|--- |8.3
Summary|Compiler crash if use   |[8/9 Regression] Compiler
   |special code with command   |crash if use special code
   |line switch |with command line switch
   |-fsanitize=float-cast-overf |-fsanitize=float-cast-overf
   |low |low
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r248139.

[Bug sanitizer/88404] ICE (tree check) with -fsanitize=thread on Fortran2003 code

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
Summary|[9 Regression] ICE (tree|ICE (tree check) with
   |check) with |-fsanitize=thread on
   |-fsanitize=thread on|Fortran2003 code
   |Fortran2003 code|

--- Comment #1 from janus at gcc dot gnu.org ---
Actually I think this is not a real regression. The reason why I saw it with
trunk but not with any released version is merely that it disappears when using
--enable-checking=release.

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[tanaya_patil at persistent dot com]

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

Tanaya Patil  changed:

   What|Removed |Added

 CC||tanaya_patil at persistent dot 
com

--- Comment #7 from Tanaya Patil  ---
Should we expect this fix to be in Binutil 2.32?

[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> The test compiled with r241883 + patches (2016-11-06) gives the expected
> result, compiled with r241924 + patches (2016-11-07) gives a segfault at run
> time.

Thanks for the information. Looking at this range of commits, I suspect that
r241885 is the culprit.

[Bug sanitizer/88404] ICE (tree check) with -fsanitize=thread on Fortran2003 code

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Actually I think this is not a real regression. The reason why I saw it
> with trunk but not with any released version is merely that it disappears
> when using --enable-checking=release.

Confirmed down to at least GCC6.

[Bug sanitizer/88426] [8/9 Regression] Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Created attachment 45196
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45196&action=edit
gcc9-pr88426.patch

Untested fix.  Sadly c_fully_fold doesn't handle CALL_EXPRs.

[Bug tree-optimization/88405] Missed DSE opportunity

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 CC||hubicka at gcc dot gnu.org,
   ||matz at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

But in general a prerequesite to eliminate Section A is
fusion of both loop nests and then CSEing the loads from a and b and finally
eliminate the stores as dead because a and b are only written to.

For the testcase we eliminate Section B because 'c' is discovered as writeonly.
But we do not update the writeonly flag of a or b when removing uses (and
IMHO we cannot easily).  Note we perform this "DSE" in fixup_cfg.

[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug target/88414] [9 Regression] ICE in lra_assign, at lra-assigns.c:1624

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||schwab at gcc dot gnu.org
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
Hmm, m68k asms may contain m68k specific constraints that do not make sense on
x86.

[Bug tree-optimization/88415] [7/8/9 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.5
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Another complex lowering thing.  Mine.

[Bug rtl-optimization/88416] [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Target Milestone|--- |8.3

[Bug c++/88419] [9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug rtl-optimization/88414] [9 Regression] ICE in lra_assign, at lra-assigns.c:1624

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |rtl-optimization

--- Comment #2 from Uroš Bizjak  ---
Not a target problem.

[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
The question would be what (simple-object-common.h) the following resolves to:

/* Define ulong_type as an unsigned 64-bit type if available.
   Otherwise just make it unsigned long.  */

#ifdef UNSIGNED_64BIT_TYPE
__extension__ typedef UNSIGNED_64BIT_TYPE ulong_type;
#else
typedef unsigned long ulong_type;
#endif

it is tested by configure:

# Look for a 64-bit type.
AC_MSG_CHECKING([for a 64-bit type])
AC_CACHE_VAL(liberty_cv_uint64,
[AC_TRY_COMPILE(
[#ifdef HAVE_STDINT_H
#include 
#endif],
[extern uint64_t foo;],
liberty_cv_uint64=uint64_t,
[AC_TRY_COMPILE(
[#ifdef HAVE_LIMITS_H
#include 
#endif
#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif],
[extern char foo[sizeof(long) * CHAR_BIT >= 64 ? 1 : -1];],
liberty_cv_uint64="unsigned long",
[AC_TRY_COMPILE(
[#ifdef HAVE_LIMITS_H
#include 
#endif
#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif],
[extern char foo[sizeof(long long) * CHAR_BIT >= 64 ? 1 : -1];],
liberty_cv_uint64="unsigned long long", liberty_cv_uint64=none)])])])
AC_MSG_RESULT($liberty_cv_uint64)
if test "$liberty_cv_uint64" != none; then
  AC_DEFINE_UNQUOTED(UNSIGNED_64BIT_TYPE, $liberty_cv_uint64,
 [Define to an unsigned 64-bit type available in the
compiler.])
fi


the fallback for using unsigned long should probably be #error instead.
Not sure if we actually need this given arm-eabi should be ELF32?

[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #3 from Richard Biener  ---
Mine.

[Bug target/88035] missing _mm512_reduce_round_pd() et al

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org,
   ||xguo at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/88404] ICE (tree check) with -fsanitize=thread on Fortran2003 code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2018-12-10 00:00:00 |
  Component|sanitizer   |fortran

--- Comment #3 from Richard Biener  ---
The reason is we have

 
...
arg:0 >
...
arg:1 
unsigned DI t.f90:4:0 size  unit-size

align:64 warn_if_not_align:0 offset_align 128 offset , dest=, rank=0, purpose=1, 
caf_mode=1)
at /space/rguenther/src/gcc-sccvn/gcc/fortran/trans-array.c:8578
8578  decl, cdecl, NULL_TREE);
(gdb) l
8573case DEALLOCATE_ALLOC_COMP:
8574
8575  gfc_init_block (&tmpblock);
8576
8577  comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
8578  decl, cdecl, NULL_TREE);
8579

here 'decl' is

(gdb) p debug_tree (decl)
 >

arg:0 
public unsigned DI
...

which is built by build_fold_indirect_ref_loc, dereferencing a generic
pointer:

#1  0x00a0632f in gfc_conv_procedure_call (se=0x7fffd3f0, 
sym=0x31258b0, args=0x30c50c0, expr=0x0, append_args=0x0)
at /space/rguenther/src/gcc-sccvn/gcc/fortran/trans-expr.c:5780
5780tmp = build_fold_indirect_ref_loc (input_location,
tmp);
(gdb) l
5775  /* The derived type is passed to
gfc_deallocate_alloc_comp.
5776 Therefore, class actuals can handled correctly but
derived
5777 types passed to class formals need the _data
component.  */
5778  tmp = gfc_class_data_get (tmp);
5779  if (!CLASS_DATA (fsym)->attr.dimension)
5780tmp = build_fold_indirect_ref_loc (input_location,
tmp);
5781}

[Bug target/88035] missing _mm512_reduce_round_pd() et al

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
I must say I don't understand the #c1 comment, GCC
__builtin_ia32_reducepd512_mask etc. don't take the rounding mode argument at
all.  And not only the _mm_*reduce_round* intrinsics are missing,
_mm512_*reduce_round* is missing too.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth  ---
Author: ro
Date: Mon Dec 10 09:49:02 2018
New Revision: 266946

URL: https://gcc.gnu.org/viewcvs?rev=266946&root=gcc&view=rev
Log:
Don't try to use libgcc-unwind.map with --disable-shared (PR bootstrap/65725)

2018-12-10  Fredrik Nyström  

PR bootstrap/65725
* config/sol2.h: Only use libgcc-unwind.map if
ENABLE_SHARED_LIBGCC.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sol2.h

[Bug debug/26475] tree-ssa loses line numbers for initializations (constants for PHIs)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug rtl-optimization/88425] suboptimal code for a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 CC||jakub at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
That is because the middle-end canonicalizes a < 123 comparison to a <= 122,
and for this exact optimization we need LTU rather than LEUm where the former
can be matched by the
*x86_movdicc_0_m1_neg pattern (or si if -m32).
So, in order to solve this, we'd need a define_insn_and_split (well, a set of
them) that would catch:
(parallel [
(set (reg:DI 86)
(neg:DI (leu:DI (reg:SI 89)
(const_int 122 [0x7a]
(clobber (reg:CC 17 flags))
])
in this case, with both SWI48 iterator (the mode of the result/neg/leu) and
SWI iterator (the mode of the comparison operands) and split that back into a
lt:CC comparison and the *x86_mov_0_m1_neg insn.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
(In reply to Fredrik Nyström from comment #3)
> (In reply to Daniel Richard G. from comment #0)
> > 1. Missing libgcc-unwind.map file
> 
> 1. Is caused by LINK_LIBGCC_MAPFILE_SPEC being set in gcc/config/sol2.h even
> if configured with --disable-shared. This has been around since PR
> target/59788.
> 
> I've had success on solaris 10, both sparc and x86 with following fix.
> 
> --- gcc/config/sol2.h.orig  2014-05-28 13:37:50.0 +0200
> +++ gcc/config/sol2.h   2015-09-03 14:23:19.950566000 +0200
> @@ -174,7 +174,7 @@
>  #define RDYNAMIC_SPEC "--export-dynamic"
>  #endif
>  
> -#ifndef USE_GLD
> +#if !defined(USE_GLD) && defined(ENABLE_SHARED_LIBGCC)
>  /* With Sun ld, use mapfile to enforce direct binding to libgcc_s unwinder.
> */
>  #define LINK_LIBGCC_MAPFILE_SPEC \
>"%{shared|shared-libgcc:-M %slibgcc-unwind.map}"

Thanks for the patch. It makes perfect send and I've now installed it on
mainline.

> > 2. stage2 vs. stage3 diffs
> 
> Are you sure you want /usr/ccs/bin/as on solaris x86?
> Have you tried with gnu as?
> --with-gnu-as
> --with-as=/usr/sfw/bin/gas

There's something to be said for using gas, but the Solaris 10 gas is ancient
by today' standards.  That said, I regularly bootstrap gcc on Solaris 10 with
both as and gas, and both work for me.

When trying a mainline bootstrap, I've run into quite a number of issues
(libcc1 and ada not building), but once I've worked around those, I could
bootstrap on amd64-pc-solaris2.11 (admittedly) with as/ld without comparison
failures.  This was without --with-pic, which I'll try next.

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
No.

They're not "less strict", but they have a fixed underlying type. For any
enumeration type with a fixed underlying type (whether "enum class" or just
"enum") the validvalues of the type are all the valid values of the underlying
type.

So:

enum E : unsigned char { e1, e2 };
enum class F : unsigned char { f1, f2 };

Both of these types can have any value from 0-255, so a switch statement that
only handles the e1/e2 or or f1/f2 is incorrect.

I wish people would just learn how enums work, it's not that complicated.

[Bug c++/86228] ordered comparison between pointer and zero

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to eracpp from comment #2)
> This bug was observed in the following example:
> 
> https://gcc.godbolt.org/z/p1VreP
> 
> #include 
> #include 
> 
> int main()
> {
> std::array arr;
> 
> // Mistake: meant to use std::generate.
> std::generate_n(arr.begin(), arr.end(), []{ return 0; });
> }
> 
> This code successfully compiles (unexpectedly) with GCC due to `size > 0`
> being treated as well-formed in the case where the type of second parameter
> `size` is deduced to be a pointer type such as `int*`.

That's PR 87982

[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 Ever confirmed|0   |1

--- Comment #6 from Jonathan Wakely  ---
GCC has mangled it the same way since at least 4.3 (I don't have anything odler
to test).

FWIW EDG agrees with Clang.

[Bug target/88425] suboptimal code for a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45197&action=edit
gcc9-pr88425.patch

Untested fix.

[Bug rtl-optimization/88416] [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-10
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed; mine.

[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
The only case I see with "sr" in mangle.c is:
  else
{
  write_string ("sr");
  write_type (scope);
  write_member_name (member);
}
but the grammar has:
::= sr   # T::x / decltype(p)::x
::= srN  + E

# T::N::x
/decltype(p)::N::x
::= [gs] sr + E   
# A::x, N::y, A::z; "gs"
means leading "::"

so it doesn't have E for some cases and has them for others.  I wonder about
that srN, is that really literal srN string?

[Bug c++/88419] [7/8/9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Target Milestone|9.0 |7.5
Summary|[9 Regression] [ICE] "Same  |[7/8/9 Regression] [ICE]
   |canonical type node for |"Same canonical type node
   |different types" for CTAD   |for different types" for
   |in noexcept |CTAD in noexcept

--- Comment #5 from Jakub Jelinek  ---
If we've rejected it before and then started to ICE on it, it is a regression,
we should either keep rejecting it (if invalid) or accept it without ICE.

[Bug rtl-optimization/88416] [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #2 from Segher Boessenkool  ---
We started with

(insn 11 10 29 2 (set (reg:DI 85)
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0  S8 A8]))
"/home/segher/tot/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include/ia32intrin.h":262:10
52 {*popdi1}
 (nil))
(debug_insn 29 11 12 2 (var_location:DI D#1 (reg:DI 85)) -1
 (nil))
(insn 12 29 13 2 (set (reg:DI 83 [ _4 ])
(reg:DI 85))
"/home/segher/tot/lib/gcc/x86_64-pc-linux-gnu/9.0.0/include/ia32intrin.h":262:10
66 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 85)
(nil)))

and then we combined 11 into 12:

Trying 11 -> 12:
   11: r85:DI=[sp:DI++]
   12: r83:DI=r85:DI
  REG_DEAD r85:DI
Successfully matched this instruction:
(set (reg:DI 83 [ _4 ])
(mem:DI (post_inc:DI (reg/f:DI 7 sp)) [0  S8 A8]))
allowing combination of insns 11 and 12
original costs 8 + 4 = 12
replacement cost 8
deferring rescan insn with uid = 29.
deferring deletion of insn with uid = 11.
modifying insn i312: r83:DI=[sp:DI++]
deferring rescan insn with uid = 12.

writing 29 as

(debug_insn 29 11 12 2 (var_location:DI D#1 (mem:DI (post_inc:DI (reg/f:DI 7
sp)
) [0  S8 A8])) -1
 (nil))

and df_insn_refs_verify chokes on that for some reason.  I dunno.

Unassigning.

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
What two fenv.h libstdc++ headers you mean (in what paths they are)?  While
there is
include/tr1/fenv.h
include/c_compatibility/fenv.h
the former should be included only with , not .

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[coypu at sdf dot org]

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

--- Comment #3 from coypu  ---
include/c_compatibility/fenv.h

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
That is one header, not two, so why should that fenv.h's #include_next include
that same header or some copy of that header in a different path?

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[coypu at sdf dot org]

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

--- Comment #5 from coypu  ---
(In reply to Jakub Jelinek from comment #4)
> That is one header, not two, so why should that fenv.h's #include_next
> include that same header or some copy of that header in a different path?

I am in the process of building libstdc++.

-I/tmp/build/shle--netbsdelf/libstdc++-v3/include

there's a libstdc++ fenv.h there

[Bug rtl-optimization/88414] [9 Regression] ICE in lra_assign, at lra-assigns.c:1624

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r257077.  In any case, it seems to be a LRA error-recovery bug. 
We first properly diagnose that the inline asm has constraints that are
impossible to resolve ("=d" on two different variables).  Vlad, do you think
you could have a look?

[Bug libstdc++/88421] compat C headers break building GCC with GCC

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to coypu from comment #1)
> suggested change: put #include_next outside of include guards?

We did something similar for PR 69581

[Bug rtl-optimization/88428] New: Fails to consider lea -1(%rax), %rax compared to sub 1, %rax failing to CSE test

[rguenth at gcc dot gnu.org]

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

Bug ID: 88428
   Summary: Fails to consider lea -1(%rax), %rax compared to sub
1, %rax failing to CSE test
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

The following GIMPLE test shows non-optimal assembly

long mask;
void bar ();
__GIMPLE () void foo (int a, int b)
{
  long _3;
  _3 = a_1(D) < b_2(D) ? _Literal (long) -1l : 0l;
  mask = _3;
  if (a_1(D) < b_2(D))
goto bb1;
  else
goto bb2;

bb1:
bar ();

bb2:
  return;
}

foo:
.LFB0:
.cfi_startproc
xorl%eax, %eax
cmpl%esi, %edi
setge   %al
subq$1, %rax
movq%rax, mask(%rip)
cmpl%esi, %edi
jl  .L5
...

here subq clobbers flags and thus the cmpl has to be repeated.  I believe
we could use lea which also has the same size

leaq-0x1(%rax), %rax

here instead and elide the redundant cmpl.  For my purpose the store to
mask is unnecessary, it was placed to simplify the testcase.  A GIMPLE
testcase was necessary to get the COND_EXPR and non-jumpy code through
optimization.

I'm not sure at which point during RTL we commit to using a CC clobbering
sub vs. a non-CC clobbering lea, but maybe cmpelim could replace one
with the other here?

[Bug tree-optimization/88415] [7/8/9 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 10 12:39:07 2018
New Revision: 266951

URL: https://gcc.gnu.org/viewcvs?rev=266951&root=gcc&view=rev
Log:
2018-12-10  Richard Biener  

PR middle-end/88415
* gimple.c (gimple_assign_set_rhs_with_ops): Transfer EH
info to a newly allocated stmt.

* gcc.dg/gomp/pr88415.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/gomp/pr88415.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/88415] [7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] ICE: |[7/8 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: dead STMT in EH |(error: dead STMT in EH
   |table)  |table)

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.

[Bug ada/88429] New: Ada bootstrap fails with --disable-shared

[ro at gcc dot gnu.org]

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

Bug ID: 88429
   Summary: Ada bootstrap fails with --disable-shared
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: amd64-pc-solaris2.11, x86_64-pc-linux-gnu

Prompted by PR bootstrap/65725 (a Solaris bootstrap failure with
--disable-shared),
I tried both Solaris/amd64 and Linux/x86_64 bootstraps with --disable-shared:
both fail in the same way:

cp -p /vol/gcc/src/hg/trunk/local/gcc/tsystem.h rts_32
rm -f ../stamp-gnatlib-rts_32
touch ../stamp-gnatlib1-rts_32
rm -f rts_32/s-oscons-tmplt.i rts_32/s-oscons-tmplt.s
(cd rts_32 ; \
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/xgcc
-B/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/
-B/vol/gcc/x86_64-pc-linux-gnu/bin/ -B/vol/gcc/x86_64-pc-linux-gnu/lib/
-isystem /vol/gcc/x86_64-pc-linux-gnu/include -isystem
/vol/gcc/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -m32 -E -C
-DTARGET=\"x86_64-pc-linux-gnu\" -iquote /vol/gcc/src/hg/trunk/local/gcc/ada
/vol/gcc/src/hg/trunk/local/gcc/ada/s-oscons-tmplt.c > s-oscons-tmplt.i ; \
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/xgcc
-B/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/
-B/vol/gcc/x86_64-pc-linux-gnu/bin/ -B/vol/gcc/x86_64-pc-linux-gnu/lib/
-isystem /vol/gcc/x86_64-pc-linux-gnu/include -isystem
/vol/gcc/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -m32 -S s-oscons-tmplt.i ; \
../bldtools/oscons/xoscons s-oscons)
/bin/bash: line 0: cd: rts_32: Not a directory

Unlike the default (--enable-shared) case, it seems that the rts directory for
the non-default multilib is created incorrectly: with --enable-shared, I see

make THREAD_KIND=native setup-rts
make[9]: Entering directory
'/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/gcc/ada'
rm -rf rts_32
mkdir -p rts_32
chmod u+w rts_32

while with --disable-shared, I get the creation of rts twice.

This may be related to libada/configure.ac referencing a gnatlib-plain
target for --disable-shared, which I couldn't find elsewhere.

[Bug testsuite/88369] [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 10 12:42:05 2018
New Revision: 266952

URL: https://gcc.gnu.org/viewcvs?rev=266952&root=gcc&view=rev
Log:
PR testsuite/88369
* gcc.dg/vect/vect-ivdep-1.c: Prune versioning for alignment messages.
* gcc.dg/vect/vect-ivdep-2.c: Likewise.
* gcc.dg/vect/nodump-vect-opt-info-1.c: Likewise.
* g++.dg/vect/pr33426-ivdep.cc: Likewise.
* g++.dg/vect/pr33426-ivdep-2.cc: Likewise. 
* g++.dg/vect/pr33426-ivdep-3.cc: Likewise.
* g++.dg/vect/pr33426-ivdep-4.cc: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep.cc
trunk/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-ivdep-2.c

[Bug testsuite/88369] [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Hopefully fixed.

[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Mon Dec 10 12:45:47 2018
New Revision: 266953

URL: https://gcc.gnu.org/viewcvs?rev=266953&root=gcc&view=rev
Log:
[PR 88214] Check that an argument is a pointer

2018-12-10  Martin Jambor  

PR ipa/88214
* ipa-prop.c (determine_locally_known_aggregate_parts): Make sure
we check pointers against pointers.

testsuite/
* gcc.dg/ipa/pr88214.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr88214.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug other/66955] Bootstrap error: libcc1 compiled as shared library despite --disable-shared

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||i?86-pc-solaris2.11,
   ||amd64-pc-solaris2.11
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
  Component|libgcc  |other
 CC||aoliva at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
   Host|x86_64-unknown-linux-gnu|
 Ever confirmed|0   |1
  Build|x86_64-unknown-linux-gnu|

--- Comment #4 from Rainer Orth  ---
Confirmed on all of Linux/x86_64 and Solaris/x86.  Recategorizing: libcc1 has
nothing to do with libgcc.  There's no category for it and the MAINTAINERS file
lists none.

[Bug go/56431] -lpthread should be added to -lgo

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
I'm seeing the same link error on Linux/x86_64 on mainline when configured with
--disable-shared:

/vol/gcc/bin/gld-2.31:
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/libgcc.a(generic-morestack.o):
in function `__morestack_block_signals':
/vol/gcc/src/hg/trunk/local/libgcc/generic-morestack.c:661: undefined reference
to `pthread_sigmask'

linking e.g. test2json.

[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Fixed.

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Rainer Orth  ---
[...]
>> > 2. stage2 vs. stage3 diffs
[...]
> When trying a mainline bootstrap, I've run into quite a number of issues
> (libcc1 and ada not building), but once I've worked around those, I could
> bootstrap on amd64-pc-solaris2.11 (admittedly) with as/ld without comparison
> failures.  This was without --with-pic, which I'll try next.

That bootstrap (amd64-pc-solaris2.10 with as/ld, --disable-shared
--with-pic) has now completed as well: in addition to libcc1 (PR
other/66955) and ada (cf. PR ada/88429), I also had to disable go
because it uses sendfile without explicitly linking with -lsendfile (in
the shared case, this works because libgo is linked with libsendfile).

Anyway, the bootstrap has now finished successfully and make check is
running: no comparison failures at all.  So unless there's additional
information how to reproduce this, I'll close the PR as WORKSFORME.

[Bug testsuite/88290] [9 regression] 23_containers/deque/erasure.cc fails after r266672

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Wasn't this already fixed in r266673 ?

[Bug c/88430] New: -Wmissing-attributes warnings when including libquadmath headers

[jb at gcc dot gnu.org]

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

Bug ID: 88430
   Summary: -Wmissing-attributes warnings when including
libquadmath headers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

When building libgfortran trunk one nowadays (within the past month or two,
maybe?) gets lots of warnings like below:


In file included from ../../../../trunk/libgfortran/libgfortran.h:61,
 from ../../../../trunk/libgfortran/ieee/ieee_helper.c:26:

../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:36:33: warning:
‘__qmath_crealq’ specifies less restrictive attribute than its target ‘crealq’:
‘nothrow’ [-Wmissing-attributes]

   36 | #define __qmath3(name) __qmath2(__qmath_ ## name,name,name)
  | ^~~~

../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:28:25: note: in
definition of macro ‘__qmath2’

   28 |   static __typeof(type) name __attribute__ ((__weakref__(#name2)));
  | ^~~~

../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:113:1: note: in
expansion of macro ‘__qmath3’

  113 | __qmath3 (crealq)
  | ^~~~



According to 'git blame', there has been no recent changes to the quadmath
header files recently, thus I suspect the implementation of
-Wmissing-attributes is to blame.

Though since libquadmath lives in-tree, a feasible solution would be to fix the
quadmath headers, if the missing attribute warning otherwise works as intended?
Please reassign to libquadmath if so.

See thread starting at https://gcc.gnu.org/ml/fortran/2018-12/msg00055.html

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
That would be the
 gcc_checking_assert (TREE_TYPE (name) == t);
assert then.  So, what is TREE_TYPE (name) and what is t when this happens?

[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 10 13:30:49 2018
New Revision: 266954

URL: https://gcc.gnu.org/viewcvs?rev=266954&root=gcc&view=rev
Log:
PR ipa/87955
* gcc.target/i386/pr87955.c: Add -msse2 -mfpmath=sse to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr87955.c

[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Jakub Jelinek  ---
Should be fixed now.

[Bug ipa/80726] [7/8/9 Regression] Destructor not inlined anymore (regression)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Honza, have you managed to look at this?

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The expectations that sanitization doesn't change generated warnings is a wrong
one, the runtime instrumentation affects the code generation so much that
necessarily some further warnings will be emitted and others omitted.
If you care about warnings as well as sanitization, I'd suggest separate builds
for warnings and for sanitization, the latter perhaps with -w.

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Martin, could you please have a look?

[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 10 13:56:51 2018
New Revision: 266955

URL: https://gcc.gnu.org/viewcvs?rev=266955&root=gcc&view=rev
Log:
2018-12-10  Richard Biener  

PR tree-optimization/88427
* vr-values.c (vr_values::extract_range_from_phi_node):
Handle symbolic ranges conservatively when trying to drop
to Inf +- 1.

* gcc.dg/pr88427.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr88427.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from Jakub Jelinek  ---
> That would be the
>  gcc_checking_assert (TREE_TYPE (name) == t);
> assert then.  So, what is TREE_TYPE (name) and what is t when this happens?

Here's what I find (after recompiling tree.c with -g3 -O0):

(gdb) up
#1  0x09777f85 in fld_incomplete_type_of (t=0xfa58cc60, fld=0xfeffd6a8)
at /vol/gcc/src/hg/trunk/local/gcc/tree.c:5312
5312  gcc_checking_assert (TREE_TYPE (name) == t);
(gdb) p name
$1 = (tree) 0xfa593000
(gdb) call TREE_TYPE (name)
$2 = (tree) 0xfa58ccc0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
constant 64>
unit-size 
constant 8>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type fa58ccc0
fields 
static unsigned SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
fa542900>
side-effects volatile unsigned nonaddressable SI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:193:7
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
side-effects volatile unsigned nonaddressable QI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:194:7
size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128 offset  bit-offset  context  chain
>> context 
Ada size 
constant visited 48>
pointer_to_this  reference_to_this  chain >
(gdb) p t
$3 = (tree) 0xfa58cc60
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
constant 64>
unit-size 
constant 8>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type fa58cc60
fields 
static unsigned SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
fa542900>
side-effects volatile unsigned nonaddressable SI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:193:7
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
side-effects volatile unsigned nonaddressable QI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:194:7
size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128 offset  bit-offset  context  chain
>> context 
Ada size 
constant visited 48>
chain >

[Bug d/88431] New: link errors on build

[dcb314 at hotmail dot com]

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

Bug ID: 88431
   Summary: link errors on build
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this configure line:

../trunk/configure --prefix=/home/dcb/gcc/results.266950 \
--disable-multilib \
--disable-werror \
--enable-checking=df,extra,fold,rtl,yes \
--enable-languages=c,c++,d,fortran

sed 's/-O2/-O3 -march=native -Wlogical-op/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

I got:

/home/dcb/gcc/working/./gcc/xgcc -shared-libgcc -B/home/dcb/gcc/working/./gcc
-nostdinc++ -L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/bin/
-B/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/include -isystem
/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I. -I../../../../trunk/libsanitizer/lsan -I.. -I
../../../../trunk/libsanitizer/include -I ../../../../trunk/libsanitizer -Wall
-W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-pc-linux-gnu
-I../../../../trunk/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O3
-march=native -Wlogical-op -D_GNU_SOURCE -MT lsan_allocator.lo -MD -MP -MF
.deps/lsan_allocator.Tpo -c
../../../../trunk/libsanitizer/lsan/lsan_allocator.cc  -fPIC -DPIC -o
.libs/lsan_allocator.o
/usr/bin/ld: core/.libs/atomic.o: relocation R_X86_64_32S against hidden symbol
`gdc.dso_slot' can not be used when making a shared object
/usr/bin/ld: core/.libs/attribute.o: relocation R_X86_64_32S against hidden
symbol `gdc.dso_slot' can not be used when making a shared object
/usr/bin/ld: core/.libs/bitop.o: relocation R_X86_64_32 against
`.rodata.str1.8' can not be used when making a shared object; recompile with
-fPIC

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-10
 CC||jamborm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Jambor  ---
Sure.

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug debug/88432] New: Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

Bug ID: 88432
   Summary: Dwarf line numbering inadequate when using
-fstack-protector-strong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alahay01 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45198&action=edit
Example breaking program

Using -fstack-protector-strong will cause GDB to break on the wrong line when
placing a breakpoint on a function.

[ Note that the GCC provided with Ubuntu will default to
-fstack-protector-strong, causing all function breakpoints to break on the
wrong line. This breaks roughly 50 GDB tests when run on x86 and AArch64 Ubuntu
]

The issue in GDB
=

Consider the following program:
47: int main ()
48: {
49:   char arg2 = 2;
50:   signed char arg3 = 3;

(full program attached. Ignore everything in it except for main. Testcase taken
from the GDB testsuite.)

When compiled with -fstack-protector-strong, then running it in GDB,
“breakpoint main” will stop at line 48, the "{". This is wrong, it should
instead stop on line 49 – the first line of the function body.

GDB figures this out by looking at the dwarf line numbers. It finds the entry
for the start of the function (from other dwarf entries), and assumes that it
the entry for the function prologue. It then jumps forward one entry.

With stack proctector turned off we get the following. Note that the dwarf
label for main points at index 2.

INDEXLINE ADDRESS
0  45 0x00400680
1  45 0x00400680
2  48 0x00400688 - main: prologue pt1
3  49 0x004006ac - main: first line of function
4  50 0x004006b4 - main: second line of function
...etc

With stack protector on (like Ubuntu):

INDEXLINE ADDRESS
0  45 0x00400680
1  45 0x00400680
2  48 0x00400688 - main: prologue pt1
3  48 0x00400698 - main: stack protector code
4  49 0x004006ac - main: first line of function
5  50 0x004006b4 - main: second line of function
...etc

Ok, we could jump forward two entries. But then breaks with the following (with
either stack protector on or off):
47: int main ()
48: {  char arg2 = 2;
49: signed char arg3 = 3;

It will result in the same line table, with just two entries at line 48:

INDEXLINE ADDRESS
0  45 0x00400680
1  45 0x00400680
2  48 0x00400688 - main: prologue pt1
3  48 0x00400698 - main: stack protector code
4  49 0x004006ac - main: second line of function
...etc

There is no way to tell if a repeated line is the first line of code or the
stack protector.



The underlying issue in GCC
===

See the attached rtl final dump from GCC (note: aarch64 code, but that doesn't
matter).

With the stack protector on, GCC produces RTL for the stack protector at the
beginning of the function, after the prologue.
You roughly get:
*function prologue rtl
*NOTE_INSN_PROLOGUE_END
*NOTE_INSN_FUNCTION_BEG
*stack guard code (__stack_chk_guard)
*rest of the function rtl

The stack guard rtl is given the line number of the "{" line.

When dumping line locations, notice_source_line() decides which RTL expressions
should cause a dump.  It will force a dump of the first expression following
the end of the prologue - expecting this to be the first line of the function.
This gives us:

.LFB1:
.loc 1 48 0.   – function prologue.
.cfi_startproc
sub sp, sp, #176
.cfi_def_cfa_offset 176
stp  x29, x30, [sp, 32]
.cfi_offset 29, -144
.cfi_offset 30, -136
add x29, sp, 32
.cfi_def_cfa 29, 144
str   x19, [sp, 48]
.cfi_offset 19, -128
.loc 1 48 0--   Start of  stack guard code
adrp   x0, __stack_chk_guard
add x0, x0, :lo12:__stack_chk_guard
ldr   x1, [x0]
str   x1, [x29, 136]
mov   x1,0
.loc 1 49 0.   – first line of function
mov   w0, 2
strbw0, [x29, 45]
.loc 1 50 0
mov   w0, 3
strbw0, [x29, 46]

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[nickc at gcc dot gnu.org]

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

--- Comment #8 from Nick Clifton  ---
(In reply to Tanaya Patil from comment #7)
> Should we expect this fix to be in Binutil 2.32?

Yes. :-)

[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

--- Comment #1 from alahay01 at gcc dot gnu.org ---
Created attachment 45199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45199&action=edit
rtl final dump for the .cc file

[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

--- Comment #2 from alahay01 at gcc dot gnu.org ---
Created attachment 45200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45200&action=edit
Final assembly dump for the .cc file with dwarf

[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Looking at this range of commits, I suspect that r241885 is the culprit.


Using -fdump-tree-original to compare the dumps of versions 6 and 7 shows that
the assignment subroutine itself is identical in both, but the dump from v7
contains additional code after the call to 'ass' that is not present in v6.

With v6, the call is translated as follows:

  {
struct __class_m_T_t class.7;
struct __class_m_T_t class.8;

class.7._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.7._data = &arr[1].c;
class.8._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.8._data = &arr[0].c;
ass (&class.7, &class.8);
  }


With v7, it looks much bulkier:

  {
struct __class_m_T_t class.7;
struct __class_m_T_t class.8;
struct t D.3602;
struct __class_m_T_t * D.3603;
struct __class_m_T_t D.3604;
void * restrict D.3605;

class.7._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.7._data = &arr[1].c;
class.8._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
D.3602 = arr[0].c;
class.8._data = &D.3602;
D.3603 = &class.8;
D.3604 = *D.3603;
ass (&class.7, D.3603);
D.3603->_cs_length = D.3604._cs_length;
if ((void *) D.3604.cs != 0B)
  {
D.3605 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.3603->_cs_length, 1>);
D.3603->cs = (character(kind=1)[1:0] *) D.3605;
__builtin_memcpy (D.3603->cs, D.3604.cs, (unsigned long)
D.3603->_cs_length);
  }
else
  {
D.3603->cs = 0B;
  }
if (D.3603->_data->cs != 0B)
  {
__builtin_free ((void *) D.3603->_data->cs);
D.3603->_data->cs = 0B;
  }
  }

Looks like there is some copying and deallocation of the allocatable components
here. Not sure why that would be necessary ...?!?

[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
I considered a number of solutions, but they all had issues:


1) Place the RTL for the stack guard inside the prologue, giving:

*function prologue rtl
*stack guard code (__stack_chk_guard)
*NOTE_INSN_PROLOGUE_END
*NOTE_INSN_FUNCTION_BEG
*rest of the function rtl

Then this would then automatically stop the line number being dumped for the
stack guard. The rest of the assembly would be the same.

Downside here is that in the future new optimisations could be added that have
exactly the same issue.


2) Add line numbers to NOTE_INSN_FUNCTION_BEG and remove line numbers from
stack guard code (which currently has the line number for the { line)


3) Ensure the stack guard code has the line number of the first line of the
function main body.


I'm not sure if 2 and 3 will break instruction reordering.

[Bug testsuite/88290] [9 regression] 23_containers/deque/erasure.cc fails after r266672

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Not sure when it was fixed but it is not failing any longer.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
Created attachment 45201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45201&action=edit
gcc9-pr86004.patch

Untested testsuite fix, tested both on a system with binutils 2.25 (where those
tests previously failed, now UNSUPPORTED) and recent ones (where it still
PASSes).

[Bug libstdc++/88290] [9 regression] 23_containers/deque/erasure.cc fails after r266672

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|testsuite   |libstdc++

--- Comment #3 from Jonathan Wakely  ---
Yes, it would have been r266673.

The component should have been "libstdc++" (I won't see it otherwise). It was a
problem in the library headers (revealed by the tests), not a problem in the
testsuite itself.

[Bug target/88418] [7/8/9 Regression] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Dec 10 15:47:16 2018
New Revision: 266958

URL: https://gcc.gnu.org/viewcvs?rev=266958&root=gcc&view=rev
Log:
PR target/88418
* config/i386/i386.c (ix86_expand_sse_cmp): For vector modes,
check operand 1 with vector_operand predicate.
(ix86_expand_sse_movcc): For vector modes, check op_true with
vector_operand, not nonimmediate_operand.

testsuite/ChangeLog:

PR target/88418
* gcc.target/i386/pr88418.c: New test.


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

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #3)
> If you care about warnings as well as sanitization, I'd suggest separate
> builds for warnings and for sanitization, the latter perhaps with -w.

This is fine for code that is fixed, but this makes developing and debugging
harder, when testing code just after making changes.

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
That can be dealt in the Makefile rules, for sanitization use something like
$(CC) $(CFLAGS) $(WARNOPTS) -S -o /dev/null $<
$(CC) $(CFLAGS) $(SANITIZEOPTS) -c -o $@ $< 2>/dev/null
or similar.

[Bug tree-optimization/85459] [8/9 Regression] Larger code generated from GMP template meta-programming

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
On the #c4 testcase it is:
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.24 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
438   0   0 438 1b6 pr85459.o
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.255509 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
334 152   0 486 1e6 pr85459.o
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.255510 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
833 160   0 993 3e1 pr85459.o
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.266943 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
813 160   0 973 3cd pr85459.o
So the only significant growth there is due to the SRA change.
For -Os the sizes are much larger, 1075 at r24, 789 at r255509, 919 at
r255510 and 939 at r266943.

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #6 from Vincent Lefèvre  ---
But this cannot apply to projects that use GNU Automake, which does not
generate such rules. And with Automake, things are more complex in practice,
because in the rules, there are additional options for dependency tracking.

[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.

[brennan at umanwizard dot com]

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

--- Comment #8 from brennan at umanwizard dot com ---
Yes that is the literal srN string and in fact GCC does output that sometimes,
for example on the following program which made it a lot clearer to me what is
going on.

template 
struct S1 {
};

struct S2
{
  template 
  struct S3 {
static constexpr int val = sizeof(T);
  };
};

template 
void g(S1::val> * = nullptr) {
}

void h() {
  g();
}

in which g is mangled as __Z1gIiEvP2S1IXsrN2S22S3IT_EE3valEE . Clang
mangles it as __Z1gIiEvP2S1IXsr2S22S3IT_EE3valEE -- notice there is no "N" in
Clang's version. Again I feel Clang is correct, based on my understanding of
the standard.

GCC apparently uses only the two productions
 ::= sr   # T::x /
decltype(p)::x
 ::= srN  + E

# T::N::x
/decltype(p)::N::x

But if you look up "unresolved-type" in the standard, it is clear that those
two productions should only be used when the first element in the chain is a
template parameter, not some random class or namespace. So it is wrong to
encode "S2::S3::val" with either of those, because "S2" is not an
"". Presumably this is what the standard authors were getting
at by using the letter "T" in the comment.

The production GCC should be using in that program, and the one Clang actually
does use, is:

 ::= [gs] sr + E
  
# A::x,
N::y, A::z; "gs" means leading "::"

In S2::S3::val, each of S2 and S3 is an ""
and val is a "".

[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.

[brennan at umanwizard dot com]

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

--- Comment #9 from brennan at umanwizard dot com ---
There is an open issue from Oct. 2017 on the ABI standard's official website
(which is a Github repo):

https://github.com/itanium-cxx-abi/cxx-abi/issues/38

It appears to be the exact thing we are seeing here.

The person who opened that issue does think GCC's behavior, although wrong
according to the standard, is better. However it doesn't seem to have gone
anywhere since 10/2017 so I'm not sure whether they will in fact change the
standard.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[hubicka at ucw dot cz]

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

--- Comment #12 from Jan Hubicka  ---
Thanks a lot for looking into this.  Indeed disabling the tests is
probably good idea, so the patch looks good to me. Somewhere we should
document minimal binutils release supporting incremental link...

Honza

[Bug rtl-optimization/84345] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
I think gcc_qsort doesn't really change things here, validation failure implies
a logic issue in the comparator, so some step is not always working as the
author intended.

And even with gcc_qsort it's still an ice-checking (possibly on valid code).

I guess evidently people don't worry too much about currently open qsort_chk
bugs, but it doesn't make sense that with gcc_qsort we should care even less.

[Bug rtl-optimization/84345] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I thought the main argument for the qsort checking was to avoid different code
generation between different hosts (e.g. with cross-compilers etc.).
Some of the comparator issues were just easy bugs in the logic, but others are
not really easily convertible to what the checking requires, it is just a
heuristic to get reasonable code generation (especially some of the RTL ones).
The argument about different code generation is gone with gcc_qsort.

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 45202
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45202&action=edit
gcc9-pr88430.patch

For quadmath_weak.h it can be easily handled with the attached patch.
There are additional 166 occurrences of warnings in gthr*.h, and some further
ones in libgfortran.
I'm worried about this warning though, because while in the libquadmath case
the alias targets are declared next to it in adjacent header provided by the
same library, in gthr*.h case it is a common example how a weakref is created
for a system header provided function.  For those one often doesn't know what
exact attributes are used and it is quite hard to query that (configure
grepping preprocessed source, what else?).

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The change occurred between r265975 (no warning) and r266035 (warnings).

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The expected mechanism to apply the attributes is by using the new copy
attribute.  (It's been on my to-do list to look into these.)

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|samtebbs at gcc dot gnu.org|rearnsha at gcc dot 
gnu.org

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Dec 10 18:05:37 2018
New Revision: 266959

URL: https://gcc.gnu.org/viewcvs?rev=266959&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/88269
* io.c (io_constraint): Update macro. If locus line buffer is NULL,
use gfc_current_locus in error messages.
(check_io_constraints): Catch missing IO UNIT in write and read
statements.  io_constraint macro is incompatible here.

2018-12-10  Steven G. Kargl  

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr88269.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88433] New: wrong code for printf after a pointer cast from a pointer to an adjacent object

[msebor at gcc dot gnu.org]

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

Bug ID: 88433
   Summary: wrong code for printf after a pointer cast from a
pointer to an adjacent object
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is from Exploring C Semantics and Pointer Provenance:
  https://www.cl.cam.ac.uk/~pes20/cerberus/cerberus-popl2019.pdf

the following test case:
 
https://cerberus.cl.cam.ac.uk/cerberus?defacto/provenance_basic_using_uintptr_t_global_yx.c

GCC emits code with different effects for each of the two functions below even
when the objects x and y are adjacent to each other: in f(), the call to printf
outputs the modified value of y.  In g(), however, it outputs the value of y
before modification.

I consider the code in the test case undefined, but a) my understanding from
Richard is that the middle-end intentionally doesn't track pointer provenance
through integer conversions (and so doesn't necessarily treat this sort of
"object hopping" as undefined), and b) the PNVI model outlined in the paper
above and expected to be proposed for C2X makes this code valid (the model
allows p to take on the provenance of y as a result of the integer <-> pointer
casts).

Looking at the dumps, I think (a) is true for this test case in both f() and
g().  The different output from g() appears to be due to the x86_64 back
performing the assignment *p = 11 only after it has stored the value of y in
the register passed to printf.  Other back-ends I've looked at produce the same
output from g() as from f().

int y = 2, x = 1;

void f (void)
{
  long ix = (long)&x;
  long iy = (long)&y;

  ix += 4;

  int *p = (int*)ix;
  int *q = (int*)iy;

  if (p == q) {
*p = 11;
__builtin_printf ("%i", y);   // prints 11
  }
}

void g (void)
{
  long ix = (long)&x;
  long iy = (long)&y;

  ix += 4;

  int *p = (int*)ix;
  int *q = (int*)iy;

  if (!__builtin_memcmp (&p, &q, sizeof p)) {
*p = 11;
__builtin_printf ("%i", y);   // prints 2
  }
}

[Bug tree-optimization/86196] [9 Regression] Bogus -Wrestrict on memcpy between array elements at unequal indices

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Any progress on this?

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce in current trunk's cross to darwin, can you still reproduce?

[Bug middle-end/88397] attribute malloc ignored on function pointers when alloc_size is accepted

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The problem with attribute noreturn is tracked separately in bug 79604 (the C
front end seems to do the right thing there, as do Clang and ICC in both C and
C++ modes).

For attributes alloc_align and malloc, what concern do you have with accepting
them on function pointers and function types?  (So they work the same way as
alloc_size.)

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Can't reproduce in current trunk's cross to darwin, can you still reproduce?

Yes with compilers configured with --enable-checking=yes. I don't see any ICE
for those configured with --enable-checking=release.

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Any particular tuning option (what -march/-mtune is the default)?
Can you attach your auto-host.h?
Perhaps could you attach a tarball with -da dumps with the above options, so I
can try to figure out why I can't reproduce this?

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Dec 10 19:26:43 2018
New Revision: 266960

URL: https://gcc.gnu.org/viewcvs?rev=266960&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/88269
* io.c (io_constraint): Update macro. If locus line buffer is NULL,
use gfc_current_locus in error messages.
(check_io_constraints): Catch missing IO UNIT in write and read
statements.  io_constraint macro is incompatible here.

2018-12-10  Steven G. Kargl  

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88269.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/io.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug c++/88216] [9 Regression] ICE (-std=c++2a) in cxx_eval_constant_expression, at cp/constexpr.c:4602

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Patch posted: 
We'll see how that goes.

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[safinaskar at mail dot ru]

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

--- Comment #11 from Askar Safin  ---
(In reply to Jonathan Wakely from comment #10)
> I wish people would just learn how enums work, it's not that complicated.

Okey, now I understand everything. Now I see that, well, -fstrict-enums
silences warning for code from comment #1 only because number of enum
alternatives happen to be power of 2. If it would be, say, 3, then code from
comment #1 will always produce a warning even with -fstrict-enums. And also I
understand that code with "enum class" will always produce a warning.

So, gcc doesn't have way to enable clang-style warning behavior for enums. And
gcc doesn't have such way for "enum class", too. And -fstrict-enums enables
clang-style warning behavior for code from comment #1 only because this code
has power of 2 number of alternatives.

And also I understand that current gcc behavior is not bug and is absolutely
standard-compliant.

But, well, I still don't like current g++ behavior. I want g++ to not report
"reaching end of non-void..." if all switch alternatives are handled, at least
if some optional option is passed to gcc. I want clang behavior. Okey, you may
mark this bug as "wishlist", but I still think that clang-style behavior here
is very useful feature.

Look here, LLVM project was forced to introduce special kludge to make sure g++
will not give useless warnings:
http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Dec 10 20:03:32 2018
New Revision: 266962

URL: https://gcc.gnu.org/viewcvs?rev=266962&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/88269
* io.c (io_constraint): Update macro. If locus line buffer is NULL,
use gfc_current_locus in error messages.
(check_io_constraints): Catch missing IO UNIT in write and read
statements.  io_constraint macro is incompatible here.

2018-12-10  Steven G. Kargl  

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88269.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/io.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.5

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk, branch-8, and branch-7. Closing

[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #13 from Marek Polacek  ---
Thanks Jon, I'll poke at it some more.

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
It's not a useless warning. If I call your function from comment 7 like this, I
get undefined behaviour:

  CoverMyBases( Enum{2} );

Your switch is undefined for this code. That's what GCC is warning you about.
To tell GCC you will never call the function with any value except Enum::A or
Enum::B, add

  default: __builtin_unreachable();

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #12)
> It's not a useless warning. If I call your function from comment 7 like
> this, I get undefined behaviour:
> 
>   CoverMyBases( Enum{2} );
> 
> Your switch is undefined for this code. That's what GCC is warning you
> about. To tell GCC you will never call the function with any value except
> Enum::A or Enum::B, add
> 
>   default: __builtin_unreachable();

Maybe better to add it after the switch if you want to make sure that you get a
warning with -Wswitch if a new enumerator is added.

[Bug c++/88434] New: operator< should take precedence over template argument in basic.lookup.classref

[gieseanw+gcc at gmail dot com]

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

Bug ID: 88434
   Summary: operator< should take precedence over template
argument in basic.lookup.classref
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gieseanw+gcc at gmail dot com
  Target Milestone: ---

Semi-related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85570
Bug discovered here: https://stackoverflow.com/q/53712642/27678


The following code does not compile in gcc 9 (or earlier) or clang 8 (or
earlier), but does in MSVC 19.00.23506.

compile with -std=c++11 Code follows:

#include 

using namespace std;

struct A{ int rank; };

template
bool comp_rank(const T &a, const T &b){
return a.rank < b.rank;
}

int main()
{
A a{42}, b{0};
comp_rank(a, b);
}

gcc fails with 

prog.cc: In function 'bool comp_rank(const T&, const T&)':
prog.cc:9:23: error: type/value mismatch at argument 1 in template parameter
list for 'template struct std::rank'
9 | return a.rank < b.rank;
  |   ^~~~
prog.cc:9:23: note:   expected a type, got 'b.rank'


This appears to violate [basic.lookup.classref] which states

In a class member access expression, if the . or -> token is immediately
followed by an identifier followed by a <, the identifier must be looked up to
determine whether the < is the beginning of a template argument list or a
less-than operator. The identifier is first looked up in the class of the
object expression. If the identifier is not found, it is then looked up in the
context of the entire postfix-expression and shall name a class template.