[Bug c++/85052] Implement support for clang's __builtin_convertvector

[kretz at kde dot org]

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

--- Comment #5 from Matthias Kretz  ---
Thank you Jakub! Here's a tested x86 library implementation for all conversions
and different ISA extension support for reference:

https://github.com/mattkretz/gcc/blob/mkretz/simd/libstdc%2B%2B-v3/include/experimental/bits/simd_x86_conversions.h

(I have not looked at the patch yet to see whether I understand enough of the
implementation to optimize conversions myself.)

[Bug testsuite/88436] [9 regression] r265421 causes gcc.target/powerpc/pr54240.c to fail

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug testsuite/88436] [9 regression] r265421 causes gcc.target/powerpc/pr54240.c to fail

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Author: marxin
Date: Thu Jan  3 07:53:37 2019
New Revision: 267541

URL: https://gcc.gnu.org/viewcvs?rev=267541=gcc=rev
Log:
Adjust a dump file in a test-case (PR testsuite/88436).

2019-01-03  Martin Liska  

PR testsuite/88436
* gcc.target/powerpc/pr54240.c: Scan phiopt2.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr54240.c

[Bug bootstrap/88668] Code generated was different for PowerPC when build!=host compared to build=host

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> > On windows with configure like
> > --host i686-w64-mingw32
> 
> But build is then guessed using config.guess.
> Then you have a build!=host case.

I should say you have the build!=host case on accident.  Really this one case
you should have them being the same.

[Bug bootstrap/88668] Code generated was different for PowerPC when build!=host compared to build=host

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-03
  Component|c   |bootstrap
   Host|windows |!=build
Summary|Code generated was  |Code generated was
   |different for PowerPC on|different for PowerPC when
   |Windows W.R.T Linux.|build!=host compared to
   ||build=host
 Ever confirmed|0   |1
  Build||!=target

--- Comment #2 from Andrew Pinski  ---
> On windows with configure like
> --host i686-w64-mingw32

But build is then guessed using config.guess.
Then you have a build!=host case.
Now AS="${AS_FOR_BUILD}" should be passed too and that is missing there.

This is the patch which should fix that (NOTE you will need to regenerate
configure):
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 974a1723843..ac7fe138548 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1708,6 +1708,7 @@ else
CC="${CC_FOR_BUILD}" CFLAGS="${CFLAGS_FOR_BUILD}" \
CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
+   AS=${AS_FOR_BUILD}" \
GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
${realsrcdir}/configure \
--enable-languages=${enable_languages-all} \

[Bug c/88668] Code generated was different for PowerPC on Windows W.R.T Linux.

[umesh.kalappa0 at gmail dot com]

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

--- Comment #1 from Umesh Kalappa  ---
after our investigation we found that the  below change ,makes code to be 
generated  like identical to linux host .

--- a/gcc/configure
+++ b/gcc/configure
@@ -11795,15 +11795,16 @@ else
CXX="${CXX_FOR_BUILD}" CXXFLAGS="${CXXFLAGS_FOR_BUILD}" \
LD="${LD_FOR_BUILD}" LDFLAGS="${LDFLAGS_FOR_BUILD}" \
GMPINC="" CPPFLAGS="${CPPFLAGS} -DGENERATOR_FILE" \
+   gcc_cv_as=../as gcc_cv_ld=../collect-ld enable_targets=$enable_targets\
${realsrcdir}/configure \
--enable-languages=${enable_languages-all} \
--target=$target_alias --host=$build_alias --build=$build_alias

This change would affect the value of macros defined in auto-build.h which is
used when building the toolchain for Windows, the different value of macros
result the different code in generated file insn-conditions.md, insn-recog.c
etc which eventually makes a different compiler is built for Windows.

Before we conclude with our changes ,we would like to hear from the experts
here on the difference behaviour(b/w hosts)  and the fix .

[Bug c/88668] New: Code generated was different for PowerPC on Windows W.R.T Linux.

[umesh.kalappa0 at gmail dot com]

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

Bug ID: 88668
   Summary: Code generated was different for PowerPC on Windows
W.R.T Linux.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: umesh.kalappa0 at gmail dot com
  Target Milestone: ---

Hi All ,

Lets consider the below code

int foo()
{
  printf("Hello World");
}

On linux with configure like :
  --target=powerpc-linux-gnu --prefix=/usr/local/wind/tmp/compilers
--with-pkgversion=' GCC 8.1.0.0 - 2018.10.29' --disable-nls
--enable-languages=c,c++ --enable-targets=all --disable-multilib
--enable-threads --enable-tls --enable-__cxa_atexit --enable-secureplt

code generated like
addis 3,2,.LC0@toc@ha
addi 3,3,.LC0@toc@l

where offset  signed 32 bit used  relatively to  toc base  on linux as expected
 for the  medium code model . and the relocation entry will be generated by gas
 :
R_PPC64_TOC16_HA   and  R_PPC64_TOC16_LO

On windows with configure like :
--host i686-w64-mingw32 --target=powerpc-linux-gnu
--prefix=/usr/local/wind/tmp/compilers --with-pkgversion='GCC 8.1.0.0 -
2018.10.25' --disable-nls --enable-languages=c,c++ --enable-targets=all
--disable-multilib --enable-threads --enable-tls --enable-__cxa_atexit
--enable-secureplt

code generated like :
la 3,.LC0@toc(2)

where offset used  is signed 16  bit used  relatively to  toc base and the
relocation entry will be :
R_PPC64_TOC16  (signed 16 bit offset ).

[Bug target/84748] wrong code with u128 at aarch64 at -O and and above

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
Shouldn't the *compare_condjump insn_and_split be similarly marked with a
CC clobber?  (and perhaps an additional clobber for the scratch register while
at that?)

[Bug middle-end/80362] [5 Regression] gcc miscompiles arithmetic with signed char

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #9 from Alexandre Oliva  ---
I see the same issue of using arg vs op is present in the reciprocal tests
right below the patched ones.  AFAICT it is not possible to trigger the problem
in a way that affects the outcome, but...  is there any good reason to keep
them different and have people puzzle over the difference?  I think it was not
the first time that difference caught my attention and got me distracted trying
to reason it out.

[Bug lto/88665] Arduino: 1.8.8 (Windows Store 1.8.19.0) (Windows 10), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

[WOLFCREEK1 at COX dot NET]

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

--- Comment #2 from ALLEN WYMER  ---
I HAD NO IDEA WHAT I WAS DOING IY JUST SAID REPORT BUG SO I TRIED

Sent from Mail for Windows 10

From: pinskia at gcc dot gnu.org
Sent: Wednesday, January 2, 2019 3:36 PM
To: wolfcre...@cox.net
Subject: [Bug lto/88665] Arduino: 1.8.8 (Windows Store 1.8.19.0) (Windows10),
Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unspecified |5.1.0
  Component|classpath   |lto
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE
Product|classpath   |gcc

--- Comment #1 from Andrew Pinski  ---
Dup of bug 87695.  NOTE you filed this bug under classpath which is wrong.

*** This bug has been marked as a duplicate of bug 87695 ***

[Bug tree-optimization/88666] GCC 8.2.- gets Internal Compiler Error: seg fault; GCC 8.1.0 works fine

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-01-03
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
This looks similar to bug 88659 but I'm not able to reproduce it on x86_64 with
either the top of the gcc-8-branch or trunk (GCC 9).  Either it's been fixed or
it's target-specific.  Please mention your Host and Target triplets and either
provide a preprocessing translation unit for the test case or reduce it to one
that doesn't include any headers.

[Bug d/88654] Hangs in libphobos testsuite

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Richard Biener from comment #1)
> I think I saw a duplicate somewhere - this is using real-time threads pinned
> to a single CPU but yield()ing in a spinning loop expecting to make progress.

I checked the multilib issue, and couldn't see it.

Had a look on D's bugtracker, and found this related issue:
https://issues.dlang.org/show_bug.cgi?id=18519

Raised a pull request against upstream phobos that fixes the test itself:
https://github.com/dlang/phobos/pull/6824

Though I haven't yet checked running in dejagnu that the desirable behaviour
transfers over well.

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||i386-*-linux
   Host||x86_64-*-linux

--- Comment #9 from Martin Sebor  ---
With the patch in comment #3 reverted the test case in comment #0 fails with a
64-bit host GCC 8 compiling for an i386 target (i.e., with -m32).  The new
failures reported for GCC 9 appear to be specific to ILP32 host compilers.

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
The test started failing only today:

  https://gcc.gnu.org/ml/gcc-regression/2019-01/msg00039.html

so the failures are a regression in GCC 9 but not in GCC 8 as the bug summary
indicates.  Since GCC 8 is not affected, neither is the patch referenced in
comment #3, and so tracking any new failures in this area under a separate bug
would be appropriate.

r267503 is also part of a bigger patch kit with at least one change after it
(r267531) so it's possible that the regression was only transient.  As Jeff
mentions in his post to gcc-patches below, he is aware of a few outstanding
issues on a few 32-bit targets as a result of some of the patches in this
series and is in the process of validating the full kit:

  https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00064.html

I have just built the top of trunk and verified the test passes in both 32-bit
and 64-bit modes (with a 64-bit host GCC) so unless the original bug was also
specific to an ILP32 host compiler the new failures are, making the root cause
also likely different.  In any case, if the failures do persist on any targets
let's open a new bug and make both the host and target clear.  As the author of
the changes behind both regressions I prefer it that way.

[Bug fortran/45424] [F08] Add IS_CONTIGUOUS intrinsic

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

  Attachment #45292|0   |1
is obsolete||

--- Comment #7 from Harald Anlauf  ---
Created attachment 45322
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45322=edit
Extended Update of Tobias' patch to 9-trunk (except for ChangeLog)

I've updated Tobias' patch, adding a runtime library function to handle
assumed rank arrays (not sure if this is the right way).  This now works
for the following testcase:

program is_contiguous_2
  implicit none
  real, allocatable :: b(:,:)
  allocate(b(10,10))
  if (fail (b,  .true.) ) stop 1
  if (fail (b(::1,::1), .true.) ) stop 2
  if (fail (b(::2,::1), .false.)) stop 3
  if (fail (b(::1,::2), .false.)) stop 4
  if (fail (b(:10,:10), .true. )) stop 5
  if (fail (b(: 9,:10), .false.)) stop 6
contains
  pure logical function fail (x, expect)
!   type(*), dimension(..), intent(in) :: x  ! This should work, too
real,dimension(..), intent(in) :: x
logical,intent(in) :: expect
fail = is_contiguous (x) .neqv. expect
  end function fail
end program

I don't know how to handle assumed type; I need help by somebody else
who is interested in pursuing this.

Thanks to whoever will pick this up.

[Bug c/88667] Accepts program with invalid abstract-declarator grammar.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Anders Granlund  ---
Thanks for the explanation.

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

--- Comment #25 from Jan Hubicka  ---
I have tracked down the firefox issue to be -fno-lifetime-dse=1 being used in
with -fprofile-use but not with -fprofile-generate. I am down to 36 mismatches
now and those seems real sourcecode changes (will analyze them after another
rebuild)

[Bug c++/81486] Class template argument deduction fails with (), succeeds with {}

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Done.

[Bug c++/81486] Class template argument deduction fails with (), succeeds with {}

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  2 22:39:16 2019
New Revision: 267535

URL: https://gcc.gnu.org/viewcvs?rev=267535=gcc=rev
Log:
PR c++/81486 - CTAD failing with ().
* g++.dg/cpp1z/class-deduction60.C: New test.
* g++.dg/cpp1z/class-deduction61.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction60.C
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction61.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c/88667] Accepts program with invalid abstract-declarator grammar.

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
This is a known defect in the syntax in the standard, as discussed on the 
WG14 reflector on 22 Sep 2017 (see reflector message 14798).

[Bug c/448] -related issues (C99 issues)

[joseph at codesourcery dot com]

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

--- Comment #40 from joseph at codesourcery dot com  ---
The definitions have been added for VxWorks at some point.

[Bug c++/88631] CTAD cannot deduce from () value initialization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/88631] CTAD cannot deduce from () value initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  2 22:20:45 2019
New Revision: 267533

URL: https://gcc.gnu.org/viewcvs?rev=267533=gcc=rev
Log:
PR c++/88631 - CTAD failing for value-initialization.
* typeck2.c (build_functional_cast): Try deducing the template
arguments even if there are no arguments to deduce from.

* g++.dg/cpp1z/class-deduction59.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1z/class-deduction59.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88343] [7/8 Regression] R31 is unconditionally saved/restored on powerpc-darwin even when it's not necessary.

[jsm28 at gcc dot gnu.org]

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

--- Comment #11 from Joseph S. Myers  ---
This change results in miscompilation of glibc for 32-bit soft-float powerpc
(symptoms: many libm tests as run by "make regen-ulps" either segfault, or
produce spurious errors that don't occur with compilers without this change, or
in the case of tests for float fail the "Value outside of 100 +/- 1ulp."
internal sanity check).

Specifically, on GCC 7 branch r267476 works OK but the tip of the branch, which
has no subsequent changes other than this patch and changes to DATESTAMP,
miscompiles glibc.  On GCC 8 branch r267386 (the revision before this change)
works and tip of the branch miscompiles glibc (but I haven't bisected there to
confirm it is indeed this change that's responsible).  Trunk also miscompiles
glibc (I haven't tried previous revisions there).

[Bug c++/88612] [9 Regression] Internal compiler error: Error reporting routines re-entered.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/88612] [9 Regression] Internal compiler error: Error reporting routines re-entered.

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  2 22:15:46 2019
New Revision: 267532

URL: https://gcc.gnu.org/viewcvs?rev=267532=gcc=rev
Log:
PR c++/88612 - ICE with -Waddress-of-packed-member.
* call.c (convert_for_arg_passing): Only give warnings with tf_warning.
* typeck.c (convert_for_assignment): Likewise.

* g++.dg/warn/Waddress-of-packed-member1.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Waddress-of-packed-member1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Martin Sebor  ---
> If this is a new regression please open a new bug for it.  It's probably a

How would I determine that?  The testcase fails on a considerable number
of targets the moment it is introduced.

> fallout from r267503 or one of the other related changes.

And what would be the point anyway: either the testcase doesn't always
test what it claims to or the patch doesn't always fix what it should.
In either case, the author is on the hook to investigate and fix the
issue, both well within the scope of this PR.

Only if it turns out that this is a completely different issue that
needs to be fixed without modifying either the new testcase or the rest
of the patch can a new PR be opened.  Everything else only leads to a
needless explosion of PRs.

[Bug c++/44263] missing diagnostic on questionable array sizes with -pedantic

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing c++ FE maintainers

[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]

[mathieu.malaterre at gmail dot com]

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

--- Comment #8 from Mathieu Malaterre  ---
For reference:

$ cat ptrace2.c
#include 
#define CREATE_TRACE_POINTS
#include 
void a(int b, int c, void *d) {
  void *e = 0;
  int g = user_regset_copyout(, , d, e, g, 0, sizeof(vector128));
  union {
elf_vrreg_t f
  } vrsave;
  user_regset_copyout(, , d, e, , 33 * sizeof(vector128), -1);
}

[Bug c++/87729] Please include -Woverloaded-virtual in -Wall

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-02
 Ever confirmed|0   |1

--- Comment #3 from Eric Gallager  ---
(In reply to Daniel Fruzynski from comment #2)
> Here you are:
> 
> [code]
> class Foo
> {
> public:
> virtual void f(int);
> };
> 
> class Bar : public Foo
> {
> public:
> virtual void f(short);
> };
> [/code]

Thanks, confirmed.

$ /usr/local/bin/g++ -c -Wall 87729.cc
$ clang++ -c -Wall 87729.cc
87729.cc:10:16: warning: 'Bar::f' hides overloaded virtual function
[-Woverloaded-virtual]
  virtual void f(short);
   ^
87729.cc:4:16: note: hidden overloaded virtual function 'Foo::f' declared here:
type mismatch at 1st parameter ('int' vs 'short')
  virtual void f(int);
   ^
1 warning generated.
$

[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations

[gary at intrepid dot com]

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

--- Comment #5 from Gary Funck  ---
(In reply to Eric Gallager from comment #4)
> Any plans to resubmit the GUPC branch again?

Eric, no not at this time.  Thanks.

[Bug c/88667] New: Accepts program with invalid abstract-declarator grammar.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88667
   Summary: Accepts program with invalid abstract-declarator
grammar.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  void f(int [const *]);

  int main() {}

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  No error messages outputed.

Expected behaviour:

  An error message outputed.

  [const *]  is an invalid abstract-declarator according to the grammar in
6.7.7/1
  (no type qualifiers allowed in [*]).

[Bug middle-end/88273] [8/9 Regression] warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of object 'vrsave' with type 'union ' [-Warray-bounds]

[mathieu.malaterre at gmail dot com]

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

--- Comment #7 from Mathieu Malaterre  ---
Here is the new creduced test case:

$ cat bug.c
#include 

typedef struct {
  int b[4]
} c;
void* d;
unsigned e;
inline int h(void *i, int p2, int j) {
  if (j < 0 || e < j) {
int copy = ({
  typeof(e) k = j - e;
  k;
});
i += e - p2;
memcpy(d, i, copy);
e = copy;
  }
}
void a() {
  int g = h(, 0, sizeof(c));
  union {
c f;
  } vrsave;
  h(, 33 * sizeof(c), -1);
}


Compilation:

$ powerpc-linux-gnu-gcc -Warray-bounds -mcpu=powerpc -O2 -c bug.c

Using creduce with:

#!/bin/bash
powerpc-linux-gnu-gcc -Warray-bounds -mcpu=powerpc -O2 -c ptrace2.i >&
output.txt
grep error output.txt && exit 1
grep -F "warning: 'memcpy' offset [-527, -529] is out of the bounds [0, 16] of
object 'vrsave' with type 'union '" output.txt >/dev/null 2>&1

[Bug classpath/29304] autoconf should be used in libjava to check for fabs, fabsf and scalbn

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #4)
> (In reply to Andrew John Hughes from comment #3)
> > No, this is a Classpath bug. Nothing to do with GCJ.
> 
> Does it make sense for Classpath and GCC to continue to share a bugzilla
> these days? This is far from the only time I've been confused by it... would
> it be possible to split them into 2 separate bug databases?

I am less confused by the sharing because I know the history (I was one of the
folks who prompted the sharing).  I don't think it hurts having the classpath
in GCC's bugzilla and I normally monitor classpath's bug list for accidental
usage there (there was one today but it only happens once every two months so
it is low traffic).

[Bug middle-end/80023] missing diagnostic on aligned_alloc with invalid alignment

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Martin Sebor from comment #2)
> Confirmed per comment #1.

Thanks.

[Bug middle-end/80042] gcc thinks sin/cos don't set errno

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||easyhack

--- Comment #5 from Eric Gallager  ---
(In reply to Richard Biener from comment #4)
> DEF_LIB_BUILTIN(BUILT_IN_SIN, "sin", BT_FN_DOUBLE_DOUBLE,
> ATTR_MATHFN_FPROUNDING)
> 
> so it doesn't set errno according to GCC.

So all that needs to be done is to change ATTR_MATHFN_FPROUNDING to
ATTR_MATHFN_FPROUNDING_ERRNO on the relevant lines in builtins.def, right?

[Bug target/29838] -fstack-protector shouldn't use TLS in freestanding mode

[egallager at gcc dot gnu.org]

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

--- Comment #13 from Eric Gallager  ---
(In reply to Thomas Schwinge from comment #12)
> See also PR78875.

That's been closed since you commented.

[Bug classpath/29304] autoconf should be used in libjava to check for fabs, fabsf and scalbn

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Andrew John Hughes from comment #3)
> No, this is a Classpath bug. Nothing to do with GCJ.

Does it make sense for Classpath and GCC to continue to share a bugzilla these
days? This is far from the only time I've been confused by it... would it be
possible to split them into 2 separate bug databases?

[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
I've been trying to reproduce this, but failing - I tried with today's trunk,
and with a build from 2018-11-16.

Do you have a revision that is known to trigger the ICE?

[Bug objc++/58783] Fast enumeration is not supported for Objective-C++

[egallager at gcc dot gnu.org]

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

--- Comment #9 from Eric Gallager  ---
(In reply to Eric Gallager from comment #8)
> I recently ran into this with the Cocoa interface for DeSmuME, which also
> tries to use fast enumeration from Objective-C++. So maybe this should be
> re-titled to reflect the fact that it's a more general issue with fast
> enumeration in Objective-C++, and not anything Qt5-specific.

Thanks to FX for doing the retitling

[Bug target/49743] -g enables var_tracking on -O0 - causes long compilations

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Gary Funck from comment #3)
> Recently, I've been reviewing changes that we made on the GUPC branch (see
> comment #2) that are candidates for the trunk revision (or in this case,
> possibly the 4.7 branch).
> 
> Index: gcc/config/darwin.c
> ===
> --- gcc/config/darwin.c (.../trunk) (revision 190707)
> +++ gcc/config/darwin.c (.../branches/gupc) (revision 190718)
> @@ -3039,6 +3039,7 @@ darwin_override_options (void)
>  }
> 
>if (flag_var_tracking
> +  && optimize >= 1
>&& generating_for_darwin_version >= 9
>&& (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE)
>: (debug_info_level >= DINFO_LEVEL_NORMAL))
> 
> Reading the problem description, unless the option scanning logic has
> changed for Darwin, it looks as if this change might still be necessary to
> suppress var tracking at -O0?

Any plans to resubmit the GUPC branch again?

[Bug other/87695] Arduino: ICE with avr and LTO

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||WOLFCREEK1 at COX dot NET

--- Comment #7 from Andrew Pinski  ---
*** Bug 88665 has been marked as a duplicate of this bug. ***

[Bug lto/88665] Arduino: 1.8.8 (Windows Store 1.8.19.0) (Windows 10), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
Version|unspecified |5.1.0
  Component|classpath   |lto
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE
Product|classpath   |gcc

--- Comment #1 from Andrew Pinski  ---
Dup of bug 87695.  NOTE you filed this bug under classpath which is wrong.

*** This bug has been marked as a duplicate of bug 87695 ***

[Bug c/448] -related issues (C99 issues)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Target|i686-pc-linux-gnu   |netbsd, VxWorks, SymbianOS,
   ||LynxOS, QNX, TPF
 CC||hainque at adacore dot com,
   ||kristerw at netbsd dot org,
   ||thorpej at gcc dot gnu.org

--- Comment #39 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #38)
> I think the correct state is NEW.  There is a well-defined set of target 
> OSes that lack the target macro definitions describing those targets' 
> stdint.h types, each of which should be straightforward to fix for someone 
> with access to the target OS in question to examine its headers and run 
> tests.

That's still these ones, right?

(In reply to jos...@codesourcery.com from comment #31)
> The following targets still appear to be missing this type information in 
> GCC: some NetBSD targets (netbsd-stdint.h only used for x86 / x86_64), 
> VxWorks, SymbianOS, LynxOS, QNX, TPF.  Others have either been fixed, or 
> obsoleted and removed.

cc-ing maintainers of those ports

[Bug testsuite/87304] [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Applied.

[Bug middle-end/88663] [9 Regression] internal compiler error: in check, at tree-vrp.c:188

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #5 from Jeffrey A. Law  ---
Should be fixed on the trunk now.

[Bug target/60563] FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe  ---
well.. given the amount of time that's passed - perhaps we'll only get a fix
for ld64 if we do it ourselves...

What about xfail-run-if - to reduce test noise, and then when (if?) ld64 gets
fixed it will "xpass" alerting us to the change?

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #21 from Gary Mills  ---
> Most of the words in the title are wrong now.  I'm attempting to build gcc-7
> now.  The ICE occurs on both SPARC and x86 systems.  It only happens with the

Which version of /bin/as are you using on Solaris/x86?

And before trying to debug this further, could you please try a
bootstrap with the bare minimum of configure options and no local
patches: from what I see in your Comment #11, that would be

CC=/usr/gcc/4.9/bin/gcc these are a 32-bit-default compilers, I assume?
CXX=/usr/gcc/4.9/bin/g++
--enable-languages=c,c++
--without-gnu-ld --with-ld=/usr/bin/ld
--without-gnu-as --with-as=/usr/bin/as

Certainly omit --with-initfini-array: if the configure test doesn't
detect it, there may be a problem (e.g. in ld) here.

Can you bootstrap a previous unmodified version of GCC (e.g. 4.9.x) in a
similar way and use that instead of the bundled one?  Maybe there's
already a problem with your bootstrap compiler.

If 4.9.x bootstraps fine and 4.9.x -> 7.x doesn't, try the last releases
from each branch (5.x, 6.x) in turn, starting with 4.9.x -> 5.x; then
5.x -> 6.x; then 6.x -> 7.x.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
What about this modified test case?

  struct S *p;

  void f(void);

  int main()
  {
f();

&*p;
  }

  struct S { int x; };

  void f()
  {
static struct S s = { 0 };
p = 
  }

It gives the same error message (using the same compilation command line), and
there is no lvalue to rvalue conversion of *p in this case, because of the
operator & .

Clang accept that test case without any errors.

[Bug debug/88635] [8 Regression] Assembler error when building with "-g -O2 -m32"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45321
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45321=edit
gcc9-pr88635.patch

Untested fix.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #21 from Gary Mills  ---
Most of the words in the title are wrong now.  I'm attempting to build gcc-7
now.  The ICE occurs on both SPARC and x86 systems.  It only happens with the
native assembler.  The result is a structure that contains many NULL pointers,
which cause a segmentation violation when xgcc dereferences one of the NULL
pointers.

I've been attempting to find the origin of this structure by examining the
source, without success.  Can someone show me a debugging technique that will
reveal the origin of this structure?

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
If this is a new regression please open a new bug for it.  It's probably a
fallout from r267503 or one of the other related changes.

[Bug debug/88644] [7/8/9 Regression] Unexpected pub type info eliminated after r246973 (causes pubtypes-*.c to regress).

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
will do a complete test suite run now, to catch any other changed lengths.

[Bug c/88582] GCC does not unqualify return types in the case of _Atomic qualified return type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

--- Comment #5 from Anders Granlund  ---
Thanks for the explanation.

[Bug tree-optimization/84478] [8 Regression] pdftex miscompilation on i386

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #5 from Rainer Orth  ---
The new testcase FAILs e.g. on i386-pc-solaris2.11 and sparc-sun-solaris2.11
(32-bit only) at -O1 and above:

+FAIL: gcc.c-torture/execute/pr84478.c   -O1  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O2  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O2 -flto  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O2 -flto -flto-partition=none 
execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
+FAIL: gcc.c-torture/execute/pr84478.c   -O3 -g  execution test

According to gcc-testresult postings, the same happens on a couple of other
targets, including i686-pc-linux-gnu.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #2 from Anders Granlund  ---
Thanks. That explains it.

[Bug debug/88644] [7/8/9 Regression] Unexpected pub type info eliminated after r246973 (causes pubtypes-*.c to regress).

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
works for me with following addition to correct the length of the (now correct)
subtypes sections.

-

diff --git a/gcc/testsuite/gcc.dg/pubtypes-2.c
b/gcc/testsuite/gcc.dg/pubtypes-2.c
index 3ac3a38..6669f3d 100644
--- a/gcc/testsuite/gcc.dg/pubtypes-2.c
+++ b/gcc/testsuite/gcc.dg/pubtypes-2.c
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x12e+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */

diff --git a/gcc/testsuite/gcc.dg/pubtypes-3.c
b/gcc/testsuite/gcc.dg/pubtypes-3.c
index 6fa1940..345e4ed 100644
--- a/gcc/testsuite/gcc.dg/pubtypes-3.c
+++ b/gcc/testsuite/gcc.dg/pubtypes-3.c
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x12e+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "\"list_name_type0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
diff --git a/gcc/testsuite/gcc.dg/pubtypes-4.c
b/gcc/testsuite/gcc.dg/pubtypes-4.c
index b2f520d..da2f9b0 100644
--- a/gcc/testsuite/gcc.dg/pubtypes-4.c
+++ b/gcc/testsuite/gcc.dg/pubtypes-4.c
@@ -2,7 +2,7 @@
 /* { dg-options "-O0 -gdwarf-2 -dA" } */
 /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } } */
 /* { dg-final { scan-assembler "__debug_pubtypes" } } */
-/* { dg-final { scan-assembler "long+\[ \t\]+0x172+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
+/* { dg-final { scan-assembler "long+\[ \t\]+0x165+\[ \t\]+\[#;]+\[ \t\]+Pub
Info Length" } } */
 /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */
 /* { dg-final { scan-assembler "\"list_name_type0\"+\[ \t\]+\[#;]+\[
\t\]+external name" } } */

[Bug testsuite/87304] [9 regression] gcc.dg/vect/bb-slp-over-widen-1.c fails starting with r262371

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jan  2 19:50:13 2019
New Revision: 267528

URL: https://gcc.gnu.org/viewcvs?rev=267528=gcc=rev
Log:
PR testsuite/87304
* gcc.dg/vect/bb-slp-over-widen-1.c: Expect basic block vectorized
messages only on vect_hw_misalign targets.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-over-widen-1.c

[Bug tree-optimization/88659] [9 Regression] ICE in maybe_warn_nonstring_arg at gcc/calls.c:1688 since r267503

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-02
 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Let me handle it.

[Bug tree-optimization/88605] vector extensions: Widening or conversion generates inefficient or scalar code.

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On January 2, 2019 6:42:00 PM GMT+01:00, husseydevin at gmail dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88605
>
>--- Comment #4 from Devin Hussey  ---
>I also want to note that LLVM is probably a good place to look. They
>have been
>pushing to remove as many intrinsic builtins as they can in favor of
>idiomatic
>code.
>
>This has multiple advantages:
>1. You can open up  and see what x intrinsic really does
>(many
>SIMD instructions have inadequate documentation)
> 2. Platform independent intrinsic headers
> 3. More useful vector extensions
>
>Should we make a metabug for this?
>Such as "Improve vector extension pattern recognition" or something?

I think we have one for the generic vector extension where this would fit. If
kit create one.

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[hubicka at ucw dot cz]

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

--- Comment #24 from Jan Hubicka  ---
> Patch needs ">>>" to be repaced by "> > >" to bootstrap, but then I get 756
> mismatches building firefox, while previously it was 1300 and before the
> rebuild_type_inheritance_graph 6273, so we are improving.  I will look into 
> the
> remaining cases.

Actually I was wrong - grepped wrong file. Still 1300 warnings.  I am
looking into that - perhaps these are same problems.

Still I think the patch for uncprop makes sense.

Honza

[Bug target/88638] [9 Regression] FAIL: *string-format-1.* on darwin

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-02
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
At a minimum, the warning on line 15 is not intended.  The change in r266195
needs to also take Objective C strings into account analogously to how they are
being handled by valid_stringptr_type_p() in c-format.c.

[Bug target/88638] [9 Regression] FAIL: *string-format-1.* on darwin

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug debug/88644] [7/8/9 Regression] Unexpected pub type info eliminated after r246973 (causes pubtypes-*.c to regress).

[jakub at gcc dot gnu.org]

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

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 45320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45320=edit
gcc9-pr88644.patch

Untested fix.

[Bug tree-optimization/88666] New: GCC 8.2.- gets Internal Compiler Error: seg fault; GCC 8.1.0 works fine

[geir at cray dot com]

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

Bug ID: 88666
   Summary: GCC 8.2.- gets Internal Compiler Error: seg fault;
GCC 8.1.0 works fine
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geir at cray dot com
  Target Milestone: ---

Simple reproducer code causes a seg fault during compile with gcc 8.2.0. The
reproducer does not seg fault for gcc 8.1.0

$ cat repro.c
#include 
#include 
#include 
#include 

int64_t foo (int64_t max, FILE *in)

{
  int64_t count = 0;
  const int64_t MAXLINE  = 1024;
  char buff[MAXLINE];

  while (!feof(in) && count < max) {
if (fgets(buff, sizeof(buff), in) != NULL) {

  // gcc 8.2 segfaults !!
  if (strncmp ([0], "QUIT", 4) == 0)
break;

  // this is OK:
  if (strncmp (buff, "QUIT", 4) == 0)
break;

}
  }

  return count;
}
$ gcc --version
gcc (GCC) 8.1.0 20180502 (Cray Inc.)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c repro.c
$ module swap gcc/8.1.0 gcc/8.2.0
$ gcc --version
gcc (GCC) 8.2.0 20180726 (Cray Inc.)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -c repro.c
during RTL pass: expand
repro.c: In function 'foo':
repro.c:17:11: internal compiler error: Segmentation fault
   if (strncmp ([0], "QUIT", 4) == 0)
   ^
0xa8de4f crash_signal
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/toplev.c:325
0x6eeb25 wi::extended_tree<192>::get_len() const
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/tree.h:5572
0x6eeb25 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:934
0x6eeb25 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:983
0x6eeb25 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:758
0x6eeb25 bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:1849
0x6eeb25 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
 >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/wide-int.h:3170
0x6eeb25 tree_int_cst_lt(tree_node const*, tree_node const*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/tree.h:5728
0x6eeb25 maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:1716
0x6f053a maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:1627
0x6f053a initialize_argument_information
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:2321
0x6f053a expand_call(tree_node*, rtx_def*, int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/calls.c:3713
0x6e4286 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/builtins.c:6656
0x7f1679 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/expr.c:11005
0x7fa35b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/expr.c:5635
0x7fb5b3 expand_assignment(tree_node*, tree_node*, bool)
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/expr.c:5403
0x7015d8 expand_call_stmt
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:2688
0x7015d8 expand_gimple_stmt_1
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:3624
0x7015d8 expand_gimple_stmt
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:3790
0x70287f expand_gimple_basic_block
../../cray-gcc-8.2.0-201808172015.9a091ef8ec76a/gcc/cfgexpand.c:5819
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

--- Comment #23 from Jan Hubicka  ---
Patch needs ">>>" to be repaced by "> > >" to bootstrap, but then I get 756
mismatches building firefox, while previously it was 1300 and before the
rebuild_type_inheritance_graph 6273, so we are improving.  I will look into the
remaining cases.

Can't the type sharing difference come from GTY((cache)) use in tree.h?

[Bug middle-end/88663] [9 Regression] internal compiler error: in check, at tree-vrp.c:188

[law at gcc dot gnu.org]

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

--- Comment #4 from Jeffrey A. Law  ---
Author: law
Date: Wed Jan  2 18:30:50 2019
New Revision: 267520

URL: https://gcc.gnu.org/viewcvs?rev=267520=gcc=rev
Log:
PR middle-end/88663
* gimple-fold.c (get_range_strlen): Update prototype to no longer
need the flexp argument.
(get_range_strlen_tree): Drop flexp argument.  Drop flexp argument
from calls to get_range_strlen.  Update comments.  Just update
VAL for an unterminated const char array and let the reset of the
code handle it normally.  No longer try to set *flexp.  Adjust
return value.
(get_range_strlen): Update for the new get_range_strlen API.
(get_maxval_strlen): Similarly.
(gimple_fold_builtin_strlen): Handle update meaning of return value
from get_range_strlen.
* gimple-ssa-sprintf.c (get_string_length): Update for the new
get_range_strlen API.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-ssa-sprintf.c

[Bug c/88642] Accepts ill-formed program with invalid scalar initialization syntax.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  Clang rejects the code with

$ clang -S --pedantic-errors pr88642.c
pr88642.c:4:15: error: too many braces around scalar initializer
  [-Werror,-Wmany-braces-around-scalar-init]
int x = { { 0 } };
  ^
1 error generated.

[Bug c++/85052] Implement support for clang's __builtin_convertvector

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 45319
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45319=edit
gcc9-pr85052.patch

Untested implementation.  Some further work is needed to improve code
generation for the narrowing or widening conversions.

[Bug c++/87729] Please include -Woverloaded-virtual in -Wall

[bugzi...@poradnik-webmastera.com]

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

--- Comment #2 from Daniel Fruzynski  ---
Here you are:

[code]
class Foo
{
public:
virtual void f(int);
};

class Bar : public Foo
{
public:
virtual void f(short);
};
[/code]

[Bug c++/88600] GCC rejects attributes on type aliases, while clang accepts them

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-02
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
The grammar implies the original form of the alias-declaration should be
accepted with standard C++ attributes so I think it would make sense to accept
it with GNU attributes as well:

  alias-declaration:
using identifier attribute-specifier-seq opt = defining-type-id;

  defining-type-id:
defining-type-specifier-seq abstract-declarator opt

  defining-type-specifier-seq:
defining-type-specifier attribute-specifier-seq opt
defining-type-specifier defining-type-specifier-seq

With that, I would expect the following two declarations to be equivalent:

  template 
  using U = __attribute__ ((__vector_size__ (8))) T;

  template 
  using V = [[gnu::vector_size (8)]] T;

Here GCC rejects both forms while Clang accepts the GNU form but (ironically)
rejects the standard form.

[Bug tree-optimization/88605] vector extensions: Widening or conversion generates inefficient or scalar code.

[husseydevin at gmail dot com]

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

--- Comment #4 from Devin Hussey  ---
I also want to note that LLVM is probably a good place to look. They have been
pushing to remove as many intrinsic builtins as they can in favor of idiomatic
code.

This has multiple advantages:
 1. You can open up  and see what x intrinsic really does (many
SIMD instructions have inadequate documentation)
 2. Platform independent intrinsic headers
 3. More useful vector extensions

Should we make a metabug for this?
Such as "Improve vector extension pattern recognition" or something?

[Bug c++/86875] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Done.

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

--- Comment #22 from Jan Hubicka  ---
Created attachment 45318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45318=edit
patch for operand_equal_p in tree-ssa-uncprop

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

--- Comment #21 from Jan Hubicka  ---
Looks like last minute change in this patch
https://gcc.gnu.org/ml/gcc-cvs/2014-06/msg00838.html
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01600.html

[Bug c++/86875] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Wed Jan  2 17:07:02 2019
New Revision: 267519

URL: https://gcc.gnu.org/viewcvs?rev=267519=gcc=rev
Log:
PR c++/86875
* g++.dg/cpp1y/lambda-generic-86875.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-86875.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de  ---
On January 2, 2019 5:25:09 PM GMT+01:00, "hubicka at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
>--- Comment #19 from Jan Hubicka  ---
>gcc 5 has:
>inline bool
>
>val_ssa_equiv_hash_traits::equal_keys (tree value1, tree value2)   
>
>{  
>
>return operand_equal_p (value1, value2, 0);
>  
>}  
>
>
>/* Free an instance of equiv_hash_elt.  */ 
>
>
>template   
>
>inline void
>
>val_ssa_equiv_hash_traits::remove (T ) 
>
>{  
>
>elt.m_value.release ();
>  
>}  
>
>
>while in mainline we seem to compare addresses... Looks like wrong
>update to
>hash_map.

But still it doesn't explain differences in tree sharing between stage2 and
three. 

But yes, I'll go track things down a bit more.

[Bug demangler/88539] A memory leak issue was discovered in cplus-dem.c

[nsl at fireeye dot com]

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

nsl at fireeye dot com changed:

   What|Removed |Added

 CC||nsl at fireeye dot com

--- Comment #2 from nsl at fireeye dot com ---
This looks to be CVE-2018-20657.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
6.3.2.1#2 (conversion of lvalues to rvalues): "If the lvalue has an 
incomplete type and does not have array type, the behavior is undefined.".  
Cf. bug 36941 (noting how DR#106 confuses things by allowing dereferences 
of pointers to qualified void).

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
gcc 5 has:
inline bool 
val_ssa_equiv_hash_traits::equal_keys (tree value1, tree value2)
{   
  return operand_equal_p (value1, value2, 0);   
}   

/* Free an instance of equiv_hash_elt.  */  

template
inline void 
val_ssa_equiv_hash_traits::remove (T )  
{   
  elt.m_value.release ();   
}   

while in mainline we seem to compare addresses... Looks like wrong update to
hash_map.

[Bug middle-end/88663] [9 Regression] internal compiler error: in check, at tree-vrp.c:188

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
I guess I should have kept going last night, this is fixed by the next patch in
the series.  I thought I had all the dependencies between them resolved, but
clearly not.  I'll have this fixed shortly.

[Bug c++/81239] std::__cxx11::string& visible in gcc warning output

[jg at jguk dot org]

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

--- Comment #10 from Jonny Grant  ---
Would you agree "abi11" would not have suffered the "cxx11" ambiguity?
Hope this can be avoided next time another ABI needs to be added to accommodate
a change in language behaviour.

[Bug c++/86875] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Confirmed it's fixed now.  Reducing & adding the testcase then.

[Bug lto/88585] [9 Regression] ICE in fld_incomplete_type_of, at tree.c:5295

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

  Component|ipa |lto

--- Comment #2 from Jan Hubicka  ---
Changing component to LTO.
This fails on the sanity check:
5295  gcc_assert (TYPE_CANONICAL (t2) != t2
5296  && TYPE_CANONICAL (t2) == TYPE_CANONICAL
(TREE_TYPE (t)));

which is supposed to check that TYPE_CANONICAL of newly created pointer to t2
points to right place.

In this case t2 is:
 
pointer_to_this >

which is incomplete version of its TYPE_CANONICAL:
(gdb) p debug_tree (t2->type_common.canonical)
  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77234348
fields  unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x771005e8 precision:32 min  max

pointer_to_this >
packed SI t.c:1:16 size  unit-size

align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context 
pointer_to_this >

TREE_TYPE (t) is:
(gdb) p debug_tree (t->typed.type)
  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7720fdc8
fields  unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x771005e8 precision:32 min  max

pointer_to_this >
packed SI t.c:1:16 size  unit-size

align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context 
pointer_to_this >

and TYPE_CANONICAL (TREE_TYPE (t)) is:
  constant 32>
unit-size  constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7720fdc8
fields  unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x771005e8 precision:32 min  max

pointer_to_this >
packed SI t.c:1:16 size  unit-size

align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context 
pointer_to_this >

So we have two versions of the packed structure, I am not sure why?

[Bug lto/88140] [9 Regression] ICE: verify_gimple failed since r266325

[hubicka at gcc dot gnu.org]

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

--- Comment #12 from Jan Hubicka  ---
I have committed the workaround as:
r267398 | hubicka | 2018-12-24 12:21:25 +0100 (Mon, 24 Dec 2018) | 6 lines


* tree.c (fld_simplified_type): Temporarily disable array
simplification.

* gcc.c-torture/pr88140.c: New testcase.

forgot to cut the PR specifier into the commit log.
Shall we retarget this to GCC 10 now?

[Bug lto/87089] [9 regression] tree check: expected class 'type', have 'declaration' (namespace_decl) in type_with_linkage_p, at ipa-utils.h

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||jason at redhat dot com

--- Comment #9 from Jan Hubicka  ---
This is caused by:

_ZN4itpp1cILNS_1aE0EED2Ev/1 (itpp::c< >::~c() [with itpp::a
 = itpp::b]) @0x770e9438
  Type: function definition analyzed
  Visibility: forced_by_abi public weak comdat_group:_ZN4itpp1cILNS_1aE0EED5Ev
one_only
  Same comdat group as: _ZN4itpp1cILNS_1aE0EED1Ev/2 
  Address is taken. 
  Aux: @0x770e95a0  
  References: _ZTVN4itpp1cILNS_1aE0EEE/4 (addr)__gxx_personality_v0/8 (addr)
  Referring: _ZN4itpp1cILNS_1aE0EED1Ev/2 (alias)
  Function flags: body  
  Called by:
  Calls: itpp::CFix::~CFix()/7

this is a destructor which is pointed to from virutal table, but it has no
DECL_VIRTUAL_P flag set. This makes free_lang_data to modify its context and
point to outer namespace rather than the containing polymorphic type.

Why we do not set VIRTUAL_P here?

[Bug bootstrap/88623] gcc build uses CXX_FOR_BUILD but files have .c extension

[andrew at ishiboo dot com]

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

--- Comment #4 from Andrew Paprocki  ---
... relying on the fact that `g++` will compile the `.c` files as C.

[Bug bootstrap/88623] gcc build uses CXX_FOR_BUILD but files have .c extension

[andrew at ishiboo dot com]

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

--- Comment #3 from Andrew Paprocki  ---
Sorry, I said 'libgcc', but I meant the 'gcc/' sub-directory. It is always
using the C++ compiler for the build and relying on the fact that `g++`

[Bug lto/85574] [8/9 Regression] LTO bootstapped binaries differ

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
OK, so it looks like uncprop causes a lot of differences (minor dump
differences
appear from profile-estimate and printf-return-value2 as well).

--- prev-gcc/cc1.ltrans99.196t.uncprop1 2019-01-02 16:06:25.701672034 +0100
+++ gcc/cc1.ltrans99.196t.uncprop1  2019-01-02 16:19:03.713847999 +0100
@@ -20478,7 +20478,7 @@
[local count: 28992085]:
   # reject_602 = PHI 
   # this_alternative_850 = PHI 
-  # _44 = PHI <_(229), _(656), _(657), _(659), 1(655),
_(658), 1(873)>
+  # _44 = PHI <_(229), _(656), _(657), _(659), _(655),
_(658), 1(873)>
   # DEBUG reject => reject_602
   # DEBUG BEGIN_STMT
   # DEBUG this_alternative_offmemok => offmemok_671

[Bug fortran/88658] [9 Regression] Intrinsic MAX1 returns a REAL result, should be INTEGER.

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug fortran/48543] Collapse identical strings

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #4 from Thomas Koenig  ---
Fixed (by whoever did this, thanks!) and test case committed, closing.

[Bug c++/81486] Class template argument deduction fails with (), succeeds with {}

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
The examples now compile with my patch for PR 88631.  I'll add them to the
testsuite.  Thanks for reporting them.

[Bug c++/88631] CTAD cannot deduce from () value initialization

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Yup, my patch fixes all the examples in PR 81486 as well.  I think the
testcases are worth adding.

[Bug fortran/48543] Collapse identical strings

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Jan  2 15:25:47 2019
New Revision: 267517

URL: https://gcc.gnu.org/viewcvs?rev=267517=gcc=rev
Log:
2019-01-02  Thomas Koenig  

PR fortran/48543
* gfortran.dg/const_chararacter_merge.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/const_chararacter_merge.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug lto/88130] [9 Regression] ICE in copy_function_or_variable, at lto-streamer-out.c:2315 since r260963

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
This is fixed on mainline, but we should backport to gcc 7 and 8.

[Bug c++/88664] False positive -Waddress-of-packed-member

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Wed Jan  2 15:23:56 2019
New Revision: 267516

URL: https://gcc.gnu.org/viewcvs?rev=267516=gcc=rev
Log:
gcc/cp/
* cxx-mapper.cc (server): Workaround PR c++/88664.

Modified:
branches/c++-modules/ChangeLog.modules
branches/c++-modules/gcc/cp/cxx-mapper.cc

[Bug lto/88130] [9 Regression] ICE in copy_function_or_variable, at lto-streamer-out.c:2315 since r260963

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Author: hubicka
Date: Wed Jan  2 15:23:27 2019
New Revision: 267515

URL: https://gcc.gnu.org/viewcvs?rev=267515=gcc=rev
Log:

PR lto/88130
* varpool.c (varpool_node::ctor_useable_for_folding_p): Also return
false at WPA time when body was removed.
* g++.dg/torture/pr88130.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr88130.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c

[Bug middle-end/88663] [9 Regression] internal compiler error: in check, at tree-vrp.c:188

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-02
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com
 Ever confirmed|0   |1

--- Comment #2 from Jeffrey A. Law  ---
A couple of my tester targets tripped this overnight.  Mine.

[Bug c++/88664] New: False positive -Waddress-of-packed-member

[nathan at gcc dot gnu.org]

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

Bug ID: 88664
   Summary: False positive -Waddress-of-packed-member
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45316=edit
extracted from code using epoll_event structure

nathans@devvm2452:29>./cc1plus -Waddress-of-packed-member ../../../packed.cc
-quiet
../../../packed.cc: In function 'void foo(epoll_event*)':
../../../packed.cc:10:49: warning: taking address of packed member of
'epoll_event' may result in an unaligned pointer value
[-Waddress-of-packed-member]
   10 |   int *actionable = static_cast  (event->ptr);
  |  ~~~^~~

But we're not taking the address of the packed field, we're converting the
value the field holds to a different pointer.

epoll_event is packed, and I imagine more code than mine squirrels away data
pointers in its data field.  I suppose the FE could internally be taking a
reference to preserve lvalueness ...

[Bug middle-end/88663] [9 Regression] internal compiler error: in check, at tree-vrp.c:188

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |9.0

--- Comment #1 from Richard Biener  ---
So bogus range-info set...