[Bug testsuite/81807] [8 Regression] many *.cc asan tests fail

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Jeffrey A. Law  ---
My recollection is the test harness doesn't pick up the .cc files so those
tests weren't being run.  We had a patch to pick up the .cc files in the test
harness which got installed and the tests mentioned in c#0 all failed across
the board for every target.  As a result the test harness patch got reverted.

So we've still got these .cc files in the testsuite which don't work in any way
shape or form.  Ideally we'd figure out why so that we could use those tests.

We could certainly drop the regression marker here and just track this as a
request to make those tests work across the targets that support asan.

[Bug c++/83138] New: ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration

[hstong at ca dot ibm.com]

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

Bug ID: 83138
   Summary: ICE: Segfault expanding function parameter pack in
subsequent sibling pack declaration
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

Given the self-contained source below, GCC ICEs with a segmentation fault.
This used to work with GCC 4.7.4.

### SOURCE ():
template  void f(T ...args, char ...args2[][sizeof args]) { }
template  void g(T) { }
void h() { g(); }


### ACTUAL OUTPUT:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


### EXPECTED OUTPUT:
Clean compile.


### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -x c++ -std=c++11 -


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20171122 (experimental) (GCC)

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Thanks!

[Bug c++/83137] New: Member function pointer template parameter not constant expression when set to nullptr

[erik2003 at u dot washington.edu]

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

Bug ID: 83137
   Summary: Member function pointer template parameter not
constant expression when set to nullptr
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erik2003 at u dot washington.edu
  Target Milestone: ---

Created attachment 42700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42700=edit
minimal bug example with additional context

When using if constexpr(), GCC claims a member function pointer template
parameter isn't a constant expression if set to nullptr. This does not happen
if the member function pointer points to a real function, or if a raw function
pointer is used instead. Replacing nullptr with (void (Fake::*)())0 or (void
(Fake::*)())NULL produces the same error.

This code compiles in clang but generates an error in GCC:

struct Fake { };

template
void MemberTest()
{
  if constexpr(SET == nullptr)
return;
}

int main()
{
  MemberTest();
}

gccbug.cpp: In instantiation of ‘void MemberTest() [with T = Fake; void (T::*
SET)() = void (Fake::*)(){0, 0}]’:
gccbug.cpp:20:29:   required from here
gccbug.cpp:6:20: error: ‘(void (Fake::*)(){0, 0}.void (Fake::*)()::__pfn == 0)’
is not a constant expression
   if constexpr(SET == nullptr)
^~

This was tested on GCC 7.1.1 and 7.2.0, and is similar to Bug 56428, but
applies to member function pointers only and is triggered by setting the member
function pointer to nullptr instead of comparing it to nullptr.

[Bug libfortran/78549] Very slow formatted internal file output

[manfred99 at gmx dot ch]

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

--- Comment #29 from Manfred Schwarb  ---
Here are the results from my test case from PR82938 
(without the "print*,f" statement, which consumes ~1s):

  1.1s for GNU Fortran (GCC) 8.0.0 20170828 (experimental) [trunk revision
251373]
  3.3s for GNU Fortran (GCC) 8.0.0 20170829 (experimental) [trunk revision
251395]
  1.3s for GNU Fortran (GCC) 8.0.0 20171123 (experimental) [trunk revision
255090]
  0.4s for version with Fortran wrapper of C function strtof()

So, with Jerry's patch gfortran is now only a little slower than before
the DTIO patches, so still some minor regression for internal read. 

But there is still some large gap compared to the C routine version...

[Bug fortran/83064] DO CONCURRENT inconsistent results

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> I looked at the IL from the Fortran FE and it clearly uses a single memory
> area for tmp for each outer loop iteration. That is, the memory is allocated
> by the caller. 

I confirm that using

pik = compute( low(i), high(i) )
pi(i) = sum(pik)

gives the right result.

Does it means that the 'sum' in 'sum(compute( low(i), high(i) ))' is not part
of the parallelization?

> > Do you understand why the code is not parallelized with
> > -ftree-parallelize-loops=4?

> Because the outer loop has four iterations and we statically require
> at least two per thread for outer loops. 

Why is it so? and is it documented?

[Bug ada/83091] ICE with -g in arm-eabi compilation

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #7 from Eric Botcazou  ---
.

[Bug ada/83091] ICE with -g in arm-eabi compilation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Nov 23 22:55:05 2017
New Revision: 255125

URL: https://gcc.gnu.org/viewcvs?rev=255125=gcc=rev
Log:
PR ada/83091
* gcc-interface/decl.c (gnat_to_gnu_entity): Do not build a variant
type for the implementation type of a packed array.

Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c

[Bug libstdc++/83134] std::negation uses !B::value instead of !bool(B::value)

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Thu Nov 23 21:35:27 2017
New Revision: 255122

URL: https://gcc.gnu.org/viewcvs?rev=255122=gcc=rev
Log:
PR libstdc++/83134 Ensure std::__not_ converts B::value to bool

PR libstdc++/83134
* include/std/type_traits (__not_): Explicitly convert to bool.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error.
* testsuite/20_util/logical_traits/83134.cc: New test.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Adjust
dg-error.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Added:
trunk/libstdc++-v3/testsuite/20_util/logical_traits/83134.cc
  - copied, changed from r255096,
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
   
trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc

[Bug c++/83136] New: static class template member: invalid application of ‘sizeof’ to incomplete type

[steve.lorimer at gmail dot com]

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

Bug ID: 83136
   Summary: static class template member: invalid application of
‘sizeof’ to incomplete type
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steve.lorimer at gmail dot com
  Target Milestone: ---

Created attachment 42699
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42699=edit
example source code illustrating bug

Compiling the below example results in the following error

---

In instantiation of ‘struct Storage’:
   required from ‘struct Bar’
 error: invalid application of ‘sizeof’ to incomplete type ‘Bar’
  std::aligned_storage_t data[N];

---

#include 
#include 

template
struct Storage
{
std::aligned_storage_t data[N];
};

template
struct PoolObj
{
static void* operator new(std::size_t size)
{
return ::pool.data[0];
}

static void operator delete(void* p, std::size_t size)
{
}
};

template
struct Bar : PoolObj
{
static Storage pool;
};

template
Storage Bar::pool {};

int main()
{
Bar* b = new Bar();
delete b;

return 0;
}

[Bug fortran/79072] ICE with class(*) pointer function result and character value

[pault at gcc dot gnu.org]

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

--- Comment #20 from Paul Thomas  ---
Author: pault
Date: Thu Nov 23 21:02:48 2017
New Revision: 255120

URL: https://gcc.gnu.org/viewcvs?rev=255120=gcc=rev
Log:
2017-11-23  Paul Thomas  


Backported from trunk
PR fortran/79072
* trans-expr.c (trans_class_vptr_len_assignment): Set from_len
if the temporary is unlimited polymorphic.
* trans-stmt.c (trans_associate_var): Use the fake result decl
to obtain the 'len' field from an explicit function result when
in that function scope.

2017-11-23  Paul Thomas  

Backported from trunk
PR fortran/79072
* gfortran.dg/class_result_5.f90: New test.
* gfortran.dg/class_result_6.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_result_5.f90
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_result_6.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/trans-expr.c
branches/gcc-7-branch/gcc/fortran/trans-stmt.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/83135] New: Routines in submodules treat protected variables from other modules as public

[ying.zhu at doctorant dot ec-lyon.fr]

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

Bug ID: 83135
   Summary: Routines in submodules treat protected variables from
other modules as public
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ying.zhu at doctorant dot ec-lyon.fr
  Target Milestone: ---

Created attachment 42698
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42698=edit
Code to illustrate the bug

I define a variable xx in mod1 with protected attribute, then use mod1 in mod2.
echo_xx is a submodule subroutine implemented in a submodule of mod2, then I
find echo_xx can change the value of xx and gnu fortran allows this when
compiling and running, protected attribute doesn't work at all. 
Meanwhile, the value of xx can not be changed in main program or other module
subroutines not submodule subroutines. Thant means, this bug is only related to 
submodules.

[Bug rtl-optimization/82621] [6/7 Regression] wrong code with -Og -fgcse -fweb

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
*** Bug 81291 has been marked as a duplicate of this bug. ***

[Bug fortran/81841] [6/7/8 Regression] THREADPRIVATE (OpenMP) wrongly rejected in BLOCK DATA

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 23 20:16:38 2017
New Revision: 255115

URL: https://gcc.gnu.org/viewcvs?rev=255115=gcc=rev
Log:
PR fortran/81841
* parse.c (parse_spec): Allow ST_OMP_THREADPRIVATE inside of
BLOCK DATA.

* libgomp.fortran/pr81841.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.fortran/pr81841.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/libgomp/ChangeLog

[Bug target/81291] [6/7 Regression] wrong code with -O2 -fno-rerun-cse-after-loop -fno-tree-ter -fno-tree-vrp -funroll-loops due to improper carry

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Segher Boessenkool  ---
Closing as dup then.

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

[Bug ada/83091] ICE with -g in arm-eabi compilation

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> The tentative patch solves all the -g errors.

Great, thanks for the feedback.

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
ytrium also bootstraps for me.  I see you use release checking for stage1 that
may be the trigger, I will try it now.

[Bug libstdc++/83134] std::negation uses !B::value instead of !bool(B::value)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-23
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |7.3
 Ever confirmed|0   |1

[Bug libstdc++/83134] New: std::negation uses !B::value instead of !bool(B::value)

[redi at gcc dot gnu.org]

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

Bug ID: 83134
   Summary: std::negation uses !B::value instead of
!bool(B::value)
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct X {
  constexpr operator bool() const { return false; }
  constexpr bool operator!() const = delete;
};

struct Y {
  static constexpr X value{};
};

int main() {
  static_assert(std::negation::value);  
}

In file included from neg.cc:1:0:
/home/jwakely/gcc/8/include/c++/8.0.0/type_traits: In instantiation of ‘struct
std::__not_’:
/home/jwakely/gcc/8/include/c++/8.0.0/type_traits:172:12:   required from
‘struct std::negation’
neg.cc:13:33:   required from here
/home/jwakely/gcc/8/include/c++/8.0.0/type_traits:154:38: error: use of deleted
function ‘constexpr bool X::operator!() const’
 : public integral_constant
  ^~~~
neg.cc:5:18: note: declared here
   constexpr bool operator!() const = delete;
  ^~~~
neg.cc: In function ‘int main()’:
neg.cc:13:35: error: ‘value’ is not a member of ‘std::negation’
   static_assert(std::negation::value);
   ^

[Bug ada/83091] ICE with -g in arm-eabi compilation

[simon at pushface dot org]

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

--- Comment #4 from simon at pushface dot org ---
The tentative patch solves all the -g errors.

My report in comment 1 is solved by patches for pr 82816 and pr 82875.

[Bug target/83114] [5/6/7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #4 from amker at gcc dot gnu.org ---
I think this duplilcates PR81228.  See
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01915.html, also see PR81647.

[Bug libfortran/78549] Very slow formatted internal file output

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|[8 Regression] Very slow|Very slow formatted
   |formatted internal file |internal file output
   |output  |

--- Comment #28 from Thomas Koenig  ---
No longer a regression.

[Bug c++/83132] Error while redeclaring an enum with extra qualification

[jenda.tusil at gmail dot com]

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

--- Comment #2 from Jan Tušil  ---
The 'struct' version can be simplified to:

struct E;
struct ::E {};

Which gives the following error:
2:12: error: global qualification of class name is invalid before '{' token

[Bug target/81291] [6/7 Regression] wrong code with -O2 -fno-rerun-cse-after-loop -fno-tree-ter -fno-tree-vrp -funroll-loops due to improper carry

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Known to work||8.0
Summary|[6/7/8 Regression] wrong|[6/7 Regression] wrong code
   |code with -O2   |with -O2
   |-fno-rerun-cse-after-loop   |-fno-rerun-cse-after-loop
   |-fno-tree-ter -fno-tree-vrp |-fno-tree-ter -fno-tree-vrp
   |-funroll-loops due to   |-funroll-loops due to
   |improper carry  |improper carry
  Known to fail|8.0 |

--- Comment #5 from Jakub Jelinek  ---
Indeed, fixed by r254874 on the trunk.

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[siddhesh at gotplt dot org]

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

--- Comment #6 from Siddhesh Poyarekar  ---
(In reply to Siddhesh Poyarekar from comment #5)
> This fixes the problem for me.  freq_max < 1, i.e. freq_max of one of the
> bbs in the function means that it ends up having a profile count larger than

Sorry, that bit should read as "freq_max < 1, i.e. highest frequency among bbs
in the function being higher than real_bb_freq_max means that the bb ends up
with a profile count larger than real_bb_freq_max and then can go all the way
up to and beyond profile_count::max_count".

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[siddhesh at gotplt dot org]

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

--- Comment #5 from Siddhesh Poyarekar  ---
This fixes the problem for me.  freq_max < 1, i.e. freq_max of one of the bbs
in the function means that it ends up having a profile count larger than 2^30
since the freq_max gets reset to 16.  Dropping this reset makes sure that the
profile counts are always correctly normalized to real_bb_freq_max:

diff --git a/gcc/predict.c b/gcc/predict.c
index 0f34956..ff9b5a9 100644
--- a/gcc/predict.c
+++ b/gcc/predict.c
@@ -3613,8 +3613,6 @@ estimate_bb_frequencies (bool force)
  freq_max = BLOCK_INFO (bb)->frequency;

   freq_max = real_bb_freq_max / freq_max;
-  if (freq_max < 16)
-   freq_max = 16;
   profile_count ipa_count = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count.ipa ();
   cfun->cfg->count_max = profile_count::uninitialized ();
   FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun), NULL, next_bb)

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 42697
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42697=edit
pr82050.c

Here it is.

[Bug target/19520] protected function pointer and copy relocation don't work right

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||yyc1992 at gmail dot com

--- Comment #33 from H.J. Lu  ---
*** Bug 83110 has been marked as a duplicate of this bug. ***

[Bug target/83110] Relocation error when taking address of protected function in shared library.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from H.J. Lu  ---
Dup.

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

[Bug c++/81722] [7/8 Regression] memory hog building c++ on i686-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Jakub Jelinek  ---
Let's just close this.

[Bug testsuite/81807] [8 Regression] many *.cc asan tests fail

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Is that still the case or was it some short episode in August?  I certainly
don't see such FAILs in my x86_64 or i686-linux regtests, nor can see them on
current powerpc64{,le}-linux gcc-testresults.

[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments

[tkoenig at gcc dot gnu.org]

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

--- Comment #12 from Thomas Koenig  ---
Author: tkoenig
Date: Thu Nov 23 17:52:05 2017
New Revision: 255109

URL: https://gcc.gnu.org/viewcvs?rev=255109=gcc=rev
Log:
2017-11-23  Thomas Koenig  

PR fortran/36313
* m4/maxloc2s.m4: Replace int for character length by
gfc_charlen_type.
* m4/minloc2s.m4: Likewise.
* generated./maxloc2_16_s1.c: Regenerated.
* generated./maxloc2_16_s4.c: Regenerated.
* generated./maxloc2_4_s1.c: Regenerated.
* generated./maxloc2_4_s4.c: Regenerated.
* generated./maxloc2_8_s1.c: Regenerated.
* generated./maxloc2_8_s4.c: Regenerated.
* generated./minloc2_16_s1.c: Regenerated.
* generated./minloc2_16_s4.c: Regenerated.
* generated./minloc2_4_s1.c: Regenerated.
* generated./minloc2_4_s4.c: Regenerated.
* generated./minloc2_8_s1.c: Regenerated.
* generated./minloc2_8_s4.c: Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/maxloc2_16_s1.c
trunk/libgfortran/generated/maxloc2_16_s4.c
trunk/libgfortran/generated/maxloc2_4_s1.c
trunk/libgfortran/generated/maxloc2_4_s4.c
trunk/libgfortran/generated/maxloc2_8_s1.c
trunk/libgfortran/generated/maxloc2_8_s4.c
trunk/libgfortran/generated/minloc2_16_s1.c
trunk/libgfortran/generated/minloc2_16_s4.c
trunk/libgfortran/generated/minloc2_4_s1.c
trunk/libgfortran/generated/minloc2_4_s4.c
trunk/libgfortran/generated/minloc2_8_s1.c
trunk/libgfortran/generated/minloc2_8_s4.c
trunk/libgfortran/m4/maxloc2s.m4
trunk/libgfortran/m4/minloc2s.m4

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle  ---
This should be fixed now fairly well.  At this point there are not a lot of
major issues in our own libgfortran library. I will leave this bug report open
for a while if any issues arise.

Here is my latest profile. On my machine I am actuall getting slightly better
performance on trunk (8) vs. gfortran 6

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self  
 time   seconds   seconds name
 15.11  4.30 4.30 printf_positional
 14.65  8.47 4.17 __printf_fp_l
  7.13 10.50 2.03 __parse_one_specmb
  6.08 12.23 1.73 build_float_string
  4.16 13.42 1.19 formatted_transfer_scalar_write
  2.39 14.10 0.68 next_format0
  2.28 14.75 0.65 _IO_no_init
  2.23 15.38 0.64 __mpn_mul_1
  2.21 16.01 0.63 strtol_l_internal
  2.18 16.63 0.62 vfprintf
  1.86 17.16 0.53 __strchrnul_sse2
  1.79 17.67 0.51 _gfortrani_next_format
  1.77 18.18 0.51 _IO_str_init_static_internal
  1.76 18.68 0.50 __mpn_extract_double
  1.72 19.17 0.49 vsnprintf
  1.72 19.66 0.49 _IO_default_xsputn
  1.69 20.14 0.48 _int_malloc
  1.62 20.60 0.46 __memmove_sse2_unaligned_erms
  1.28 20.96 0.37 get_float_string
  1.12 21.28 0.32 _IO_padn
  1.02 21.57 0.29 __memset_sse2_unaligned
  1.02 21.86 0.29 __wmemset_sse2_unaligned
  0.91 22.12 0.26 flt128_ais

[Bug fortran/83064] DO CONCURRENT inconsistent results

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On November 23, 2017 6:30:34 PM GMT+01:00, "dominiq at lps dot ens.fr"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
>
>--- Comment #5 from Dominique d'Humieres 
>---
>> As I said in the other bug we're seeing
>>
>>real(real64), dimension(nsplit) :: tmp
>>
>> as "shared" amongst the outer loop iterations.
>>
>> ...
>>
>> Not sure if you need to mark compute somehow to avoid this
>> and the testcase is invalid fortran or if the frontend is at fault.
>
>IMO the testcase is valid fortran and, with my naive view of arrays
>returned by
>a function, the returned array should be private to the function.
>
>If I do the following changes
>
>...
>real(real64), dimension(nsplit) :: pi, pik
>...
>do concurrent (i = 1:nsplit)
>pik = compute( low(i), high(i) )
>pi(i) = sum(pik)
>end do
>...
>
>the code works as expected, at least for my limited testing.

I looked at the IL from the Fortran FE and it clearly uses a single memory area
for tmp for each outer loop iteration. That is, the memory is allocated by the
caller. 

>
>Do you understand why the code is not parallelized with
>-ftree-parallelize-loops=4?

Because the outer loop has four iterations and we statically require at least
two per thread for outer loops. 

Richard.

[Bug target/83110] Relocation error when taking address of protected function in shared library.

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
What might be invalid about the source?

[Bug target/82459] AVX512F instruction costs: vmovdqu8 stores may be an extra uop, and vpmovwb is 2 uops on Skylake and not always worth using

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 CC||andrew.n.senkevich at gmail 
dot co
   ||m

--- Comment #2 from Andrew Senkevich  ---
Currently -mprefer-avx256 is default for SKX and vzeroupper addition was fixed,
code generated is:

.L3:
vpsrlw  $8, (%rsi,%rax,2), %ymm0
vpsrlw  $8, 32(%rsi,%rax,2), %ymm1
vpand   %ymm0, %ymm2, %ymm0
vpand   %ymm1, %ymm2, %ymm1
vpackuswb   %ymm1, %ymm0, %ymm0
vpermq  $216, %ymm0, %ymm0
vmovdqu8%ymm0, (%rdi,%rax)
addq$32, %rax
cmpq%rax, %rdx
jne .L3

vmovdqu8 remains but I cannot confirm it is slower.

[Bug target/83114] [7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 CC||amker.cheng at gmail dot com,
   ||jgreenhalgh at gcc dot gnu.org,
   ||sudi.das at arm dot com
  Known to work|6.4.1   |4.8.1
  Known to fail||4.9.1, 5.1.1

--- Comment #3 from James Greenhalgh  ---
Looks like we're missing handling for LTGT in our vcmp/vcond handlers.

  /* This is an ordered NE, ie !UNEQ, ie false for NaN.  */
  DEF_RTL_EXPR(LTGT, "ltgt", "ee", RTX_COMM_COMPARE)

I bet this would fail even further back with a modified testcase (this one is
somewhat undefined behaviour).

  void *a;
  void b(double *in) {
char c;
long d = -1024;
char *e = a;
for (; d; d++) {
  double f = in[d], g = in[d+1];
  c = g < f || g > f;
  e[d] = c;
}
  }

Is broken back to at least GCC 4.9.

Well... I implemented the original version of this code in GCC 4.9 and today is
the first time I heard of LTGT, so not surprising I missed it!

[Bug target/83114] [5/6/7/8 Regression] ICE in gen_vec_cmpv2dfv2di, at config/aarch64/aarch64-simd.md:2495

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

   Target Milestone|7.3 |6.6
Summary|[7/8 Regression] ICE in |[5/6/7/8 Regression] ICE in
   |gen_vec_cmpv2dfv2di, at |gen_vec_cmpv2dfv2di, at
   |config/aarch64/aarch64-simd |config/aarch64/aarch64-simd
   |.md:2495|.md:2495

[Bug rtl-optimization/83123] Int compare - different asm code for different return type

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
In the first case (with the extend to SImode) the extend is combined
with the AND, to an AND in SImode.  After that, the 3-insn combination
of the two shifts with the AND is something combine knows how to split.

In the second case this of course does not happen.

[Bug fortran/83064] DO CONCURRENT inconsistent results

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> As I said in the other bug we're seeing
>
>real(real64), dimension(nsplit) :: tmp
>
> as "shared" amongst the outer loop iterations.
>
> ...
>
> Not sure if you need to mark compute somehow to avoid this
> and the testcase is invalid fortran or if the frontend is at fault.

IMO the testcase is valid fortran and, with my naive view of arrays returned by
a function, the returned array should be private to the function.

If I do the following changes

...
real(real64), dimension(nsplit) :: pi, pik
...
do concurrent (i = 1:nsplit)
pik = compute( low(i), high(i) )
pi(i) = sum(pik)
end do
...

the code works as expected, at least for my limited testing.

Do you understand why the code is not parallelized with
-ftree-parallelize-loops=4?

[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Nov 23 17:19:18 2017
New Revision: 255108

URL: https://gcc.gnu.org/viewcvs?rev=255108=gcc=rev
Log:
2017-11-23  Jerry DeLisle  

Backport from trunk
PR libgfortran/78549
* io/io.h (newunit_free): Add declaration. Clean some whitespace.
* io/transfer.c (st_read_done, st_write_done): Call newunit_free.
* io/unit.c (newunit_free): Change type from static void to void.

Modified:
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/io.h
branches/gcc-7-branch/libgfortran/io/transfer.c
branches/gcc-7-branch/libgfortran/io/unit.c

[Bug bootstrap/81869] [8 Regression] --enable-checking=yes,rtl failed to bootstrap on 32-bit hosts

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Does this still happen?  I'm bootstrapping/regtesting with
--enable-languages=default,obj-c++,lto,go,brig --enable-checking=yes,rtl,extra
on i686-linux often several times a day and haven't seen this.

[Bug rtl-optimization/83133] New: Superflous x86 test instructions in generated assembly.

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 83133
   Summary: Superflous x86 test instructions in generated
assembly.
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

Consider the following code:

int negative(int);
int positive(int);
int nonnegative(int);
int nonpositive(int);

int f(int a, int b) {
int diff = a - b;
if(diff < 0)
return negative(diff);
else
return nonnegative(diff);
}

int g(int a, int b) {
int diff = a - b;
if(diff > 0)
return positive(diff);
else
return nonpositive(diff);
}

And the assembly generated with `-O3 -march=broadwell`:

f(int, int):
  subl %esi, %edi
  js .L4
  jmp nonnegative(int)
.L4:
  jmp negative(int)

g(int, int):
  subl %esi, %edi
  testl %edi, %edi < unnecessary instruction.
  jle .L6
  jmp positive(int)
.L6:
  jmp nonpositive(int)

g function assembly contains a superflous test instruction. It should not
generate that instruction, since sub instruction already sets all the required
flags. I first discovered this issue in gcc-4.9.2 and it is still there in
gcc-7.2.0.

Double-checked it with clang-5.0.0 and it seem to generate optimal assembly:

f(int, int): # @f(int, int)
  subl %esi, %edi
  js .LBB0_1
  jmp nonnegative(int) # TAILCALL
.LBB0_1:
  jmp negative(int) # TAILCALL

g(int, int): # @g(int, int)
  subl %esi, %edi
  jle .LBB1_2
  jmp positive(int) # TAILCALL
.LBB1_2:
  jmp nonpositive(int) # TAILCALL

[Bug c++/83132] Error while redeclaring an enum with extra qualification

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Similar error for classes:

namespace N { struct E; }
struct ::N::E {};

x.C:2:15: error: global qualification of class name is invalid before ‘{’ token
 struct ::N::E {};
   ^

[Bug c++/83132] New: Error while redeclaring an enum with extra qualification

[jenda.tusil at gmail dot com]

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

Bug ID: 83132
   Summary: Error while redeclaring an enum with extra
qualification
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jenda.tusil at gmail dot com
  Target Milestone: ---

g++ -std=c++14 does not compile this:

enum E : int;
enum ::E : int{};

It says:
2:10: error: expected unqualified-id before ‘:’ token

Clang compiles it without errors, but gives a little wierd warning:
warning: extra qualification on member 'E' [-Wextra-qualification]

The bug was found in the context of this SO thread:
https://stackoverflow.com/q/47383199/6209703

It manifestes in most (all?) gcc versions on https://gcc.godbolt.org/

[Bug target/81317] builtin_vec_ld fails for powerpc with altivec

[randy.macleod at windriver dot com]

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

--- Comment #28 from Randy MacLeod  ---
Alex, thanks for confirming, I was worried that it was one of the _perfectly_
sensible local patches we have in YP.  ;-)

FYI, a local toolchain expert has started working on this defect so stay tuned
/ keeep refreshing.

[Bug tree-optimization/83129] calloc zero initialization is not taken into account by gcc

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-11-23
Version|unknown |8.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

This one is interesting because alias-wise we consider allocation functions
not clobbering anything -- dependences for the pointer will prevent any
invalid transform.

That of course means we'll never visit it via vn_reference_lookup_3.

One trick we don't pull is that if there's a must-alloc in the path we can
stop walking.  Another trick we don't pull is that if we don't find any
may-def the memory we load is uninitialized (or in this case zero-initialized
as we don't find the calloc as may-def either - an issue for calloc and
-Wuninit maybe).  So we could in theory optimistically value-number each
of those to zero (conservatively to treat calloc "right").

Need to think about that -Wuninitialized case.  Ah, we only ever warn
using the oracle walking for decls, so never for allocated memory.

So in theory the following but it doesn't trigger because of the above.

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 255093)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -2412,6 +2417,21 @@ vn_reference_lookup_3 (ao_ref *ref, tree
   return NULL;
 }

+  /* 7) calloc, optimize ref to all zeros.  */
+  else if (is_gimple_reg_type (vr->type)
+  && gimple_call_builtin_p (def_stmt, BUILT_IN_CALLOC)
+  && TREE_CODE (base) == MEM_REF
+  && TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
+  && SSA_VAL (TREE_OPERAND (base, 0)) != VN_TOP
+  && SSA_VAL (TREE_OPERAND (base, 0)) == gimple_call_lhs (def_stmt))
+{
+  /* We do not bother to check whether the ref is in range because
+ we'll usually not be able to anyway.  */
+  tree val = build_zero_cst (vr->type);
+  return vn_reference_lookup_or_insert_for_pieces
+   (vuse, vr->set, vr->type, vr->operands, val);
+}
+
   /* Bail out and stop walking.  */
   return (void *)-1;
 }

[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676

[siddhesh at gotplt dot org]

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

--- Comment #4 from Siddhesh Poyarekar  ---
Reduced C test case:

#define MAX 98

void foo (unsigned long *res, unsigned long in)
{
  for (unsigned long a = 0; a < MAX; a++)
for (unsigned long b = 0; b < MAX; b++)
  for (unsigned long c = 0; c < MAX; c++)
for (unsigned long d = 0; d < MAX; d++)
  for (unsigned long e = 0; e < MAX; e++)
for (unsigned long f = 0; f < MAX; f++)
  for (unsigned long g = 0; g < MAX; g++)
*res += a * in;
}



foo.c: In function 'foo':
foo.c:13:1: internal compiler error: in from_gcov_type, at profile-count.h:676
 }
 ^
0xaaf57f profile_count::from_gcov_type(long)
/home/siddhesh/src/gcc/gcc/profile-count.h:676
0xaaf57f estimate_bb_frequencies(bool)
/home/siddhesh/src/gcc/gcc/predict.c:3623
0xab40af tree_estimate_probability(bool)
/home/siddhesh/src/gcc/gcc/predict.c:2849
0xab45c3 execute
/home/siddhesh/src/gcc/gcc/predict.c:3760
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/82050] [8 Regression] ICE on invalid code on x86_64-linux-gnu in column_range, at diagnostic-show-locus.c:1403

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
I attempted to copy from comment #0, but couldn't reproduce the ICE
(possibly a spaces vs tabs thing?)

Jakub: please can you attach the reproducer file, and I'll take this.  Thanks.

[Bug rtl-optimization/83098] [8 regression] ICE in assert_rtx_eq_at, at selftest-rtl.c:57

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #5 from Rainer Orth  ---
Of course.  Sorry I forgot.

[Bug rtl-optimization/83098] [8 regression] ICE in assert_rtx_eq_at, at selftest-rtl.c:57

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
If you are into make check, then self test already passed, right?
Thus, can this be closed as fixed?

[Bug c++/83116] [6/7/8 Regression] Statement with no effect causes wrong code of static object constexpr method

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
No idea where though.

[Bug testsuite/83131] c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug testsuite/83131] New: c-c++/common/attr-nonstring-3 failure for strcmp tests on PowerPC

[dje at gcc dot gnu.org]

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

Bug ID: 83131
   Summary: c-c++/common/attr-nonstring-3 failure for strcmp tests
on PowerPC
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

New testcase failure on PowerPC (Linux and AIX)

FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
149)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
150)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
153)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
154)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
156)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
157)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
158)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
168)
FAIL: c-c++-common/attr-nonstring-3.c  -std=gnu++98  (test for warnings, line
169)

gnu++11, gnu++14, c

149-169 correspond to the line-specific strcmp and strncmp tests in the
testcase.

[Bug tree-optimization/83128] Unable to optimize {m,c}alloc when strings builtin are used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

Index: gcc/tree-ssa-sccvn.c
===
--- gcc/tree-ssa-sccvn.c(revision 255093)
+++ gcc/tree-ssa-sccvn.c(working copy)
@@ -1388,10 +1388,14 @@ fully_constant_vn_reference_p (vn_refere
   else if (base->opcode == MEM_REF
   && base[1].opcode == ADDR_EXPR
   && (TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == VAR_DECL
-  || TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == CONST_DECL))
+  || TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == CONST_DECL
+  || TREE_CODE (TREE_OPERAND (base[1].op0, 0)) == STRING_CST))
{
  decl = TREE_OPERAND (base[1].op0, 0);
- ctor = ctor_for_folding (decl);
+ if (TREE_CODE (decl) == STRING_CST)
+   ctor = decl;
+ else
+   ctor = ctor_for_folding (decl);
}
   if (ctor == NULL_TREE)
return build_zero_cst (ref->type);
@@ -2331,7 +2335,8 @@ vn_reference_lookup_3 (ao_ref *ref, tree
  rhs = TREE_OPERAND (tem, 0);
  rhs_offset += tree_to_uhwi (TREE_OPERAND (tem, 1));
}
- else if (DECL_P (tem))
+ else if (DECL_P (tem)
+  || TREE_CODE (tem) == STRING_CST)
rhs = build_fold_addr_expr (tem);
  else
return (void *)-1;

[Bug libstdc++/83127] Missing overload for operator << of std::stringstream for old ABI

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #3 from ghjghj530-bubu at yahoo dot de ---
Changed my testcode to int main(). The error stil occurs.
The system is Windows 7, 64 bit, mingw.

Is use the GCC in a company-specific enviroment with some customized
linkersripts.

We first compile the source file with:
i686-elf-gcc.exe -c C:\temp\2\Main.cpp -o c:\temp\2\Main.cpp.o
-D_GLIBCXX_USE_CXX11_ABI=0

and then call the linker:
i686-elf-gcc.exe C:\Temp\2\Main.cpp.o -o C:\Temp\2\a.out
-Wl,-lstdc++,-lsupc++,-lm -lc 
(i have removed a -specs paramter and some target plattform specific
parameters).

I'm sorry for the incomplete command line.

I still hope the *.a-File analysis from my original post can help you.

[Bug c++/83116] [6/7/8 Regression] Statement with no effect causes wrong code of static object constexpr method

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r230365.
Guess we need to remove the static var from constexpr caches at the end of
construction if the var isn't constexpr.

Testcase modified for the testsuite:

// PR c++/83116
// { dg-do run { target c++14 } }

struct S {
  constexpr S () : s(0) { foo (); }
  constexpr int foo () { return s; }
  int s;
};

int
main ()
{
  static S var;
  var.s = 5;
  if (var.s != 5 || var.foo () != 5)
__builtin_abort ();
}

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[jakub at gcc dot gnu.org]

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

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 42696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42696=edit
gcc8-pr81888.patch

Untested fix.

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #8 from Oleg Endo  ---
Fixed on GCC 7 and GCC 8.

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[olegendo at gcc dot gnu.org]

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

--- Comment #7 from Oleg Endo  ---
Author: olegendo
Date: Thu Nov 23 14:08:12 2017
New Revision: 255097

URL: https://gcc.gnu.org/viewcvs?rev=255097=gcc=rev
Log:
gcc/
Backport from mainline
2017-11-23  Oleg Endo  

PR target/83111
* config/sh/sh.md (udivsi3, divsi3, sibcall_value_pcrel,
sibcall_value_pcrel_fdpic): Use local variable instead of
operands[3].
(calli_tbr_rel): Add missing operand 2.
(call_valuei_tbr_rel): Add missing operand 3.


Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/sh/sh.md

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
Author: olegendo
Date: Thu Nov 23 14:06:15 2017
New Revision: 255096

URL: https://gcc.gnu.org/viewcvs?rev=255096=gcc=rev
Log:
gcc/
PR target/83111
* config/sh/sh.md (udivsi3, divsi3, sibcall_value_pcrel,
sibcall_value_pcrel_fdpic): Use local variable instead of
operands[3].
(calli_tbr_rel): Add missing operand 2.
(call_valuei_tbr_rel): Add missing operand 3.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.md

[Bug c++/83130] Compilation error related to 'using', template instantiations and default constructors

[nadult at fastmail dot fm]

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

--- Comment #1 from Krzysztof Jakubowski  ---
someFunc() at the bottom is unnecessary.

[Bug c++/83130] New: Compilation error related to 'using', template instantiations and default constructors

[nadult at fastmail dot fm]

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

Bug ID: 83130
   Summary: Compilation error related to 'using', template
instantiations and default constructors
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nadult at fastmail dot fm
  Target Milestone: ---

The following code fails to compile on new GCC (7.1, 7.2, 8.0). It compiles
without any problems on Clang. Compiled with: -std=c++1z

#include 

template  struct ValueBase {
ValueBase() {}
ValueBase(const ValueBase ) {}
ValueBase(ValueBase &) {}
void operator=(ValueBase &) {}
void operator=(const ValueBase ) {}
};

template  struct Value : public ValueBase {
Value(void *) {}
using ValueBase::ValueBase;
using ValueBase::operator=;
};

struct MyObj {
MyObj();
MyObj(const MyObj &);

struct Impl {
// Uncomment these lines to make the bug go away:
//Impl() = default;
//Impl(const Impl &) = default;

Value value;
};

std::pair pair;
};

MyObj::MyObj(const MyObj &) = default;

void someFunc() {
std::pair impl;
// Comment this line to make the bug go away
impl.first.value = nullptr;
}

[Bug tree-optimization/83129] New: calloc zero initialization is not taken into account by gcc

[denis.campredon at gmail dot com]

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

Bug ID: 83129
   Summary: calloc zero initialization is not taken into account
by gcc
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

It seems that GCC does not know that calloc initialize the memory to zero.

The the following functions could be optimized to the same assemble, but only
f3 is optimized to:
xor eax, eax
ret

--
int f1() {
  char * i = __builtin_calloc(1, 1);
  return *i;
}

int f2() {
  struct s{int i;}* a = __builtin_calloc(1, sizeof(*a));

  return a->i;
}

int f3() {
char * i = (char*)__builtin_calloc(1, 1);
i[0] = 0;
return *i;
}
--

[Bug bootstrap/83015] [8 regression] bootstrap comparison failure on ia64

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #15 from Jan Hubicka  ---
I believe it was done before the inliner change, but i am now trying to
reproduce it on yttrium. It is bad idea to use periodic benchmarking machine
for random bootstraps anyway.

Thanks for the info and pointer to working itanium box!

[Bug tree-optimization/83128] New: Unable to optimize {m,c}alloc when strings builtin are used

[denis.campredon at gmail dot com]

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

Bug ID: 83128
   Summary: Unable to optimize {m,c}alloc when strings builtin are
used
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Currently gcc with -03 is able to optimize 
--
char f() {
  char * i = (char*)__builtin_malloc(100);

 i[0] = 'a';
 return i[0];
}
--
to
--
mov al, 97
ret

But is unable to do the same when string builtins are used with either malloc
or calloc.

-
char f() {
  char * i = (char*)__builtin_malloc(100);

  __builtin_memcpy(i, "a", 1);
  return i[0];
}
-

[Bug fortran/83064] DO CONCURRENT inconsistent results

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code

--- Comment #4 from Richard Biener  ---
As I said in the other bug we're seeing

   real(real64), dimension(nsplit) :: tmp

as "shared" amongst the outer loop iterations.

It seems it is constructed that way by the frontend though:

MAIN__ ()
{
...
  real(kind=8) A.11[4];
...
  atmp.10.dtype = 537;
  atmp.10.dim[0].stride = 1;
  atmp.10.dim[0].lbound = 0;
  atmp.10.dim[0].ubound = 3;
  atmp.10.data = 
  atmp.10.offset = 0;
  compute (, _73, _74); [static-chain: ]

and

compute (struct array1_real(kind=8) & __result, integer(kind=8) & restrict low,
integer(kind=8) & restrict high)
{
  real(kind=8)[0:D.3540] * restrict __result.0;

so each invocation gets the same local array in MAIN__.

Not sure if you need to mark compute somehow to avoid this and the testcase
is invalid fortran or if the frontend is at fault.

[Bug libstdc++/83127] Missing overload for operator << of std::stringstream for old ABI

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It links fine on GNU/Linux using a standard start function, int main().

[Bug libstdc++/83127] Missing overload for operator << of std::stringstream for old ABI

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
What is void Main(void) ? Is this using mingw or something?

Please provide the missing information as requested by https://gcc.gnu.org/bugs

[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug fortran/82973] [8 regression] ICE in output_constant_pool_2, at varasm.c:3896 on aarch64

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
Summary|ICE in  |[8 regression] ICE in
   |output_constant_pool_2, at  |output_constant_pool_2, at
   |varasm.c:3896 on aarch64|varasm.c:3896 on aarch64

--- Comment #3 from Ramana Radhakrishnan  ---
Confirmed.

I can't provoke this on GCC 7 though. Are you sure this is coming out GCC 7
rather than trunk ?

[Bug target/82974] [8 regression] ICE in extract_insn, at recog.c:2305 on aarch64

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||ramana at gcc dot gnu.org
Version|7.0 |c++-concepts
Summary|ICE in extract_insn, at |[8 regression] ICE in
   |recog.c:2305 on aarch64 |extract_insn, at
   ||recog.c:2305 on aarch64
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
I can't provoke the latest tip of GCC7 to ICE but GCC 8 does ICE.

[Bug target/82975] ICE in baseness at rtlanal.c:6220

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
$CC -S -O2 -mtune=cortex-a57 -fno-sched-pressure -mfpu=neon -mfloat-abi=softfp
-O3 /work/wa3/src/gcc/gcc/testsuite/gcc.target/i386/pr78904-6.c 

Confirmed.

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||ramana at gcc dot gnu.org
Summary|Inexplicable use of NEON|[7/8 regression ]
   |for 64-bit math |Inexplicable use of NEON
   ||for 64-bit math
 Ever confirmed|0   |1
  Known to fail||7.2.1, 8.0

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug target/82989] [7/8 regression ] Inexplicable use of NEON for 64-bit math

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
Works as expected in GCC 6.

[Bug c++/81888] [7/8 Regression] Structured bindings stopped working

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with my r249947 aka PR81258 fix.

[Bug rtl-optimization/83124] wrong code on arm-linux-gnueabi-gcc with -O3 optimization

[yangyibiao at nju dot edu.cn]

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

--- Comment #2 from Yibiao Yang  ---
Thanks and Very sorry for this wrong bug report. 
(In reply to ktkachov from comment #1)
> The code has undefined behaviour.
> If you remove the -w, two of the warnings are:
> bad.c:5:10: warning: initialization of ‘int *’ from incompatible pointer
> type ‘union  *’ [-Wincompatible-pointer-types]
>  int *c = 
>   ^
> bad.c:7:11: warning: initialization of ‘long int *’ from incompatible
> pointer type ‘union  *’ [-Wincompatible-pointer-types]
>  long *d = 
>^
> 
> These break strict-aliasing rule.
> So if you use -fno-strict-aliasing you'll get  as the output at all
> optimisation levels

[Bug middle-end/82253] [6/7 Regression] ICE in convert_move, at expr.c:604

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7/8 Regression] ICE in   |[6/7 Regression] ICE in
   |convert_move, at expr.c:604 |convert_move, at expr.c:604

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug middle-end/82253] [6/7/8 Regression] ICE in convert_move, at expr.c:604

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Nov 23 11:26:32 2017
New Revision: 255095

URL: https://gcc.gnu.org/viewcvs?rev=255095=gcc=rev
Log:
PR middle-end/82253
* expr.c (expand_assignment): For CONCAT to_rtx, complex type from and
bitpos/bitsize covering the whole destination, use store_expr only if
the complex mode is the same.  Otherwise, use expand_normal and if
it returns CONCAT, subreg each part separately instead of trying to
subreg the whole result.

* gfortran.dg/pr82253.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr82253.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/83127] New: Missing overload for operator << of std::stringstream for old ABI

[ghjghj530-bubu at yahoo dot de]

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

Bug ID: 83127
   Summary: Missing overload for operator << of std::stringstream
for old ABI
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghjghj530-bubu at yahoo dot de
  Target Milestone: ---

Compiling the following testcode

#include 
#include 

void Main(void)
{
std::string testStr("Hello");
std::string testStr2("World");
std::stringstream ss;

ss << testStr;

testStr2 = ss.str();
}

with flag: -D_GLIBCXX_USE_CXX11_ABI=0 leads to linker error:
undefined reference to `std::basic_ostream&
std::operator<< (std::basic_ostream&, std::basic_string const&)'

Setting -D_GLIBCXX_USE_CXX11_ABI=1 fixes the bug.

We narrowed the problem down to a missing overload in libstdc++.a using:
nm.exe -gC "libstdc++.a" > libstdc++.a.out

There is only one overload for operator << and string:
"std::__cxx11::basic_string"
 W std::basic_ostream& std::operator<<
(std::basic_ostream&, std::__cxx11::basic_string const&)

But two overloads for operator >>:
"std::__cxx11::basic_string" and "std::basic_string"
 W std::basic_istream&
std::operator>>(std::basic_istream&,
std::__cxx11::basic_string&)
 W std::basic_istream&
std::operator>>(std::basic_istream&,
std::basic_string&)

[Bug target/82975] ICE in baseness at rtlanal.c:6220

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
Can you put the output of arm-none-linux-gnueabi-gcc -v ? What's the
cross-compiler been configured with ?

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 42695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42695=edit
gcc8-pr83014.patch

Untested fix.  I believe this is because on mingw host HOST_LONG_LONG_FORMAT
is redefined to "I64", but that is a Microsoft-ism that pp_printf of course
doesn't handle.  pp_unsigned_wide_integer or pp_scalar it uses should handle
this fine by using the host sprintf into a temporary buffer and then just
appending the digit buffer.
As this needs mingw host, I can't really test whether it fixes this though, can
only bootstrap/regtest it on linux.

[Bug c/83122] -Wconversion and shifting bitwise

[lh_mouse at 126 dot com]

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

--- Comment #2 from Liu Hao  ---
Yes it is hard to tell whether there is indeed loss of precision.

At the moment, the (only?) redictable way to silence the warning is to use a
bitwise and operation. That is, `ptr->b = (val >> 3) & (UINT64_MAX >> 3)`.

[Bug tree-optimization/83126] New: [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713

[asolokha at gmx dot com]

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

Bug ID: 83126
   Summary: [8 Regression] ICE in
transform_to_exit_first_loop_alt, at
tree-parloops.c:1713
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171119 snapshot (r254939) ICEs when compiling the following
snippet w/ -O1 -ftree-parallelize-loops=2 -floop-parallelize-all:

void
ew (unsigned short int c9)
{
  int e1;

  for (;;)
{
  unsigned int *by = 
  int *fd;

  *fd = c9;
  fd = *fd;
  if (*fd != 0)
for (*by = 0; *by < 2; ++*by)
  c9 *= e1;
}
}

% gcc-8.0.0-alpha20171119 -O1 -ftree-parallelize-loops=2 -floop-parallelize-all
-w -c dbuks5p2.c
during GIMPLE pass: parloops
dbuks5p2.c: In function 'ew':
dbuks5p2.c:2:1: internal compiler error: in transform_to_exit_first_loop_alt,
at tree-parloops.c:1713
 ew (unsigned short int c9)
 ^~
0xcf558a transform_to_exit_first_loop_alt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:1711
0xcf5eac try_transform_to_exit_first_loop_alt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:1835
0xcf7d45 gen_parallel_loop
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:2379
0xcf826c parallelize_loops
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:3366
0xcf852f execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171119/work/gcc-8-20171119/gcc/tree-parloops.c:3448

[Bug lto/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Strangely, it started with r255066.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #21 from Ramana Radhakrishnan  ---
Though I don't know what exactly "fixed" this mark it as fixed for GCC 8 as per
reporter.

[Bug ipa/83125] [8 regression] ICE in edge_badness, at ipa-inline.c:1025

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug rtl-optimization/83123] Int compare - different asm code for different return type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 CC||segher at gcc dot gnu.org
  Component|c   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The first case is somehow optimized by combine while the latter is not.
The gimple is almost equal, so is the expanded RTL.

test1 (int a, int b)
{
  _Bool _1;
  _Bool _2;
  _Bool _3;
  int _6;

   [local count: 1073741825]:
  _1 = a_4(D) < 0;
  _2 = b_5(D) < 0;
  _3 = _1 & _2;
  _6 = (int) _3;
  return _6;

test2 (int a, int b)
{
  _Bool _1;
  _Bool _2;
  _Bool _3;

   [local count: 1073741825]:
  _1 = a_4(D) < 0;
  _2 = b_5(D) < 0;
  _3 = _1 & _2;
  return _3;

[Bug c/83122] -Wconversion and shifting bitwise

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The same probably happens with a division.

Note it might be an inherent limitation of the warning given apart from some
simple cases like yours we can't really tell the value range of the stored
value.  This is why it says "may" alter its value.

[Bug lto/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Probably a latent issue.  Always smells like mixed up BLOCKs :/

[Bug libstdc++/83120] [8 Regression] ext/special_functions/hyperg failure on AIX

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #2 from Richard Biener  ---
Also fails for me on x86_64-linux with -m32:

=== libstdc++ Summary for unix/ ===

# of expected passes12775
# of expected failures  70
# of unsupported tests  256

Running target unix//-m32
FAIL: ext/special_functions/hyperg/check_value.cc execution test
FAIL: tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc
exec
ution test

=== libstdc++ Summary for unix//-m32 ===

# of expected passes12781
# of unexpected failures2
# of expected failures  70
# of unsupported tests  252


sounds more like a testsuite issue to me not properly allowing for an epsilon
(excess precision, yadda yadda)

[Bug libfortran/83097] Use __BYTE_ORDER__ instead of runtime test

[jb at gcc dot gnu.org]

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

--- Comment #4 from Janne Blomqvist  ---
Actually, I think it's for big endian we could optimize memcmp_char4. In the
example Thomas posted on the mailing list, one must also check the sign of
memcmp, not just whether it's != 0. Fixed example:

#include 
#include 

char a[4] = { 1, 2, 3, 4};
char b[4] = { 4, 3, 2, 1};

int main()
{
  int i, j;
  memcpy (, a, sizeof(i));
  memcpy (, b, sizeof(j));
  printf("memcmp   : ");
  if (memcmp (,,sizeof(i)) > 0)
printf("larger\n");
  else
printf("smaller or equal\n");

  printf("Direct comparison: ");
  if (i > j)
printf("larger\n");
  else
printf("smaller or equal\n");

  return 0;
}


On a little endian system this prints:

memcmp   : smaller or equal
Direct comparison: larger

Since most targets of interest for GFortran usage are little endian (x86, arm,
ppc64le) I'm not sure it's worth the bother to do the memcmp_char4
optimization.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from PeteVine  ---
The bug doesn't reproduce in a recent GCC 8 build (profiling on a Cortex A5
system).

The generated assembly contains no __aeabi_idiv calls whatsoever. Well done.

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #5 from Tom de Vries  ---
(In reply to Oleg Endo from comment #4)
> Thanks for reporting and tracking this down.
> It seems there more such traps.  Can you please try the following:

I've done an sh-elf build using this patch, and that went ok.

FWIW, I've also done an sh-unknown-linux-gnu build and that gets as far as it
can get without an sh runtime installation.

I don't have a complete sh build and test setup. Somebody needs to build and
test this patch for the sh target.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #19 from PeteVine  ---
Created attachment 42694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42694=edit
Better assembly after profiling

[Bug c++/83121] [8 Regression] ICE: in linemap_ordinary_map_lookup, at libcpp/line-map.c:995

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
Created attachment 42693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42693=edit
reduced testcase

trippels@gcc67 ~ % g++ -g -flto -r -nostdlib -O2 test_environment.ii
node_buffer.ii
node_buffer.ii:98:10: warning: type ‘struct AsyncHooks’ violates the C++ One
Definition Rule [-Wodr]
   struct AsyncHooks {
  ^
test_environment.ii:117:10: note: a different type is defined in another
translation unit
   struct AsyncHooks {
  ^
node_buffer.ii:99:39: note: the first difference of corresponding definitions
is field ‘providers_’
 int providers_[B::PROVIDERS_LENGTH];
   ^
test_environment.ii:118:67: note: a field of same name but different type is
defined in another translation unit
 v8::Eternal providers_[AsyncWrap::PROVIDERS_LENGTH];
   ^

lto1: internal compiler error: in linemap_ordinary_map_lookup, at
libcpp/line-map.c:995
0x139f7a4 linemap_ordinary_map_lookup
../../gcc/libcpp/line-map.c:995
0x139f7a4 linemap_lookup(line_maps*, unsigned int)
../../gcc/libcpp/line-map.c:948
0x13a068b linemap_macro_loc_to_def_point
../../gcc/libcpp/line-map.c:1453
0x13a068b linemap_resolve_location(line_maps*, unsigned int,
location_resolution_kind, line_map_ordinary const**)
../../gcc/libcpp/line-map.c:1585
0x136bb45 diagnostic_report_current_module(diagnostic_context*, unsigned int)
../../gcc/gcc/diagnostic.c:581
0xb0a6b1 diagnostic_report_current_function(diagnostic_context*,
diagnostic_info*)
../../gcc/gcc/tree-diagnostic.c:39
0xb0a6f0 default_tree_diagnostic_starter
../../gcc/gcc/tree-diagnostic.c:48
0x136a48a diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/gcc/diagnostic.c:985
0x136a84e diagnostic_impl
../../gcc/gcc/diagnostic.c:1108
0x136aa98 inform(unsigned int, char const*, ...)
../../gcc/gcc/diagnostic.c:1160
0x895b21 odr_types_equivalent_p
../../gcc/gcc/ipa-devirt.c:1569
0x89664e add_type_duplicate
../../gcc/gcc/ipa-devirt.c:1848
0x89664e get_odr_type(tree_node*, bool)
../../gcc/gcc/ipa-devirt.c:2028
0x89b9e4 odr_subtypes_equivalent_p
../../gcc/gcc/ipa-devirt.c:689
0x895740 odr_types_equivalent_p
../../gcc/gcc/ipa-devirt.c:1556
0x89664e add_type_duplicate
../../gcc/gcc/ipa-devirt.c:1848
0x89664e get_odr_type(tree_node*, bool)
../../gcc/gcc/ipa-devirt.c:2028
0x89bbd9 register_odr_type(tree_node*)
../../gcc/gcc/ipa-devirt.c:2111
0x5efea7 lto_read_decls
../../gcc/gcc/lto/lto.c:1748
0x5f14d4 lto_file_finalize
../../gcc/gcc/lto/lto.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/home/trippels/bin/ld: fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Also happens without -g -O2:
~ % g++ -flto -r -nostdlib test_environment.ii node_buffer.ii

[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds

[ghjghj530-bubu at yahoo dot de]

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

--- Comment #7 from ghjghj530-bubu at yahoo dot de ---
I tried debugging the GCC today (not my strong side).
I ended up to extracte the call to cc1plus.exe and started GDB with cc1plus.exe
as target.
If i just run the process the ICE still occurs with the same information as
before: "internal compiler error: in pp_format, at pretty-print.c:630"

So i set a breakpoint at this location and printed the backtrace and some
variables:

Breakpoint 2, pp_format (pp=pp@entry=0xbd9fba8, text=text@entry=0xbd9faec) at
../../gcc-6.3.0/gcc/pretty-print.c:630
630 in ../../gcc-6.3.0/gcc/pretty-print.c
(gdb) bt
#0  pp_format (pp=pp@entry=0xbd9fba8, text=text@entry=0xbd9faec) at
../../gcc-6.3.0/gcc/pretty-print.c:630
#1  0x00f469ab in pp_printf (pp=pp@entry=0xbd9fba8, msg=msg@entry=0x116423d
 "%I64d")
at ../../gcc-6.3.0/gcc/pretty-print.c:874
#2  0x009219b9 in ubsan_type_descriptor (type=,
type@entry=0xda193c0, pstyle=pstyle@entry=UBSAN_PRINT_ARRAY)
at ../../gcc-6.3.0/gcc/ubsan.c:416
#3  0x0092213a in ubsan_expand_bounds_ifn (gsi=gsi@entry=0xbd9fc9c) at
../../gcc-6.3.0/gcc/ubsan.c:693
#4  0x00927438 in (anonymous namespace)::pass_sanopt::execute (this=, fun=0x14b068) at ../../gcc-6.3.0/gcc/sanopt.c:696
#5  0x0085c61a in execute_one_pass (pass=pass@entry=0x15d4e0) at
../../gcc-6.3.0/gcc/passes.c:2336
#6  0x0085cb78 in execute_pass_list_1 (pass=0x15d4e0, pass@entry=0x15a728) at
../../gcc-6.3.0/gcc/passes.c:2420
#7  0x0085cbd9 in execute_pass_list (fn=0x14b068, pass=0x15a728) at
../../gcc-6.3.0/gcc/passes.c:2431
#8  0x005f928f in cgraph_node::expand (this=0xda28000) at
../../gcc-6.3.0/gcc/cgraphunit.c:1982
#9  0x005f9e02 in output_in_order (no_reorder=no_reorder@entry=false) at
../../gcc-6.3.0/gcc/cgraphunit.c:2220
#10 0x005fa12c in symbol_table::compile (this=this@entry=0x14b000) at
../../gcc-6.3.0/gcc/cgraphunit.c:2468
#11 0x005fc097 in compile (this=0x14b000) at
../../gcc-6.3.0/gcc/cgraphunit.c:2538
#12 symbol_table::finalize_compilation_unit (this=0x14b000) at
../../gcc-6.3.0/gcc/cgraphunit.c:2564
#13 0x009085a5 in compile_file () at ../../gcc-6.3.0/gcc/toplev.c:488
#14 0x0109b23a in do_compile () at ../../gcc-6.3.0/gcc/toplev.c:1986
#15 toplev::main (this=this@entry=0xbd9ff1e, argc=argc@entry=14,
argv=argv@entry=0xc212ff0) at ../../gcc-6.3.0/gcc/toplev.c:2094
#16 0x010b2fb6 in main (argc=14, argv=0xc212ff0) at
../../gcc-6.3.0/gcc/main.c:39
(gdb) p pp->format_decoder
$11 = (printer_fn) 0x0
(gdb) p pp
$12 = (pretty_printer *) 0xbd9fba8
(gdb)


Continuing at this position leads to the ICE

Does this help in any way? How can i contribute more information?

[Bug c/83117] [8 Regression] FAIL: gcc.target/x86_64/abi/ms-sysv/ms-sysv.c (test for excess errors)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |8.0
Summary|FAIL:   |[8 Regression] FAIL:
   |gcc.target/x86_64/abi/ms-sy |gcc.target/x86_64/abi/ms-sy
   |sv/ms-sysv.c (test for  |sv/ms-sysv.c (test for
   |excess errors)  |excess errors)

[Bug rtl-optimization/83124] wrong code on arm-linux-gnueabi-gcc with -O3 optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ktkachov at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from ktkachov at gcc dot gnu.org ---
The code has undefined behaviour.
If you remove the -w, two of the warnings are:
bad.c:5:10: warning: initialization of ‘int *’ from incompatible pointer type
‘union  *’ [-Wincompatible-pointer-types]
 int *c = 
  ^
bad.c:7:11: warning: initialization of ‘long int *’ from incompatible pointer
type ‘union  *’ [-Wincompatible-pointer-types]
 long *d = 
   ^

These break strict-aliasing rule.
So if you use -fno-strict-aliasing you'll get  as the output at all
optimisation levels

[Bug fortran/82814] ICE from submodule character function

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Thu Nov 23 09:52:04 2017
New Revision: 255094

URL: https://gcc.gnu.org/viewcvs?rev=255094=gcc=rev
Log:
2017-11-23  Paul Thomas  

PR fortran/82814
* trans-types.c (gfc_sym_type): If a character function result
is missing the charlen backend_decl, use the one from the name-
space procedure symbol, if present.

2017-11-23  Paul Thomas  

PR fortran/82814
* gfortran.dg/submodule_31.f08: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_31.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog