[Bug bootstrap/22195] Missing Documentation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Andrew Pinski  ---
.

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[egallager at gcc dot gnu.org]

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

--- Comment #29 from Eric Gallager  ---
(In reply to Sven from comment #28)
> (In reply to Eric Gallager from comment #27)
> > gcc 8 adds -Wpacked-not-aligned; does that fix this bug?
> 
> I couldn't find documentation on what this switch is supposed to do. Can you
> point me in the right direction? Is there some commit explaining
> -Wpacked-not-aligned?
> 

I don't remember the exact commit number but HJ Lu added it; I added him on cc
with my previous comment, so maybe he can explain.

[Bug bootstrap/22195] Missing Documentation

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #6 from sandra at gcc dot gnu.org ---
I'm guessing a 12-year-old bug complaining that building a patched ancient
development version of GCC doesn't work is no longer relevant.  Can we close
this?

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[sven.koehler at gmail dot com]

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

--- Comment #28 from Sven  ---
(In reply to Eric Gallager from comment #27)
> gcc 8 adds -Wpacked-not-aligned; does that fix this bug?

I couldn't find documentation on what this switch is supposed to do. Can you
point me in the right direction? Is there some commit explaining
-Wpacked-not-aligned?

FYI: the LLVM developers have added -Waddress-of-packed-member which addresses
the issue discussed here.

[Bug ipa/82801] Internal compiler error with Eigen and __attribute__((always_inline, flatten))

[awllee at gmail dot com]

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

--- Comment #1 from Anthony Lee  ---
creduce reduces this to the below. However, I'm not sure this is the reason for
the original ICE since the error goes away if one writes inline double
B::m_fn1() const { ... }

template
class A {
public:
  A() {}
};

class B {
  double m_fn1() const;
};

__attribute__((always_inline, flatten))
double B::m_fn1() const {
  A<1> v;
  return 0.0;
}

int main() { }

[Bug c/51628] __attribute__((packed)) is unsafe in some cases

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||hjl at gcc dot gnu.org

--- Comment #27 from Eric Gallager  ---
(In reply to Eric Gallager from comment #26)
> (In reply to Keith Thompson from comment #3)
> > I see no "-Walign" option, either in the versions of gcc I'm using or in the
> > online documentation.  Were you thinking of a different option?
> >
> 
> Maybe -Wpacked?

gcc 8 adds -Wpacked-not-aligned; does that fix this bug?

[Bug target/78077] gcc 6.2.0 fails to link temacs from emacs-25.1 using the Xcode 8 linker

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #7 from Eric Gallager  ---
(In reply to Jack Howarth from comment #6)
> (In reply to Iain Sandoe from comment #5)
> > (In reply to Jack Howarth from comment #4)
> > > The Apple developers think this is gcc bug producing malformatted input to
> > > the linker. From macho_relocatable_file.cpp, we are triggering the linker
> > > check...
> > > 
> > > #ifndef NDEBUG
> > > // scan for FDEs claming the same function
> > > for(uint32_t i=1; i < cfiStartsArrayCount; ++i) {
> > > assert( cfiStartsArray[i] != cfiStartsArray[i-1] 
> > > );
> > > }
> > > #endif
> > 
> > If it's a 0-length FDE caused by a 0-length function, then this is a repeat
> > of 57438.  If so please mark it accordingly  (I expect to post a fix for
> > 57438 soon, and I can send you a preview if that helps).
> > 
> > If this is something different, then please can we have a reduced test-case.
> > Thanks
> 
> A reduced test case is unlikely but I can confirm that this appears to be
> due to PR57438 since passing -D__builtin_unreachable=__builtin_trap by
> using...
> 
> ../configure --enable-link-time-optimization --without-ns
> CC=/sw/bin/gcc-fsf-6 CXX=/sw/bin/g++-fsf-6
> CPPFLAGS="-D__builtin_unreachable=__builtin_trap -I/sw/include"
> LDFLAGS="-L/sw/lib"
> 
> produces a successful build at -O2 with LTO under stock gcc 6.2.0 and Xcode
> 8.1 GM's linker.

OK, closing it as a duplicate of bug 57438 then.

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

[Bug target/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

[egallager at gcc dot gnu.org]

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

--- Comment #33 from Eric Gallager  ---
*** Bug 78077 has been marked as a duplicate of this bug. ***

[Bug other/31233] obstack.h typo

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Eric Gallager from comment #3)
> > (In reply to Jim Wilson from comment #2)
> > > Except that we will have to deal with local changes somehow.  They really
> > > should be pushed to the FSF is they aren't already there.
> > 
> > Has it been resynced as part of the "Replace libiberty with gnulib" GSoC
> > project yet?
> 
> Patch is here: https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01302.html
> 
> If you can notice any local changes that Ayush may have missed, please reply
> to the patch.

Adding "patch" keyword then

[Bug c/67314] No warning on assigning an out-of-range integer to an enum

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=61864,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78736,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=7654

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to Martin Sebor from comment #4)
> > The trouble is that while gcc makes it easy to assign without a warning
> > values to enums that are outside the range of the enumerated type, it makes
> > it difficult to handle such values in case and switch statements without
> > eliciting one of the -Wswitch warnings.  In those cases gcc either complains
> > about "case values being not in enumerated type" or it complains about a
> > "switch missing default case" and there doesn't seem to be an easy way to
> > make it happy.
> 
> See also Bug 61864 for more on issues with warnings having to do with the
> relationship between enums and switch statements.

Bug 78736 and bug 7654 are both also related.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78352

--- Comment #19 from Eric Gallager  ---
Bug 78352 is related

[Bug c/28492] -Wmissing-format-attribute points to vsnprintf() or related functions instead of the function that needs the attribute added

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
Summary|-Wmissing-format-attribute  |-Wmissing-format-attribute
   |causes warning for  |points to vsnprintf() or
   |vsnprintf() |related functions instead
   ||of the function that needs
   ||the attribute added

--- Comment #5 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #3)
> OK, I see that the warning is misleading, because it points to the call of
> vsnprintf instead of pointing to vsnprintf_one.
> 
> ttest.c: In function ‘vsnprintf_one’:
> ttest.c:826:5: warning: function might be possible candidate for
> ‘gnu_printf’ format attribute [-Wmissing-format-attribute]
>  vsnprintf(self, 2, "%c", arglist);
>  ^

(In reply to Eric Gallager from comment #4)
> (In reply to Manuel López-Ibáñez from comment #3)
> > OK, I see that the warning is misleading, because it points to the call of
> > vsnprintf instead of pointing to vsnprintf_one.
> > 
> > ttest.c: In function ‘vsnprintf_one’:
> > ttest.c:826:5: warning: function might be possible candidate for
> > ‘gnu_printf’ format attribute [-Wmissing-format-attribute]
> >  vsnprintf(self, 2, "%c", arglist);
> >  ^
> 
> Same thing with the other members of the vprintf family of functions, such
> as vfprintf... I remember getting particularly confused by this one in the
> past and hacking together some really ugly workarounds to deal with it, when
> all I really needed to do was to put the format attribute on the calling
> function, instead of trying to re-declare vfprintf...

Retitling to clarify

[Bug target/71767] Endless stream of warnings when using GCC with -Wa,-q and Clang Integrated Assembler

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #60 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #58)
> (In reply to Francois-Xavier Coudert from comment #57)
> > (In reply to Iain Sandoe from comment #55)
> > > nope, it needs back-porting to 6.x and 5.x - will do that after it's been 
> > > on
> > > trunk a while.
> > 
> > Is backport to 5.x still planned?
> 
> Yes, when time permits.

But 5.x branch is closed now. So I'm closing this bug, too.

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #14 from Eric Gallager  ---
Changing status to ASSIGNED since there's an assignee

[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #1)
> Just to add one note, which is that Apple's gcc-4.2.1 implementation for
> blocks was not actually submitted (and therefore doesn't exist on an FSF
> server);  it's my understanding that means we cannot use / forward port it.
> 
> I'm working on a new version - based on trying to match what clang's current
> code-gen produces.

Changing status to ASSIGNED then since you put yourself as the assignee.

[Bug middle-end/82798] Inconsistent descriptions for warning options in documentation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71283

--- Comment #1 from Eric Gallager  ---
(In reply to Julien ÉLIE from comment #0)
> In GCC 7 documentation:
> 
> 1/ One can read "Some options, such as -Wall and -Wextra, turn on other
> options, such as -Wunused" and later in the description of -Wunused:  "note
> that -Wall implies -Wunused".
> 
> However, "-Wunused" is not listed in the list of warning flags turned on by
> -Wall.
> 4 warning flags are instead listed in the -Wall list: -Wunused-function,
> -Wunused-label, -Wunused-value and -Wunused-variable.
> And 2 warning flags are listed in the -Werror list: -Wunused-parameter,
> -Wunused-but-set-parameter.
> 
> It seems a bit confusing, and I believe there is something to fix.
> Maybe in fact -Wunused is not turned on by -Wall?
> 
> 
> 2/ -Wuninitialized is listed in both -Wall and -Werror list.
> And the description of -Wuninitialized does not mention either of them.
> I believe there is something to fix for that.
> 
> 
> 3/ -Wall should list "-Walloc-size-larger-than=PTRDIFF_MAX" in the warning
> flags turned on (according to GCC 7 changes).  The description should
> mention that at the same time.
> 
> 
> 4/ The description of -Wexpansion-to-defined mentions that it is enabled by
> -Wextra and -Wpedantic.  The list of warning flags turned on by them should
> mention that.
> 
> 
> 5/ -Wall mentions two warnings that are not described in the documentation:
> -Wmultistatement-macros and -Wreorder.  Can they be described please?
> 

-Wreorder at least is listed in the "C++ Dialect Options" section, which is bug
71283

> 
> Thanks beforehand for fixing these issues.
> 
> Julien ÉLIE

[Bug target/40503] DEC_EVAL_METHOD not match operators

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Eric Gallager  ---
(In reply to jos...@codesourcery.com from comment #7)
> As far as I understand the general state of DFP support in GCC: the basic 
> functionality generally works without needing much maintenance, but no-one 
> is actively fixing DFP bugs or updating the DFP support for TS 18661-2 / 
> TS 18661-3, and no-one has ever hooked the DFP support up to the support 
> for the C front-end to manage excess precision, so that support is only 
> active for binary floating point.

So, I guess that's a confirmation.

[Bug c/82200] Unhelpful diagnostic for incorrectly ordered attribute and asm on function declaration in system header

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||drikosev at gmail dot com

--- Comment #4 from Eric Gallager  ---
*** Bug 82787 has been marked as a duplicate of this bug. ***

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||egallager at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #8 from Eric Gallager  ---
dup of bug 82200

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

[Bug c/82802] New: Potential UBSAN error with pointer difference (32-bits mode)

[yann.collet.73 at gmail dot com]

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

Bug ID: 82802
   Summary: Potential UBSAN error with pointer difference (32-bits
mode)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann.collet.73 at gmail dot com
  Target Milestone: ---

As part of our CI test suite,
we compile and run fuzzer tests every day.

The UBSAN test has been failing for some time now.
I suspect it's related to our provider having updated at some point the gcc
version.


The failure happens in this situation :
presuming we have 2 pointers : highPtr > lowPtr,
if I request the distance in 32-bits mode,
both pointers being associated to the same object 
(one is the upper limit, another is a cursor into the object)

`highPtr - lowPtr` generates this UBSAN error : 
runtime error: signed integer overflow: -2147452928 - 1879078921 cannot be
represented in type 'int'

The values of these pointers are :
highPtr : 0x80007800
lowPtr  : 0x70018AAB

As can be seen, there is no overflow : highPtr is > lowPtr, and the distance is
~256 MB, well within the limits of ptrdiff_t in 32-bits.
Nonetheless, UBSAN consider it an error, likely because it crosses the
0x8000 threshold.
I suspect the pointer addresses are converted into `int` type *before* the
substraction, which leads to UBSAN conclusion.


The same code on clang doesn't trigger any error.

[Bug c/67224] UTF-8 support for identifier names in GCC

[spoa at eircom dot net]

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

--- Comment #25 from spoa at eircom dot net  ---
Many thanks Manu.  The to_UCN.sh script works well.  The only trouble was that
my include file also contain unusual characters with diacritic marks and the
script changes these file names to UCN also.  So compiler cant find them.  I
had to re-edit the .cpp file manually after conversion to UCN to change the
include file names back.  But in spite of that, it is useful and enables coding
with much greater choice of words for identifiers.  Much easier for me to read
my code. Thanks again.

[Bug c++/82801] New: Internal compiler error with Eigen and __attribute__((always_inline, flatten))

[awllee at gmail dot com]

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

Bug ID: 82801
   Summary: Internal compiler error with Eigen and
__attribute__((always_inline, flatten))
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: awllee at gmail dot com
  Target Milestone: ---

Created attachment 42519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42519=edit
compressed compiler_error.ii

This internal compiler error involves a minimal call to the Eigen-3.3.4
template library. It works using clang and homebrewed GCC 7.2.0 on OSX, but
fails on Linux with GCC 7.2.0. It works using ICC on Linux.

Exact version of GCC: 7.2.0

System type: Linux, Ubuntu 16.04

GCC configure options: --enable-languages=c,c++ --disable-multilib

the complete command line that triggers the bug:
g++ -g -O1 -I/home/al17824/local/eigen-3.3.4 compiler_error.cpp -o
compiler_error

compiler output:
compiler_error.cpp:31:1: internal compiler error: Segmentation fault
 }
 ^
0xb1272f crash_signal
/home/al17824/objdir/../gcc-7.2.0/gcc/toplev.c:337
0x1168f51 ipa_inline
/home/al17824/objdir/../gcc-7.2.0/gcc/ipa-inline.c:2422
0x1168f51 execute
/home/al17824/objdir/../gcc-7.2.0/gcc/ipa-inline.c:2845

preprocessed file attached.

Code is fairly simple; most changes lead to the compiler succeeding.

#include 
#include 

class A {
 public:
  virtual double bar() const = 0;
};

class B : public A {
 public:
  double bar() const;
};

__attribute__((always_inline, flatten))
inline double B::bar() const {
  Eigen::Matrix v;
  return 0.0;
}

inline double foo(const B& c) {
  return c.bar();
}

void testError() {
  B model;
  std::cout << foo(model) << std::endl;
}

int main() {
  testError();
}

[Bug web/82798] Inconsistent descriptions for warning options in documentation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-01
 Ever confirmed|0   |1

[Bug c++/82800] New: Incorrect warning on "may be used uninitialized in this function" in variadic template code

[alonzakai at gmail dot com]

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

Bug ID: 82800
   Summary: Incorrect warning on "may be used uninitialized in
this function" in variadic template code
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alonzakai at gmail dot com
  Target Milestone: ---

The testcase below fails with

g++- a.cpp -std=c++11 -Wall -Werror -O2

It fails on 7.2.0, but works on 5.4.0, so this looks like a regression.

Testcase:
===
#include 
#include 
#include 

struct Maker {
  double makeConst() {
return pick(0, 0, 0, 0, 0, 0, 1);
  }

  template
  T pick(T first, Args... args) {
return pickGivenNum(rand(), first, args...);
  }

  template
  T pickGivenNum(size_t num, T first) {
if (num != 0) abort();
return first;
  }

  template
  T pickGivenNum(size_t num, T first, Args... args) {
if (num == 0) return first;
return pickGivenNum(num - 1, args...);
  }
};

int main() {
  Maker maker;
  maker.makeConst();
  maker.makeConst();
}
===

The error is
===
a.cpp: In function ‘double Maker::makeConst()’:
a.cpp:8:44: error: ‘first’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
 return pick(0, 0, 0, 0, 0, 0, 1); 
  ^
===
This may have something to do with it being a variadic template (I couldn't
reduce it any more without that template).

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #31 from Segher Boessenkool  ---
Okay, closing then (the patch has been backported to 6, too).  Thanks!

[Bug c++/82799] New: [8 Regression] -Wunused-but-set-variable false positive

[sgunderson at bigfoot dot com]

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

Bug ID: 82799
   Summary: [8 Regression] -Wunused-but-set-variable false
positive
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sgunderson at bigfoot dot com
  Target Milestone: ---

Hi,

Reduced testcase (automatically; it might be possible to reduce further):

enum a { b }; 
struct c {
template < a > int d() {
const bool is_ident = 0;
const int ret = is_ident ? 7 : 9;
return ret;
}
void e() {
d < b > ();
}
};

When compiled with -Wall, yields:

test.cc: In instantiation of 'int c::d() [with a  = (a)0]':
test.cc:9:12:   required from here
test.cc:4:14: warning: variable 'is_ident' set but not used
[-Wunused-but-set-variable]
   const bool is_ident = 0;
  ^~~~

even though is_ident is clearly used on the line below.

gcc version 8.0.0 20171017 (experimental) [trunk revision 253812] (Debian
20171017-1) 

This does not happen with GCC 7.2.1.

[Bug web/82798] New: Inconsistent descriptions for warning options in documentation

[julien at trigofacile dot com]

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

Bug ID: 82798
   Summary: Inconsistent descriptions for warning options in
documentation
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julien at trigofacile dot com
  Target Milestone: ---

In GCC 7 documentation:

1/ One can read "Some options, such as -Wall and -Wextra, turn on other
options, such as -Wunused" and later in the description of -Wunused:  "note
that -Wall implies -Wunused".

However, "-Wunused" is not listed in the list of warning flags turned on by
-Wall.
4 warning flags are instead listed in the -Wall list: -Wunused-function,
-Wunused-label, -Wunused-value and -Wunused-variable.
And 2 warning flags are listed in the -Werror list: -Wunused-parameter,
-Wunused-but-set-parameter.

It seems a bit confusing, and I believe there is something to fix.
Maybe in fact -Wunused is not turned on by -Wall?


2/ -Wuninitialized is listed in both -Wall and -Werror list.
And the description of -Wuninitialized does not mention either of them.
I believe there is something to fix for that.


3/ -Wall should list "-Walloc-size-larger-than=PTRDIFF_MAX" in the warning
flags turned on (according to GCC 7 changes).  The description should mention
that at the same time.


4/ The description of -Wexpansion-to-defined mentions that it is enabled by
-Wextra and -Wpedantic.  The list of warning flags turned on by them should
mention that.


5/ -Wall mentions two warnings that are not described in the documentation:
-Wmultistatement-macros and -Wreorder.  Can they be described please?


Thanks beforehand for fixing these issues.

Julien ÉLIE

[Bug c++/82797] New: Suggest -Wshadow suppression for nested if/else

[wsnyder at wsnyder dot org]

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

Bug ID: 82797
   Summary: Suggest -Wshadow suppression for nested if/else
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wsnyder at wsnyder dot org
  Target Milestone: ---

Created attachment 42518
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42518=edit
shadow.cpp

I would like to suggest that code similar to the following under -Wshadow:

if (ClassA* thing3 = geta()) {
operate(thing3);
}
else if (ClassB* thing3 = getb()) {  // Suggest no warning here
operate(thing3);
}

Not throw a:

   warning: declaration of 'thing2' shadows a previous local [-Wshadow]

While the warning is correct in that the else if's thing3 does in fact shadow
the first if's definition of thing3, this coding style makes it fairly clear
that the intent is to properly redefine thing3, and it is hard to imagine how
there could be a mistake as to which thing3 is being referred to.

Furthermore, there is no clean way to work around this warning; e.g. if the
"else if"'s thing3 is renamed it will only make the code less readable and
potentially lead to other errors e.g.:

if (ClassA* thing3 = geta()) {
operate(thing3);
}
else if (ClassB* thing3b = getb()) {  // used thing3b so no shadow warning
operate(thing3);  // Is this really thing3, or should it have been
thing3b?
}

Fixing the warning clearly makes the code less similar and more bug prone,
opposite of the intent of the warning.

However IMO this does, and should continue to result in a shadow warning:

if (ClassA* thing3 = geta()) {
operate(thing3);
}
else {
ClassB* thing3 = getb();
operate(thing3);
}

Thanks for your consideration. A test case is attached.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #30 from John Paul Adrian Glaubitz  ---
(In reply to Segher Boessenkool from comment #29)
> Is there anything left to do here?  Or can this PR be closed.

As both LibreOffice and GHC now build without issues on Debian powerpcspe with
gcc-7 as the default compiler, I think it's safe to assume that the bug has
been fixed.

I think it did still occur with gcc-6 though although I'm not sure anymore.
Either way, gcc-7 works correctly.

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  ---
Excellent, thanks for testing!  I'll backport it next week.

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[segher at gcc dot gnu.org]

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

--- Comment #29 from Segher Boessenkool  ---
Is there anything left to do here?  Or can this PR be closed.

[Bug rtl-optimization/82597] [8 Regression] ICE at -O2 and -O3 x86_64-linux-gnu in the 32-bit mode: in extract_constrain_insn, at recog.c:2207

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov  1 21:52:21 2017
New Revision: 254328

URL: https://gcc.gnu.org/viewcvs?rev=254328=gcc=rev
Log:
PR rtl-optimization/82778
PR rtl-optimization/82597
* compare-elim.c (struct comparison): Add in_a_setter field.
(find_comparison_dom_walker::before_dom_children): Remove killed
bitmap and df_simulate_find_defs call, instead walk the defs.
Compute last_setter and initialize in_a_setter.  Merge definitions
with first initialization for a few variables.
(try_validate_parallel): Use insn_invalid_p instead of
recog_memoized.  Return insn rather than just the pattern.
(try_merge_compare): Fix up comment.  Don't uselessly test if
in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
chains.
(execute_compare_elim_after_reload): Remove df_chain_add_problem
call.

* g++.dg/opt/pr82778.C: New test.

2017-11-01  Michael Collison  

PR rtl-optimization/82597
* gcc.dg/pr82597.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr82778.C
trunk/gcc/testsuite/gcc.dg/pr82597.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/compare-elim.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82778] crash: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov  1 21:52:21 2017
New Revision: 254328

URL: https://gcc.gnu.org/viewcvs?rev=254328=gcc=rev
Log:
PR rtl-optimization/82778
PR rtl-optimization/82597
* compare-elim.c (struct comparison): Add in_a_setter field.
(find_comparison_dom_walker::before_dom_children): Remove killed
bitmap and df_simulate_find_defs call, instead walk the defs.
Compute last_setter and initialize in_a_setter.  Merge definitions
with first initialization for a few variables.
(try_validate_parallel): Use insn_invalid_p instead of
recog_memoized.  Return insn rather than just the pattern.
(try_merge_compare): Fix up comment.  Don't uselessly test if
in_a is a REG_P.  Use cmp->in_a_setter instead of walking UD
chains.
(execute_compare_elim_after_reload): Remove df_chain_add_problem
call.

* g++.dg/opt/pr82778.C: New test.

2017-11-01  Michael Collison  

PR rtl-optimization/82597
* gcc.dg/pr82597.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr82778.C
trunk/gcc/testsuite/gcc.dg/pr82597.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/compare-elim.c
trunk/gcc/testsuite/ChangeLog

[Bug target/40503] DEC_EVAL_METHOD not match operators

[joseph at codesourcery dot com]

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

--- Comment #7 from joseph at codesourcery dot com  ---
As far as I understand the general state of DFP support in GCC: the basic 
functionality generally works without needing much maintenance, but no-one 
is actively fixing DFP bugs or updating the DFP support for TS 18661-2 / 
TS 18661-3, and no-one has ever hooked the DFP support up to the support 
for the C front-end to manage excess precision, so that support is only 
active for binary floating point.

[Bug target/82002] [8 Regression] ICE in sp_valid_at, at config/i386/i386.c:13233

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
pr82002-2a.c as well as pr82002-2b.c still ICE on the current trunk on
x86_64-linux:
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr82002-2a.c: In function
'b':
/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr82002-2a.c:14:1: error:
unrecognizable insn:
(insn/f 36 35 37 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 116 [0x2540be410])) [2  S16 A128])
(reg:V4SF 27 xmm6))
"/home/jakub/src/gcc/gcc/testsuite/gcc.target/i386/pr82002-2a.c":9 -1
 (expr_list:REG_DEAD (reg:V4SF 27 xmm6)
(expr_list:REG_CFA_EXPRESSION (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 116 [0x2540be410])) [2  S16 A128])
(reg:V4SF 27 xmm6))
(nil
during RTL pass: cprop_hardreg

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[hiraditya at msn dot com]

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

--- Comment #9 from AK  ---
Are we also taking advantage of this statement in the standard:

> An iteration statement that performs no input/output operations, does not 
> access volatile objects, and performs no
synchronization or atomic operations in its body, controlling
expression, or (in the case of a for statement) its expression may be assumed
by the implementation to terminate.

[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[andreast at gcc dot gnu.org]

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

--- Comment #14 from Andreas Tobler  ---
The gcc5 branch is closed, so I can not commit there. In the ports tree we're
on gcc6 as default gcc. We still can build gcc5. I certainly can talk to Gerald
to make an exception or whatever and patch the gcc5 port.

[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5

[h2+bugs at fsfe dot org]

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

--- Comment #13 from Hannes Hauswedell  ---
(In reply to Andreas Tobler from comment #12)
> Will soon commit a fix, for gcc6/7/8 on FreeBSD > 9.3. Older gcc's and OS
> releases will not be supported by this fix.

Thanks a lot!

But is there no chance of getting a fix for gcc5? Not even via patch in the
FreeBSD port (if not doable via gcc5 trunk)?
Because we would need to selectively disable gcc5 then (while gcc49 and >5
would still work which is kind of akward).

[Bug fortran/82796] [6/7/8 Regression] Private+equivalence in used module breaks compilation of pure function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-01
  Known to work||4.9.3
Summary|Private+equivalence in used |[6/7/8 Regression]
   |module breaks compilation   |Private+equivalence in used
   |of pure function|module breaks compilation
   ||of pure function
 Ever confirmed|0   |1
  Known to fail||5.5.0, 6.4.0, 7.2.0, 8.0

--- Comment #1 from Dominique d'Humieres  ---
The behavior changed between revisions r224148 (2015-06-05, OK) and r224160
(2015-06-05, error) likely r224159.

Note that the error appeared only once up to revision r227398 + two patches
(2015-09-02).

[Bug fortran/78293] [6/7/8 Regression] SIGABRT with function result used as argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
Fixed on all three branches.

Thanks for the report - sorry that it didn't make it to 5-branch.

Regards

Paul

[Bug fortran/78293] [6/7/8 Regression] SIGABRT with function result used as argument

[paul.richard.thomas at gmail dot com]

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

--- Comment #11 from paul.richard.thomas at gmail dot com  ---
I rather suspect that was why I had deleted the tree :-)

That's a pity. I am afraid moving from one country to another caused
this PR to get lost.

Cheers

Paul

On 1 November 2017 at 18:18, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293
>
> --- Comment #10 from Dominique d'Humieres  ---
>> Dominique,
>>
>> Do you still have 5-branch and, if so, could you commit the patch to it 
>> please?
>>
>> Cheers
>>
>> Paul
>
> Paul,
>
> The 5-branch is now closed.
>
> Dominique
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[sje at gcc dot gnu.org]

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

--- Comment #17 from Steve Ellcey  ---
Yes, this fixed my SPEC problem.

[Bug fortran/78293] [6/7/8 Regression] SIGABRT with function result used as argument

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Dominique,
>
> Do you still have 5-branch and, if so, could you commit the patch to it 
> please?
>
> Cheers
>
> Paul

Paul,

The 5-branch is now closed.

Dominique

[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
This is fixed by the patch for PR81447, which I am just about to submit.

Cheers

Paul

[Bug fortran/82796] New: Private+equivalence in used module breaks compilation of pure function

[ripero84 at gmail dot com]

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

Bug ID: 82796
   Summary: Private+equivalence in used module breaks compilation
of pure function
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ripero84 at gmail dot com
  Target Milestone: ---

gfortran (multiple versions including 7.2.0, 6.4.0 and 5.4.1,) fails to compile
the following code

===

MODULE EQ
  implicit none

  INTEGER :: N1
  INTEGER :: N2
  INTEGER, DIMENSION(2) :: a

  EQUIVALENCE (a(1), N1)
  EQUIVALENCE (a(2), N2)

  COMMON /A/ a
END MODULE EQ

!--

module m
  use eq
  implicit none
  private

  type, public :: t
integer :: i
  end type t

end module m

!--

module p
  implicit none
contains

  pure integer function d(h)
use m, only: t
implicit none
integer, intent(in) :: h
d = h
  end function

end module p

===

As far as I can see (see also
https://groups.google.com/forum/#!topic/comp.lang.fortran/9sC7kUje0Mc ), the
pure function is not attempting to access the variables that are affected by
the EQUIVALENCE in module EQ - what's more, the function should not be allowed
to have access to them since they are private.

Other compilers (intel, nag) and older versions of gfortran (4.8.4., 4.9.3) do
not complain about this and compile the code.

The compilation error is provided below.

===

$ gfortran-7 -v -c -std=f2008 foo.f90 -o foo.o
Using built-in specs.
COLLECT_GCC=gfortran-7
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-12'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.1 20171025 (Debian 7.2.0-12) 
COLLECT_GCC_OPTIONS='-v' '-c' '-std=f2008' '-o' 'foo.o' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/f951 foo.f90 -quiet -dumpbase foo.f90
-mtune=generic -march=x86-64 -auxbase-strip foo.o -std=f2008 -version
-fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/7/finclude -o
/tmp/ccpUItgn.s
GNU Fortran (Debian 7.2.0-12) version 7.2.1 20171025 (x86_64-linux-gnu)
compiled by GNU C version 7.2.1 20171025, GMP version 6.1.2, MPFR
version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP

warning: MPFR header version 3.1.6 differs from library version 3.1.5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (Debian 7.2.0-12) version 7.2.1 20171025 (x86_64-linux-gnu)
compiled by GNU C version 7.2.1 20171025, GMP version 6.1.2, MPFR
version 3.1.6, MPC version 1.0.3, isl version isl-0.18-GMP

warning: MPFR header version 3.1.6 differs from library version 3.1.5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
foo.f90:34:8:

 use m, only: t
1
Error: Common block member ‘a’ at (1) cannot be an EQUIVALENCE object in the
pure procedure ‘d’
foo.f90:34:8:

 use m, only: t
1
Error: Common block member ‘a’ at (1) cannot be an EQUIVALENCE object in the
pure procedure ‘d’

[Bug fortran/78293] [6/7/8 Regression] SIGABRT with function result used as argument

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #7)
> > > Revision r242875 caused pr79344. Is there any plan to back port the fixes 
> > > to
> > > the 6 branch?
> >
> > That's a good question. What is your opinion?
> 
> Well, it is a [5/6/7 Regression]. How much pain does it requires to back
> port?

Dominique,

Do you still have 5-branch and, if so, could you commit the patch to it please?

Cheers

Paul

[Bug fortran/78293] [6/7/8 Regression] SIGABRT with function result used as argument

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Wed Nov  1 17:24:35 2017
New Revision: 254319

URL: https://gcc.gnu.org/viewcvs?rev=254319=gcc=rev
Log:
2017-11-01  Andre Vehreschild  
Paul Thomas  

PR fortran/78293
* trans-expr.c (gfc_conv_procedure_call): Prepend deallocation
of alloctable components to post, rather than adding to
se->post.
* trans-stmt.c (gfc_trans_allocate): Move deallocation of expr3
allocatable components so that all expr3s are visited.

2017-11-01  Paul Thomas  

PR fortran/78293
* gfortran.dg/allocatable_function_10.f90: New test.
* gfortran.dg/class_array_15.f03: Increase builtin_free count
from 11 to 12.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/allocatable_function_10.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-expr.c
branches/gcc-6-branch/gcc/fortran/trans-stmt.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/class_array_15.f03

[Bug c/82792] Fallthrough attribute ignored after label

[michael.thayer at oracle dot com]

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

--- Comment #9 from Michael Thayer  ---
Created attachment 42517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42517=edit
Assembly output

[Bug c/82792] Fallthrough attribute ignored after label

[michael.thayer at oracle dot com]

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

--- Comment #8 from Michael Thayer  ---
Created attachment 42516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42516=edit
Preprocessor output (almost identical to source)

[Bug c/82792] Fallthrough attribute ignored after label

[michael.thayer at oracle dot com]

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

--- Comment #7 from Michael Thayer  ---
Created attachment 42515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42515=edit
g++ -v -save-temps -c -Wextra -Werror -fsanitize=address -o test.o test.cpp >
gcc-out 2>&1

[Bug c/82792] Fallthrough attribute ignored after label

[michael.thayer at oracle dot com]

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

--- Comment #6 from Michael Thayer  ---
Created attachment 42514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42514=edit
New test case

[Bug c/82792] Fallthrough attribute ignored after label

[michael.thayer at oracle dot com]

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

--- Comment #5 from Michael Thayer  ---
This works for the test case I provided above, but not for our original source.
 Attaching a new test case.  This one is slightly more involved, as it requires
both g++ and address sanitizer.  Should I create a new bug for this?

[Bug libstdc++/82777] incorrect result of std::filesystem::path::lexically_normal

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Thanks for the report, it now prints the expected results:

lexically normal :"a/b/c"
weakly_canonical : "/tmp/a/b/c"

[Bug c++/82790] [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const

[eugene.zelenko at gmail dot com]

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

--- Comment #2 from Eugene Zelenko  ---
Just a little bit of background: a lot of legacy C code was converted to C++,
so a lot of type casts were necessary to compile it properly. Gradually char *
are converted to const char *, so -Wuseless-cast will be helpful for
refactoring.

[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> AFAICT the ICE disappears if the files are put in a single one.

Yep.  I played with this a little yesterday.  This suggests
that when a module is saved and an attribute for a polymorphic
entity isn't saved correctly or re-read from the module
correctly.

[Bug libstdc++/82777] incorrect result of std::filesystem::path::lexically_normal

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov  1 17:09:14 2017
New Revision: 254317

URL: https://gcc.gnu.org/viewcvs?rev=254317=gcc=rev
Log:
PR libstdc++/82777 fix path normalization for dot-dot

PR libstdc++/82777
* src/filesystem/std-path.cc (path::lexically_normal): Remove dot-dot
elements correctly.
* testsuite/27_io/filesystem/path/generation/normal.cc: Add testcase.
* testsuite/util/testsuite_fs.h (compare_paths): Improve exception
text.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/filesystem/std-path.cc
trunk/libstdc++-v3/testsuite/27_io/filesystem/path/generation/normal.cc
trunk/libstdc++-v3/testsuite/util/testsuite_fs.h

[Bug target/40503] DEC_EVAL_METHOD not match operators

[tydeman at tybor dot com]

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

--- Comment #6 from Fred J. Tydeman  ---
No.  All evaluations should be as if 34 digits of precision.

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

--- Comment #16 from Segher Boessenkool  ---
Should be fixed on trunk now.  Steve, could you see if it fixes the
SPEC problem for you?

[Bug rtl-optimization/69567] PowerPC64: cstore optimisation produces bad code

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Author: segher
Date: Wed Nov  1 16:40:42 2017
New Revision: 254315

URL: https://gcc.gnu.org/viewcvs?rev=254315=gcc=rev
Log:
combine: Fix bug in giving up placing REG_DEAD notes (PR82683)

When we have a REG_DEAD note for a reg that is set in the new I2, we
drop the note on the floor (we cannot find whether to place it on I2
or on I3).  But the code I added to do this has a bug and does not
always actually drop it.  This patch fixes it.

But that on its own is too pessimistic, it turns out, and we generate
worse code.  One case where we do know where to place the note is if
it came from I3 (it should go to I3 again).  Doing this fixes all of
the regressions.


PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

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

[Bug rtl-optimization/64682] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
Author: segher
Date: Wed Nov  1 16:40:42 2017
New Revision: 254315

URL: https://gcc.gnu.org/viewcvs?rev=254315=gcc=rev
Log:
combine: Fix bug in giving up placing REG_DEAD notes (PR82683)

When we have a REG_DEAD note for a reg that is set in the new I2, we
drop the note on the floor (we cannot find whether to place it on I2
or on I3).  But the code I added to do this has a bug and does not
always actually drop it.  This patch fixes it.

But that on its own is too pessimistic, it turns out, and we generate
worse code.  One case where we do know where to place the note is if
it came from I3 (it should go to I3 again).  Doing this fixes all of
the regressions.


PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

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

[Bug rtl-optimization/69737] [5 Regression] FAIL: gcc.c-torture/execute/pr64682.c -O2 execution test

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Author: segher
Date: Wed Nov  1 16:40:42 2017
New Revision: 254315

URL: https://gcc.gnu.org/viewcvs?rev=254315=gcc=rev
Log:
combine: Fix bug in giving up placing REG_DEAD notes (PR82683)

When we have a REG_DEAD note for a reg that is set in the new I2, we
drop the note on the floor (we cannot find whether to place it on I2
or on I3).  But the code I added to do this has a bug and does not
always actually drop it.  This patch fixes it.

But that on its own is too pessimistic, it turns out, and we generate
worse code.  One case where we do know where to place the note is if
it came from I3 (it should go to I3 again).  Doing this fixes all of
the regressions.


PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

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

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool  ---
Author: segher
Date: Wed Nov  1 16:40:42 2017
New Revision: 254315

URL: https://gcc.gnu.org/viewcvs?rev=254315=gcc=rev
Log:
combine: Fix bug in giving up placing REG_DEAD notes (PR82683)

When we have a REG_DEAD note for a reg that is set in the new I2, we
drop the note on the floor (we cannot find whether to place it on I2
or on I3).  But the code I added to do this has a bug and does not
always actually drop it.  This patch fixes it.

But that on its own is too pessimistic, it turns out, and we generate
worse code.  One case where we do know where to place the note is if
it came from I3 (it should go to I3 again).  Doing this fixes all of
the regressions.


PR rtl-optimization/64682
PR rtl-optimization/69567
PR rtl-optimization/69737
PR rtl-optimization/82683
* combine.c (distribute_notes) : If the new I2 sets the same
register mentioned in the note, drop the note, unless it came from I3,
in which case it should go to I3 again.

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

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Thanks. The relevant line is:

void syslog(int, const char *, ...) __attribute__((__format__ (__printf__, 2,
3))) __asm("_" "syslog" "$DARWIN_EXTSN");

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[sje at gcc dot gnu.org]

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

--- Comment #14 from Steve Ellcey  ---
(In reply to Segher Boessenkool from comment #13)
> I have a simpler patch.  It is testing...

Can you attach your patch to this defect so I can test it as well.

[Bug target/82795] New: [8 Regression] ICE in predicate_mem_writes, at tree-if-conv.c:2251

[asolokha at gmx dot com]

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

Bug ID: 82795
   Summary: [8 Regression] ICE in predicate_mem_writes, at
tree-if-conv.c:2251
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-8.0.0-alpha20171029 snapshot (r254205) ICEs when compiling the following
snippet w/ -mavx2 -O3 or -mavx2 -Ofast:

void
sj (int qh, int rn, int *by)
{
  for (;;)
if (qh != 0)
  {
int dc;

for (dc = 0; dc < 17; ++dc)
  {
int nn;

nn = (rn != 0) ? qh : dc;
if (nn != 0)
  qh = nn;
else
  qh = (qh != 0) ? *by : dc;
  }
  }
}

% gcc-8.0.0-alpha20171029 -mavx2 -O3 -w -c w6osxlfx.c
during GIMPLE pass: ifcvt
w6osxlfx.c: In function 'sj':
w6osxlfx.c:2:1: internal compiler error: in predicate_mem_writes, at
tree-if-conv.c:2251
 sj (int qh, int rn, int *by)
 ^~
0x5dd228 predicate_mem_writes
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/tree-if-conv.c:2251
0x5dd228 combine_blocks
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/tree-if-conv.c:2377
0xcd7337 tree_if_conversion(loop*)
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/tree-if-conv.c:2885
0xcd810e execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171029/work/gcc-8-20171029/gcc/tree-if-conv.c:2963

[Bug c/82216] internal compiler error: Illegal instruction

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Marek Polacek  ---
Feedback not coming, please reopen if you manage to produce a stand-alone
testcase.

[Bug c/82792] Fallthrough attribute ignored after label

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
You should just swap these two lines:
__attribute__((fallthrough));
default_case:
so that the null statement with the attribute precedes the case.

Not a bug.

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[drikosev at gmail dot com]

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

--- Comment #6 from Ev Drikos  ---
1) the exact version of GCC:
$ gcc7 --version
gcc7 (GCC) 7.1.1 20170622
Copyright (C) 2017 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.

2) the system type:
$ uname -a
Darwin miniserver.local 17.0.0 Darwin Kernel Version 17.0.0: Thu Aug 24
21:48:19 PDT 2017; root:xnu-4570.1.46~2/RELEASE_X86_64 x86_64

3) the options given when GCC was configured/built
$ gcc7 -v
Using built-in specs.
COLLECT_GCC=gcc7
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin17/7.1.1/lto-wrapper
Target: x86_64-apple-darwin17
Configured with: ../gcc-7-20170622/configure --prefix=/opt/local
--program-suffix=7 --build=x86_64-apple-darwin17
--enable-languages=c,c++,fortran --disable-bootstrap --disable-nls
--enable-checking=release --with-system-zlib --enable-threads=posix
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --with-ar=/usr/bin/ar
AR_FOR_TARGET=/usr/bin/ar AS_FOR_TARGET=/usr/bin/as LD_FOR_TARGET=/usr/bin/ld
NM_FOR_TARGET=/usr/bin/nm OBJDUMP_FOR_TARGET=/usr/bin/objdump
RANLIB_FOR_TARGET=/usr/bin/ranlib STRIP_FOR_TARGET=/usr/bin/strip
OTOOL=/usr/bin/otool OTOOL64=/usr/bin/otool LIPO=/usr/bin/lipo
LIPO_FOR_TARGET=/usr/bin/lipo CC=/opt/local/bin/gcc CXX=/opt/local/bin/g++
CPP=/opt/local/bin/cpp GCC=/opt/local/bin/gcc CC_FOR_TARGET=/opt/local/bin/gcc
CXX_FOR_TARGET=/opt/local/bin/g++ CPP_FOR_TARGET=/opt/local/bin/cpp
GCC_FOR_TARGET=/opt/local/bin/gcc CFLAGS='-O2 -g -mmacosx-version-min=10.13
-fstack-protector-strong --param=ssp-buffer-size=4 ' CXXFLAGS='-O2 -g
-mmacosx-version-min=10.13 -fstack-protector-strong --param=ssp-buffer-size=4'
'CFLAGS_FOR_TARGET=-O2 -g -mmacosx-version-min=10.13 -fstack-protector-strong
--param=ssp-buffer-size=4 ' 'CXXFLAGS_FOR_TARGET=-O2 -g
-mmacosx-version-min=10.13 -fstack-protector-strong --param=ssp-buffer-size=4'
Thread model: posix
gcc version 7.1.1 20170622 (GCC) 

4) the complete command line that triggers the bug:
$ gcc7 -save-temps syslog.c
5) the compiler output (error messages, warnings, etc.):
In file included from /usr/include/syslog.h:23:0,
 from syslog.c:1:
/usr/include/sys/syslog.h:227:84: error: expected ',' or ';' before '__asm'
 void syslog(int, const char *, ...) __printflike(2, 3) __not_tail_called
__DARWIN_ALIAS_STARTING(__MAC_10_13, __IPHONE_NA, __DARWIN_EXTSN(syslog));
   
^
6) the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command.
   It's the attachment syslog.i

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[drikosev at gmail dot com]

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

--- Comment #5 from Ev Drikos  ---
Created attachment 42513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42513=edit
syslog.i

[Bug fortran/82774] [6/7/8 Regression] Structure constructor and deferred type parameter character component

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gmx dot de

--- Comment #3 from kargl at gcc dot gnu.org ---
I added Andre as r219801 appears to be a patch that he developed.

[Bug c++/82794] ICE: Cannot allocate memory for concept with default argument

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirm, all supporting -fconcepts ICE.
However I see following backtrace:

pr82794.cpp:4:10: internal compiler error: in tsubst, at cp/pt.c:13756
 template
  ^~~
0x7bb3ee tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13756
0x7cc4bc coerce_template_parms
../../gcc/cp/pt.c:8203
0x655011 resolve_variable_concept_check(tree_node*)
../../gcc/cp/constraint.cc:303
0x655224 deduce_constrained_parameter(tree_node*, tree_node*&, tree_node*&)
../../gcc/cp/constraint.cc:328
0x7413ae cp_parser_maybe_constrained_type_specifier
../../gcc/cp/parser.c:17479
0x741541 cp_parser_nonclass_name
../../gcc/cp/parser.c:17570
0x7643c3 cp_parser_type_name
../../gcc/cp/parser.c:17376
0x7643c3 cp_parser_simple_type_specifier
../../gcc/cp/parser.c:17248
0x7613ad cp_parser_type_specifier
../../gcc/cp/parser.c:16894
0x76f836 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:13684
0x76ff71 cp_parser_parameter_declaration
../../gcc/cp/parser.c:21564
0x771286 cp_parser_template_parameter
../../gcc/cp/parser.c:15509
0x771286 cp_parser_template_parameter_list
../../gcc/cp/parser.c:15098
0x7756ee cp_parser_explicit_template_declaration
../../gcc/cp/parser.c:27045
0x7756ee cp_parser_template_declaration_after_export
../../gcc/cp/parser.c:27079
0x77bac9 cp_parser_declaration
../../gcc/cp/parser.c:12788
0x77bdfb cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:12715
0x77c10b cp_parser_translation_unit
../../gcc/cp/parser.c:4502
0x77c10b c_parse_file()
../../gcc/cp/parser.c:39021
0x8c3086 c_common_parse_file()
../../gcc/c-family/c-opts.c:1124

[Bug c++/82794] New: ICE: Cannot allocate memory for concept with default argument

[victor.nicolae.savu at gmail dot com]

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

Bug ID: 82794
   Summary: ICE: Cannot allocate memory for concept with default
argument
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: victor.nicolae.savu at gmail dot com
  Target Milestone: ---

Here is the reproduction on godbolt: https://godbolt.org/g/Ag8aqs

When I try to define a concept with two template arguments where latter depends
on the former:

> code: -
template
concept bool Foo = true;

template
using foo = void;
> ---

I get the following error:

> 4 : :4:10: internal compiler error: in tsubst, at cp/pt.c:13607
>  template
>   ^~~
mmap: Cannot allocate memory

Compiler version:
> x86-64 GCC 7.2
Compiler flags:
> -fconcepts


It seems that it doesn't really matter what template we are defining. I went
for a generic using statement just for the simple reproduction, but foo could
be a function or a class and the same problem occurs.

The problem seems to stem from the `typename G = F` part. Variations such as
`typename G = typename F::associated` also fail.

Replacing that by `typename G` results in a valid compilation error, while
replacing by `typename G = int` leads to successful compilation (as expected).

Please let me know if there is any other information that I need to provide.

[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #2 from Dominique d'Humieres  ---
AFAICT the ICE disappears if the files are put in a single one.

[Bug c++/82793] __attribute__((target("sse"))) causes call throught ifunc

[vorfeed.canal at gmail dot com]

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

--- Comment #1 from Vorfeed Canal  ---
Example closer to real code:

#include "xmmintrin.h"

inline __attribute__((target("avx"),visibility("hidden"))) __m128 foo(__m128 a,
__m128 b) {
  return _mm_add_ps(a, b);
}

inline __attribute__((target("sse4.2"),visibility("hidden"))) __m128 foo(__m128
a, __m128 b) {
  return _mm_add_ps(a, b);
}

inline __attribute__((target("default"),visibility("hidden"))) __m128
foo(__m128 a, __m128 b) {
  return _mm_add_ps(a, b);
}

__attribute__((target("sse4.2"))) __m128 bar(__m128 a, __m128 b) {
  return foo(a, b);
}

__attribute__((target("avx"))) __m128 bar(__m128 a, __m128 b) {
  return foo(a, b);
}

__attribute__((target("default"))) __m128 bar(__m128 a, __m128 b) {
  return foo(a, b);
}

Result of compilation:

.type   _Z3barDv4_fS_.avx, @function
_Z3barDv4_fS_.avx:
.LFB529:
.cfi_startproc
vaddps  %xmm1, %xmm0, %xmm0
ret
.cfi_endproc

.type   _Z3barDv4_fS_.sse4.2, @function
_Z3barDv4_fS_.sse4.2:
.LFB542:
.cfi_startproc
jmp _Z19_Z3fooDv4_fS_.ifuncDv4_fS_
.cfi_endproc


Needless to say: when simple, short, INLINE function is called via resolver
performance takes unacceptable hit.

[Bug c++/82793] New: __attribute__((target("sse"))) causes call throught ifunc

[vorfeed.canal at gmail dot com]

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

Bug ID: 82793
   Summary: __attribute__((target("sse"))) causes call throught
ifunc
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vorfeed.canal at gmail dot com
  Target Milestone: ---

The following example illustrates the problem:

#include "xmmintrin.h"

extern __attribute__((target("avx"),visibility("hidden"))) __m128 foo(__m128 a,
__m128 b);
extern __attribute__((target("sse4.2"),visibility("hidden"))) __m128 foo(__m128
a, __m128 b);
extern __attribute__((target("default"),visibility("hidden"))) __m128
foo(__m128 a, __m128 b);

__attribute__((target("sse4.2"))) __m128 bar(__m128 a, __m128 b) {
  return foo(a, b);
}

__attribute__((target("avx"))) __m128 bar(__m128 a, __m128 b) {
  return foo(a, b);
}

__attribute__((target("default"))) __m128 bar(__m128 a, __m128 b) {
  return foo(a, b);
}

All versions of GCC which I've tried produced the following code:

...
   .type   _Z3barDv4_fS_.avx, @function
_Z3barDv4_fS_.avx:
.LFB526:
.cfi_startproc
jmp _Z3fooDv4_fS_.avx
.cfi_endproc
...
.type   _Z3barDv4_fS_.sse4.2, @function
_Z3barDv4_fS_.sse4.2:
.LFB525:
.cfi_startproc
jmp _Z19_Z3fooDv4_fS_.ifuncDv4_fS_
.cfi_endproc


That is: AVX functions are calling AVX functions directly while SSE4.2
functions call SSE4.2 functions via ifunc-resolver. Needless to day this kills
the performance quite throughly - and this IS the reason to use function
multiversioning with AVS/SSE attributes!

[Bug target/82767] [8 regression] gcc.target/i386/pr71321.c scan-assembler-times fail

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The bug submission process asked you to read https://gcc.gnu.org/bugs/ which
says how to do it.

[Bug c++/82768] ICE in synthesize_implicit_template_parm, at cp/parser.c:39338

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-01
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||6.4.0, 7.2.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed on all release that support -fconcepts. Is it a valid code?

[Bug hsa/82771] FAIL: brig.dg/test/gimple/packed.hsail (internal compiler error)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[drikosev at gmail dot com]

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

--- Comment #3 from Ev Drikos  ---
Created attachment 42512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42512=edit
On Darwin 10.13: "cpp7 /usr/include/syslog.h>cpp7syslog.h"


If this isn't what you expect, please feel free to tell me how I should run the
preprocessor.

Ev. Drikos

[Bug tree-optimization/82776] Unable to optimize the loop when iteration count is unavailable.

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
At some point, we could also think of taking advantage of what the C++ standard
(for instance) says:

"[intro.progress]
The implementation may assume that any thread will eventually do one of the
following:
(1.1) — terminate,
(1.2) — make a call to a library I/O function,
(1.3) — perform an access through a volatile glvalue, or
(1.4) — perform a synchronization operation or an atomic operation.
[ Note: This is intended to allow compiler transformations such as removal of
empty loops, even when termination cannot be proven. — end note ]"

The only potential "progress" in this loop is the call to
__builtin_ia32_pmovmskb128, but replacing it with a call to a function with
attribute((const)) does not help. And if there is no progress in the loop, the
loop must be finite.

(we could have some new flag if people insist on for(;;); not being optimized
away. I would even use a flag -fno-infinite-loop that says that no loop can be
infinite, or -fmain-returns that says that no loop is infinite and the program
cannot trap or terminate, etc, but that's getting a bit far from this PR)

[Bug gcov-profile/45891] Guessed profile needs updating after profile-read

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška  ---
I guess it's currently fixed as Honza did big reorganization of profiling
infrastructure.

[Bug rtl-optimization/81803] [7/8 regression] miscompilation at -O1 on mips64el

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|mpf at gcc dot gnu.org |ebotcazou at gcc dot 
gnu.org

--- Comment #20 from Eric Botcazou  ---
Assigning back.

[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.4.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2017-11-01
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|gfotran ICEs when compiling |[7/8 Regression] gfortran
   |polymorphic function call   |ICEs when compiling
   ||polymorphic function call
   Target Milestone|--- |7.3
  Known to fail||7.2.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r241450.

[Bug c/82787] gnu gcc (4.8 - 7.1) cannot parse some system headers in macOS (10.13)

[drikosev at gmail dot com]

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

--- Comment #2 from Ev Drikos  ---
(In reply to Andrew Pinski from comment #1)
> Can you provide the preprocessed source?

What command I should run?

Ev. Drikos

[Bug gcov-profile/79392] MinGW-w64 backend: programs built with --coverage do not create *.gcda files

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Martin Liška  ---
Closing as I can't reproduce and 5.4.0 is not longer supported.
Please reopen if still valid.

[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)

[marxin at gcc dot gnu.org]

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

--- Comment #15 from Martin Liška  ---
(In reply to Matti Bryce from comment #14)
> (In reply to Martin Liška from comment #12)
> > (In reply to Matti Bryce from comment #7)
> > > (In reply to Martin Liška from comment #5)
> > > > Confirmed with cross compiler, I reduce a test-case.
> > > 
> > > I've attempted to reduce a test case, but after 2 days of running creduce,
> > > the produced file won't generate the error.
> > 
> > Hi. Looks you hit stack overflow. In that case, please use ulimit and set
> > smaller stack, that will simplify the reduction. You have to properly write
> > creduce script that will catch the ICE:
> > https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
> > 
> > And please use -fmax-errors=1 which will guarantee that reduced test-case
> > will be a valid code.
> > 
> > Please either download debug symbols for GCC package. Or build your own from
> > source: https://gcc.gnu.org/install/configure.html
> > 
> > Feel free to ask for questions..
> 
> There are no debug symbols available, so I'm going to have to build gcc. But
> I can't find the configure option on
> https://gcc.gnu.org/install/configure.html, so if you could tell me the flag
> to use to enable debug symbols, that would be helpful. 

You can basically following in root folder:

$ mkdir objdir
$ cd objdir
$ ../configure --enable-languages=c,c++ --disable-multilib --disable-bootstrap
--disable-libsanitizer
$ make -j8
$ ./gcc/xg++ -Bgcc [rest_of_options]

That should trigger the ICE.

> 
> I'm running creduce again, so I'll get back to you on that once it has
> finished running.
> 
> Thanks.
> 
> Thanks.

[Bug fortran/80554] [f08] variable redefinition in submodule

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #8 from Paul Thomas  ---
Fixed on 6-, 7- and 8-branches.

Thanks for the report.

Paul

[Bug fortran/80554] [f08] variable redefinition in submodule

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Wed Nov  1 12:39:48 2017
New Revision: 254303

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

PR fortran/80554
* decl.c (build_sym): In a submodule allow overriding of host
associated symbols from the ancestor module with a new
declaration.

2017-11-01  Paul Thomas  

PR fortran/80554
* gfortran.dg/submodule_29.f08: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_29.f08
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug fortran/80554] [f08] variable redefinition in submodule

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas  ---
Added by hand because I used the wrong file for the -F option on commit to
7-branch:

Author: pault
Date: Wed Nov  1 11:29:07 2017
New Revision: 254299

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

2017-11-01  Paul Thomas  

PR fortran/80554
* decl.c (build_sym): In a submodule allow overriding of host
associated symbols from the ancestor module with a new
declaration.

2017-11-01  Paul Thomas  

PR fortran/80554
* gfortran.dg/submodule_29.f08: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/submodule_29.f08
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[pault at gcc dot gnu.org]

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

--- Comment #28 from Paul Thomas  ---
(In reply to Paul Thomas from comment #27)
> Author: pault
> Date: Wed Nov  1 11:29:07 2017
> New Revision: 254299
> 
> URL: https://gcc.gnu.org/viewcvs?rev=254299=gcc=rev
> Log:
> 2017-11-01  Paul Thomas  
> 
>   PR fortran/80850
>   * trans_expr.c (gfc_conv_procedure_call): When passing a class
>   argument to an unlimited polymorphic dummy, it is wrong to cast
>   the passed expression as unlimited, unless it is unlimited. The
>   correct way is to assign to each of the fields and set the _len
>   field to zero.
> 
> 2017-11-01  Paul Thomas  
> 
>   PR fortran/80850
>   * gfortran.dg/class_64_f90 : New test.
> 
> Added:
> branches/gcc-7-branch/gcc/testsuite/gfortran.dg/submodule_29.f08
> Modified:
> branches/gcc-7-branch/gcc/fortran/ChangeLog
> branches/gcc-7-branch/gcc/fortran/decl.c
> branches/gcc-7-branch/gcc/testsuite/ChangeLog

Blast, this is the fix for PR80554.! I used the wrong file for the -F option on
the commit.

Ignore the noise!

[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Predcom uses below comparison function to make sure references in chain are
sorted in lexicographic order.  That is, inter-iteration deps are sorted in
iteration order; intra-iteration deps are sorted in dominant order.

/* Compares two drefs A and B by their offset and position.  Callback for
   qsort.  */

static int
order_drefs (const void *a, const void *b)
{
  const dref *const da = (const dref *) a;
  const dref *const db = (const dref *) b;
  int offcmp = wi::cmps ((*da)->offset, (*db)->offset);

  if (offcmp != 0)
return offcmp;

  return (*da)->pos - (*db)->pos;
}

The issue is triggered by re-association of combination, in which
re-association position is different to the original reference point.  It's
wrong to generate/replace re-associated combined reference using order of the
original combined chain.  Working on a fix.

[Bug c++/82565] [7/8 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-01
  Known to work||7.1.0
Summary|Concept and lambda return   |[7/8 Regression] Concept
   |type deduction cause|and lambda return type
   |compilation to crash with   |deduction cause compilation
   |"mmap: Cannot allocate  |to crash with "mmap: Cannot
   |memory" |allocate memory"
 Ever confirmed|0   |1
  Known to fail||7.2.0, 8.0

--- Comment #1 from Jonathan Wakely  ---
Trunk gives a seemingly bogus error before the ICE:

mozilla_jwakely0/crash.cpp: In instantiation of ‘run_test()::
[with auto:1 = const std::__cxx11::basic_string]’:
mozilla_jwakely0/crash.cpp:9:12:   required from here
mozilla_jwakely0/crash.cpp:49:47: error: use of parameter from containing
function
 return object.visit([] (auto& x) { return x.empty(); });
   ^
mozilla_jwakely0/crash.cpp:49:35: note: ‘const
std::__cxx11::basic_string& x’ declared here
 return object.visit([] (auto& x) { return x.empty(); });
 ~~^
mozilla_jwakely0/crash.cpp:49:58: internal compiler error: Segmentation fault
 return object.visit([] (auto& x) { return x.empty(); });
  ^

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[pault at gcc dot gnu.org]

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

--- Comment #27 from Paul Thomas  ---
Author: pault
Date: Wed Nov  1 11:29:07 2017
New Revision: 254299

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

PR fortran/80850
* trans_expr.c (gfc_conv_procedure_call): When passing a class
argument to an unlimited polymorphic dummy, it is wrong to cast
the passed expression as unlimited, unless it is unlimited. The
correct way is to assign to each of the fields and set the _len
field to zero.

2017-11-01  Paul Thomas  

PR fortran/80850
* gfortran.dg/class_64_f90 : New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/submodule_29.f08
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/decl.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/82790] [GCC 5, 6, 7] -Wuseless-cast doesn't detect unnecessary removal of const

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

--- Comment #1 from Jonathan Wakely  ---
This seems like a fairly niche warning for an uncommon problem.

Neither Clang nor EDG warns about this either.

[Bug c++/82789] Invalid code generated for std::array element-wise processing with -O3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Dup.

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

[Bug target/82524] [7/8 Regression] expensive-optimizations produces wrong results

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||nazarenkoal at gmail dot com

--- Comment #20 from Martin Liška  ---
*** Bug 82789 has been marked as a duplicate of this bug. ***

[Bug fortran/82774] [6/7/8 Regression] Structure constructor and deferred type parameter character component

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.3
   Keywords||wrong-code
   Last reconfirmed||2017-11-01
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|Structure constructor and   |[6/7/8 Regression]
   |deferred type parameter |Structure constructor and
   |character component |deferred type parameter
   ||character component
  Known to fail||5.5.0, 6.4.0, 7.2.0

--- Comment #2 from Dominique d'Humieres  ---
This is a regression which occurred between revision r219763 (2015-01-16, OK)
and r219772 + one patch (2015-01-16, wrong code), likely revision r219801.

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

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

[Bug c++/81702] [7/8 Regression] ICE in gimple_get_virt_method_for_vtable

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
Author: jamborm
Date: Wed Nov  1 10:35:13 2017
New Revision: 254295

URL: https://gcc.gnu.org/viewcvs?rev=254295=gcc=rev
Log:
[PR 81702] Remove devirtualization assert

2017-11-01  Martin Jambor  

PR c++/81702
* gimple-fold.c (gimple_get_virt_method_for_vtable): Remove assert.

testsuite/
* g++.dg/tree-ssa/pr81702.C: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/tree-ssa/pr81702.C
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/gimple-fold.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog