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

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-12
   Target Milestone|--- |9.0
Summary|False positive  |[9 Regression] False
   |-Waddress-of-packed-member  |positive
   ||-Waddress-of-packed-member
 Ever confirmed|0   |1

[Bug libstdc++/88811] libstdc++-v3/src/filesystem/path.cc:503: possible cut'n'paste error ?

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
Minor quibble on one of the lines:

   + (pstr1.length() || pstr2.length() ? pstr1.length() + 3 : 0)

Given the number of folks who fail to read correctly the ternary
operator, would this be better as

   + ((pstr1.length() || pstr2.length()) ? (pstr1.length() + 3) : 0)

to make the meaning more clear ?

[Bug libstdc++/88811] libstdc++-v3/src/filesystem/path.cc:503: possible cut'n'paste error ?

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I think it's pretty obvious from the context.

Parenthesizing the second operand is certainly useless. Obviously the colon
binds to the question mark, not the plus operator.

[Bug libfortran/88807] misleading indentation warnings building libgfortran

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jan 12 09:15:54 2019
New Revision: 267875

URL: https://gcc.gnu.org/viewcvs?rev=267875&root=gcc&view=rev
Log:
PR libfortran/88807
* m4/minloc0.m4: Reindent to avoid -Wmisleading-indentation warnings.
* generated/minloc0_4_i1.c: Regenerated.
* generated/minloc0_4_i2.c: Regenerated.
* generated/minloc0_4_i4.c: Regenerated.
* generated/minloc0_4_i8.c: Regenerated.
* generated/minloc0_4_i16.c: Regenerated.
* generated/minloc0_4_r4.c: Regenerated.
* generated/minloc0_4_r8.c: Regenerated.
* generated/minloc0_4_r10.c: Regenerated.
* generated/minloc0_4_r16.c: Regenerated.
* generated/minloc0_8_i1.c: Regenerated.
* generated/minloc0_8_i2.c: Regenerated.
* generated/minloc0_8_i4.c: Regenerated.
* generated/minloc0_8_i8.c: Regenerated.
* generated/minloc0_8_i16.c: Regenerated.
* generated/minloc0_8_r4.c: Regenerated.
* generated/minloc0_8_r8.c: Regenerated.
* generated/minloc0_8_r10.c: Regenerated.
* generated/minloc0_8_r16.c: Regenerated.
* generated/minloc0_16_i1.c: Regenerated.
* generated/minloc0_16_i2.c: Regenerated.
* generated/minloc0_16_i4.c: Regenerated.
* generated/minloc0_16_i8.c: Regenerated.
* generated/minloc0_16_i16.c: Regenerated.
* generated/minloc0_16_r4.c: Regenerated.
* generated/minloc0_16_r8.c: Regenerated.
* generated/minloc0_16_r10.c: Regenerated.
* generated/minloc0_16_r16.c: Regenerated.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/minloc0_16_i1.c
trunk/libgfortran/generated/minloc0_16_i16.c
trunk/libgfortran/generated/minloc0_16_i2.c
trunk/libgfortran/generated/minloc0_16_i4.c
trunk/libgfortran/generated/minloc0_16_i8.c
trunk/libgfortran/generated/minloc0_16_r10.c
trunk/libgfortran/generated/minloc0_16_r16.c
trunk/libgfortran/generated/minloc0_16_r4.c
trunk/libgfortran/generated/minloc0_16_r8.c
trunk/libgfortran/generated/minloc0_4_i1.c
trunk/libgfortran/generated/minloc0_4_i16.c
trunk/libgfortran/generated/minloc0_4_i2.c
trunk/libgfortran/generated/minloc0_4_i4.c
trunk/libgfortran/generated/minloc0_4_i8.c
trunk/libgfortran/generated/minloc0_4_r10.c
trunk/libgfortran/generated/minloc0_4_r16.c
trunk/libgfortran/generated/minloc0_4_r4.c
trunk/libgfortran/generated/minloc0_4_r8.c
trunk/libgfortran/generated/minloc0_8_i1.c
trunk/libgfortran/generated/minloc0_8_i16.c
trunk/libgfortran/generated/minloc0_8_i2.c
trunk/libgfortran/generated/minloc0_8_i4.c
trunk/libgfortran/generated/minloc0_8_i8.c
trunk/libgfortran/generated/minloc0_8_r10.c
trunk/libgfortran/generated/minloc0_8_r16.c
trunk/libgfortran/generated/minloc0_8_r4.c
trunk/libgfortran/generated/minloc0_8_r8.c
trunk/libgfortran/m4/minloc0.m4

[Bug libfortran/88807] misleading indentation warnings building libgfortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug libfortran/69788] FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Dominique d'Humieres  ---
Is this PR still valid?

I don't see any related failure in
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg00581.html.

[Bug middle-end/88703] oacc_validate_dims allows invalid dimensions

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Author: vries
Date: Sat Jan 12 10:27:12 2019
New Revision: 267877

URL: https://gcc.gnu.org/viewcvs?rev=267877&root=gcc&view=rev
Log:
[nvptx] Verify dimension limits after applying defaults

There's a problem in oacc_validate_dims that when f.i. the worker dimension
is set using -fopenacc-dim=:32, and the vector_length is set using a
"vector_length (128)" clause, the compiler combines, accepts and emits the
values, while the combination of the two is invalid.

The reason for this is that while oacc_validate_dims validates the dimensions
using targetm.goacc.validate_dims before applying default or minimum values,
it does not do so afterwards.

Work around this in the nvptx port by applying the defaults from
oacc_default_dims at the end of nvptx_goacc_validate_dims_1, as
oacc_validate_dims would do it, and then apply the dimensions limits.

2019-01-12  Tom de Vries  

PR middle-end/88703
* config/nvptx/nvptx.c (nvptx_goacc_validate_dims_1): Apply defaults
from oacc_default_dims, as oacc_validate_dims would do it, and apply
dimensions limits.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/nvptx/nvptx.c

[Bug c++/88815] [9 Regression] is_constexpr (based on narrowing conversion and expression SFINAE) broken

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-12
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r265789.

[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers

[drepper.fsp+rhbz at gmail dot com]

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

--- Comment #3 from Ulrich Drepper  ---
Created attachment 45416
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45416&action=edit
Add nodiscard support

As Martin suggested, we could indeed use existing attributes in library code to
warn about some of the problems.  The code from comment #0 is real, this
happened in a project of mine where I mistyped an assignment.  The warning
would have pointed to the problem.

How about the following patch for a start?  This compiles cleanly on x86-64.  I
haven't run the test suite to see whether it breaks some regression tests.

Also, this approach should be extended beyond shared_ptr and unique_ptr,
probably to at least every single bool operatorXX(...) const.  Or even every
single const member function which then of course raises the question whether
the compiler should learn about this…

[Bug bootstrap/88714] [9 regression] bootstrap comparison failure on armv7l since r265398

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
In armv7hl --enable-checking=release profiledbootstrap I see:
checking for strtoull... ../../libdecnumber/decNumber.c: In function 'decLnOp':
../../libdecnumber/decNumber.c:5581:13: error: number of counters in profile
data for function 'decLnOp' does not match its profile data (counter 'arcs',
expected 54 and have 55) [-Werror=coverage-mismatch]
 5581 | decNumber * decLnOp(decNumber *res, const decNumber *rhs,
  | ^~~
../../libdecnumber/decNumber.c:5581:13: error: the control flow of function
'decLnOp' does not match its profile data (counter 'time_profiler')
[-Werror=coverage-mismatch]
../../libdecnumber/decNumber.c: In function 'decExpOp':
../../libdecnumber/decNumber.c:5221:13: error: number of counters in profile
data for function 'decExpOp' does not match its profile data (counter 'arcs',
expected 52 and have 53) [-Werror=coverage-mismatch]
 5221 | decNumber * decExpOp(decNumber *res, const decNumber *rhs,
  | ^~~~
../../libdecnumber/decNumber.c:5221:13: error: the control flow of function
'decExpOp' does not match its profile data (counter 'time_profiler')
[-Werror=coverage-mismatch]
../../libdecnumber/decNumber.c: In function 'decMultiplyOp':
../../libdecnumber/decNumber.c:4831:20: error: number of counters in profile
data for function 'decMultiplyOp' does not match its profile data (counter
'arcs', expected 43 and have 46) [-Werror=coverage-mismatch]
 4831 | static decNumber * decMultiplyOp(decNumber *res, const decNumber *lhs,
  |^
../../libdecnumber/decNumber.c:4831:20: error: the control flow of function
'decMultiplyOp' does not match its profile data (counter 'time_profiler')
[-Werror=coverage-mismatch]
../../libdecnumber/decNumber.c: In function 'decDivideOp':
../../libdecnumber/decNumber.c:4211:20: error: number of counters in profile
data for function 'decDivideOp' does not match its profile data (counter
'arcs', expected 111 and have 113) [-Werror=coverage-mismatch]
 4211 | static decNumber * decDivideOp(decNumber *res,
  |^~~
../../libdecnumber/decNumber.c:4211:20: error: the control flow of function
'decDivideOp' does not match its profile data (counter 'single')
[-Werror=coverage-mismatch]
../../libdecnumber/decNumber.c:4211:20: error: the control flow of function
'decDivideOp' does not match its profile data (counter 'time_profiler')
[-Werror=coverage-mismatch]
../../libdecnumber/decNumber.c: In function 'decNumberSquareRoot':
../../libdecnumber/decNumber.c:2797:13: error: number of counters in profile
data for function 'decNumberSquareRoot' does not match its profile data
(counter 'arcs', expected 64 and have 65) [-Werror=coverage-mismatch]
 2797 | decNumber * decNumberSquareRoot(decNumber *res, const decNumber *rhs,
  | ^~~
../../libdecnumber/decNumber.c:2797:13: error: the control flow of function
'decNumberSquareRoot' does not match its profile data (counter 'time_profiler')
[-Werror=coverage-mismatch]
which might be related, if one stage generates starting with PRE slightly
different code from the other stage, then the profile mismatches would make a
lot of sense.

[Bug target/88808] bitwise operators on AVX512 masks fail to use the new mask instructions

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #1)
> See PR88473 and PR88798.  I'd personally probably revert the changes to make
> the mask operations separate from GPR operations and just use special RTL
> patterns if GPR operation can't do it (e.g. andn when not BMI, or 64-bit
> logicals on 32-bit targets), but it is too late for that for GCC9.

I'm not against the revert, [1] describes the rationale for the current
approach from 2016. In the meantime, a couple of new constraint modifiers were
introduced to better guide register allocation choices, and I believe that with
appropriate RTX costs, it is possible to implement mask operations without
UNSPECs.

I certainly agree with Jakub to postpone new implementation to gcc-10. Without
approporate cost model, we risk that under register pressure, RA will allocate
mask registers for values, expected to live in general registers. At the time,
it was warned that moves between mask and integer registers are quite costly,
so we took the safe way and by introducin UNSPECs, avoided runtime regressions
when mask registers were present.

[1] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02612.html

[Bug target/88808] bitwise operators on AVX512 masks fail to use the new mask instructions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-12
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Yeah, we probably need to better express in the constraint modifiers the cost
of moving a mask reg into integer reg or vice versa (and measure it).  Could
maybe somebody from Intel look into this during stage1 (or even before try to
implement  it now and benchmark and if it turns to be a win, propose for
stage1)?  Thanks.  I'm afraid I'll be busy again the whole stage1 with OpenMP
5.0.

[Bug target/88794] [9 Regression] fixupimm intrinsics are unusable

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug libgomp/87835] nvptx offloading: libgomp.oacc-c-c++-common/asyncwait-1.c execution test intermittently fails at -O2

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> (In reply to Thomas Schwinge from comment #0)
> > After r264397 "[nvptx] Remove use of CUDA unified memory in libgomp", I'm
> > seeing (intermittently only, and only on some systems):
> > 
> 
> I see the failure reproduced consistently with a Quadro M1200.
> 
> > I have not yet analyzed what's causing this, but I have some ideas about
> > pending patches that might cure it.
> 
> OK, let's see if those make it. If not, we may want to investigate and
> decide if we want to revert the patch.

Hi Thomas,

do you intend to address this before stage4 closes?

Thanks,
- Tom

[Bug middle-end/35587] -Warray-bounds does not work at all or does not find all trivial cases, and :works only with -O2 or -O3

[levon at movementarian dot org]

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

John Levon  changed:

   What|Removed |Added

 CC||levon at movementarian dot org

--- Comment #10 from John Levon  ---
This is such a pain because of -faggressive-loop-optimizations. Here's a
salient example courtesy of bcantrill:

#define NULL ((void *)0)

static char *arr[2] = { "nasal", "demons" };

long
func()
{
int i;

for (i = 0; i <= 2; i++) {
if (arr[i] == NULL && i == 0)
return (0xbad);
}

return (0xfad);
}

Obviously, the index past the array bounds is undefined behaviour, but GCC
compiling this down to just "return (0xbad)" as it does is not very helpful.
But what's *really* not helpful is that -Warray-bounds=2 can't report on this.

(As per #78678, --fsanitize=object-size does enable detection of this. I'm not
clear if implementation-wise that's the only way to get this reported.)

[Bug middle-end/35587] -Warray-bounds does not work at all or does not find all trivial cases, and :works only with -O2 or -O3

[levon at movementarian dot org]

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

--- Comment #11 from John Levon  ---
Ugh, and in fact, the sanitize option isn't even enough for the real-life code
that we hit this with.

[Bug c++/85577] list-initialization chooses initializer-list constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||isj-bugzilla at i1 dot dk

--- Comment #6 from Jonathan Wakely  ---
*** Bug 88816 has been marked as a duplicate of this bug. ***

[Bug c++/88816] Constructor calls itself recursively

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
See PR 85577 (and PR 86135).

Use parens instead of braces and it works:

new(&u.array_elements) array_type(a);

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

[Bug c++/88816] Constructor calls itself recursively

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> See PR 85577 (and PR 86135).
> 
> Use parens instead of braces and it works:
> 
> new(&u.array_elements) array_type(a);

Basically, if you're trying to call the array_type copy constructor then don't
use array_type{a} when array_type has an initializer-list constructor and a is
convertible to the value_type. If you use braces the compiler thinks you're
trying to do array_type{initializer_list{a}}, i.e. create a vector with
one element copied from a. It converts a to Value, which calls back into the
same constructor and recurses.

[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Ulrich Drepper from comment #3)
> Created attachment 45416 [details]
> Add nodiscard support
> 
> As Martin suggested, we could indeed use existing attributes in library code
> to warn about some of the problems.  The code from comment #0 is real, this
> happened in a project of mine where I mistyped an assignment.  The warning
> would have pointed to the problem.
> 
> How about the following patch for a start?  This compiles cleanly on x86-64.
> I haven't run the test suite to see whether it breaks some regression tests.

Please do, but it looks good in principle.

I'd feel comfortable adding this in stage 4 if it was only enabled for C++17
and up:

// Macro to warn about unused results.
#if __cplusplus >= 201703L
# define _GLIBCXX_NODISCARD [[__nodiscard__]]
#else
# define _GLIBCXX_NODISCARD
#endif

We could then enable it for C++98/C++11/C++14 during stage 1 if no problems
show up.

> Also, this approach should be extended beyond shared_ptr and unique_ptr,
> probably to at least every single bool operatorXX(...) const.  Or even every
> single const member function which then of course raises the question
> whether the compiler should learn about this…

Microsoft went quite aggressive adding [[nodiscard]] *everywhere* in their
library, and ended up backing some out again. There are some subtle cases (or,
depending on your point of view, users do silly things and complain about
getting warnings for their unreasonable code).

I do think Clang's warning in the compiler is better than having to decorate
everything explicitly.

[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
GCC6 is no longer supported, this PR should probably closed as FIXED.

[Bug target/88778] Odd Complex float load

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
Please take a look at

https://github.com/hjl-tools/gcc/commit/a56b4a49b2617a31365bdb9c44340695c31d56e8

[Bug libfortran/47149] failing build: execvp: /bin/sh: Argument list too long

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Dominique d'Humieres  ---
Is this still valid?

[Bug fortran/48776] ICE(segfault) after -std=f95 diagnostic error involving PROCEDURE

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> So this PR seems to be another instance of non-deterministic error recovery.

Yet another instance of

==2863==ERROR: AddressSanitizer: heap-use-after-free on address 0x61302588
at pc 0x0001004e9eab bp 0x7ffeefbfe690 sp 0x7ffeefbfe688
READ of size 8 at 0x61302588 thread T0
#0 0x1004e9eaa in gfc_sym_get_dummy_args(gfc_symbol*) symbol.c:5215
...

related to pr52622, pr84245, pr86657, and pr87908.

[Bug target/88778] Odd Complex float load

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
We need to update read_complex_part and write_complex_part to manipulate
SCmode with vector operations instead of 64-bit integers.

[Bug c/88817] New: Diagnostics improvement: Does not detect attempt to use void expression in some cases.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88817
   Summary: Diagnostics improvement: Does not detect attempt to
use void expression in some cases.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  extern void v;

  int main(void)
  {
_Generic(v, default: 0);
  } 

Compilation command line:

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

Observed behaviour:

  No error messages outputed.

Possible improvement:

  The program has undefined behaviour because it attempts to use the void
  expression  v  (as the controlling expression of _Generic).

  Since GCC detects attempts to use void expressions in other case it would be
  good if it detected it in this case also.

[Bug c++/88816] Constructor calls itself recursively

[isj-bugzilla at i1 dot dk]

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

--- Comment #3 from Ivan Skytte Jørgensen  ---
Ohhh...! Thank you for the explanation.

That was not at all obvious to me. It would be great if GCC detected it and
warned "brace-initializing a std:vector with a single std::vector may not do
what you think it does, depending on user-defined conversion constructors"

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||hjl.tools at gmail dot com,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I'd use just
struct S { short s; void *p; } __attribute__ ((__packed__));

int *
foo (struct S *x)
{
  return (int *) (x->p);
}
for both languages.

Despite quite many tests added in the -Waddress-of-packed-member commit, I
really don't see any testsuite coverage of the
  warning_at (location, OPT_Waddress_of_packed_member,
  "converting a packed %qT pointer (alignment %d) "
  "to %qT (alignment %d) may may result in an "
  "unaligned pointer value",
  rhstype, rhs_align, type, type_align);
warning (and note the "may may" bug in the wording there), is that covered by
anything?
As for the other path, it doesn't care whether address is taken or not:
  if (INDIRECT_REF_P (rhs))
rhs = TREE_OPERAND (rhs, 0);

  if (TREE_CODE (rhs) == ADDR_EXPR)
rhs = TREE_OPERAND (rhs, 0);
while it is significant.  We shouldn't warn if we are reading content from the
packed structure, but should warn if we are taking address (and for that needs
to take into account the array to pointer conversions, whether they happen
before or after this warning is reported).

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
H.J., can you please look into this?

Plus, I guess we need to reevaluate all the spots where
-Wno-address-of-packed-member has been added, whether we were warning there
correctly or not.

[Bug tree-optimization/88813] snprintf less optimal than sprintf for %s with big enough destination

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
To be safe, even though %s requires that the argument be a nul-terminated
string, the snprintf optimization would need to be predicated on knowing that
it, in fact, is one (to avoid buffer overflow if snprintf was called with a
non-string argument).  The optimization opportunity is in the length of the
source string not needing to be known.  When the source array is not guaranteed
to be a nul-terminated string then the memccpy optimization described in
pr88814 could take place instead.

So to clarify the example in comment #0, the array size optimization would only
be applicable if s was previously used as a string, such as in an argument to
some string function like in:

  char d[8];
  char s[8];
  char *p;

  void g (void)
  {
p = __builtin_strchr (s, '/');   // s must be a nul-terminated string
...
__builtin_snprintf (d, sizeof d, "%s", s);   // can be folded to strcpy
  }

[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
I can see how applying the attribute to every standard library function, even
const, might be excessive, but I wonder if it would make sense for the majority
of them, or at least for most equality and relational operators defined by the
library.  If it did we could have GCC apply it implicitly to all such functions
or operators defined in namespace std, and provide a new attribute to disable
it in the cases where it might not be appropriate (say no_warn_unused_result). 
We could also add a #pragma to control the scope where the attribute should or
should not be implicitly applied to such functions.  If you think this might be
a worthwhile approach to consider let's schedule it as an enhancement for GCC
10.

[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers

[drepper.fsp+rhbz at gmail dot com]

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

--- Comment #6 from Ulrich Drepper  ---
(In reply to Martin Sebor from comment #5)
> If it did we could have GCC apply it implicitly to
> all such functions or operators defined in namespace std, and provide a new
> attribute to disable it in the cases where it might not be appropriate (say
> no_warn_unused_result).

I looked at what clang does and it's very simplistic.  The code below produces
the output shows below.  I.e., they use the warning for all comparison
operators regardless of

- namespace
- return value
- member function or not
- const-ness of operators
- visible side effects

Nevertheless people use the compiler without complaining, at least visibly.

$ clang++ -c -O -Wall u.cc
u.cc:26:5: warning: equality comparison result unused [-Wunused-comparison]
  l == r;
  ~~^~~~
u.cc:26:5: note: use '=' to turn this equality comparison into an assignment
  l == r;
^~
=
u.cc:31:5: warning: inequality comparison result unused [-Wunused-comparison]
  l != r;
  ~~^~~~
u.cc:31:5: note: use '|=' to turn this inequality comparison into an
or-assignment
  l != r;
^~
|=
u.cc:36:5: warning: relational comparison result unused [-Wunused-comparison]
  l <= r;
  ~~^~~~
u.cc:41:5: warning: relational comparison result unused [-Wunused-comparison]
  l >= r;
  ~~^~~~
u.cc:46:5: warning: relational comparison result unused [-Wunused-comparison]
  l < r;
  ~~^~~
5 warnings generated.



~~
struct foo {
  int a;
  foo(int) : a(42) {}
  auto operator==(const foo& o) const { return a == o.a; }
  auto operator!=(foo& o) { return a == o.a; }
};

auto operator<=(const foo& l, const foo& r)
{
  return l.a == r.a;
}

auto operator>=(foo& l, foo& r)
{
  l.a |= 1;
  return l.a == r.a;
}

int operator<(foo& l, foo& r)
{
  return l.a == r.a ? 0 : l.a < r.a ? -1 : 1;
}

auto f1(foo& l, foo& r)
{
  l == r;
}

auto f2(foo& l, foo& r)
{
  l != r;
}

auto f3(foo& l, foo& r)
{
  l <= r;
}

auto f4(foo& l, foo& r)
{
  l >= r;
}

auto f5(foo& l, foo& r)
{
  l < r;
}

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #3)
> Created attachment 45407 [details]
> Self-contained testcase
> 
> I've been able to produce a self-contained testcase, which may aid
> debugging.
> 
> While reducing further, I got the impression that it is just a subtle
> whitespace issue.

I have looked a little closer at this. 

There are a few places where reading is handled differently if the unit is
stdin_unit. For example in list_read.c near line 3614 we have:

  while (!dtp->u.p.input_complete)
{
  if (!nml_get_obj_data (dtp, &prev_nl, nml_err_msg, sizeof nml_err_msg))
{
  printf ("ping: %d, %d\n", dtp->u.p.current_unit->unit_number,
options.stdin_unit);
  if (dtp->u.p.current_unit->unit_number != options.stdin_unit)
goto nml_err_ret;
  printf("pong\n");
  generate_error (&dtp->common, LIBERROR_READ_VALUE, nml_err_msg);
}

Where I have instrumented this a little and running a slightly modified test
case, we take two different error paths. This results in:

$ ./a.out 
 Calling on unit 10:
ping: 10, 5
 Calling on unit 5:
ping: 5, 5
pong
 ichan not 2,unit=   5
STOP 3

goto nml_err_ret above is a more graceful return:

nml_err_ret:

  /* All namelist error calls return from here */
  free_saved (dtp);
  free_line (dtp);
  generate_error (&dtp->common, LIBERROR_READ_VALUE, nml_err_msg);
  return;

Putting a return after the error in the block at 3614 seems to fix it.

  if (!nml_get_obj_data (dtp, &prev_nl, nml_err_msg, sizeof nml_err_msg))
{
  //printf ("ping: %d, %d\n", dtp->u.p.current_unit->unit_number,
options.stdin_unit);
  if (dtp->u.p.current_unit->unit_number != options.stdin_unit)
goto nml_err_ret;
  //printf("pong\n");
  generate_error (&dtp->common, LIBERROR_READ_VALUE, nml_err_msg);
  return;
}

With the printf's commented out:

$ ./a.out 
 Calling on unit 10:
 Calling on unit 5:

I have not regression tested this and will report back.

[Bug libfortran/69788] FAIL: gfortran.dg/derived_constructor_comps_6.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #8 from John David Anglin  ---
Don't see failure on hppa2.0w-hp-hpux11.11 in gcc-7 and later.

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
So far this patch seems to test OK.

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 4a7ccb3ddd5..d9af255a034 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -3614,11 +3614,7 @@ find_nml_name:
   while (!dtp->u.p.input_complete)
 {
   if (!nml_get_obj_data (dtp, &prev_nl, nml_err_msg, sizeof nml_err_msg))
-   {
- if (dtp->u.p.current_unit->unit_number != options.stdin_unit)
-   goto nml_err_ret;
- generate_error (&dtp->common, LIBERROR_READ_VALUE, nml_err_msg);
-}
+   goto nml_err_ret;

   /* Reset the previous namelist pointer if we know we are not going
 to be doing multiple reads within a single namelist object.  */

All our current namelist tests pass. We shoud check this against an actual
redirection to stdin which we do not do in our testsuite, but I cannot think of
a reason why it would not be OK. (ie cat file | ./a.out )

[Bug target/85486] [og7, nvptx] ref-1.C fails with vector length 128

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
Author: vries
Date: Sat Jan 12 22:18:50 2019
New Revision: 267894

URL: https://gcc.gnu.org/viewcvs?rev=267894&root=gcc&view=rev
Log:
[nvptx] Force vl32 if calling vector-partitionable routines -- test-cases

Add test-cases for "[nvptx] Force vl32 if calling vector-partitionable
routines".

2019-01-12  Tom de Vries  

PR target/85486
* testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: New test.
* testsuite/libgomp.oacc-c-c++-common/pr85486.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85486-3.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85486.c
Modified:
trunk/libgomp/ChangeLog

[Bug target/85381] [og7, nvptx, openacc] parallel-loop-1.c fails with default vector length 128

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Author: vries
Date: Sat Jan 12 22:18:39 2019
New Revision: 267893

URL: https://gcc.gnu.org/viewcvs?rev=267893&root=gcc&view=rev
Log:
[nvptx] Don't emit barriers for empty loops -- test-cases

Add test-cases for PR85381.

2019-01-12  Tom de Vries  

PR target/85381
* testsuite/libgomp.oacc-c-c++-common/pr85381-5.c: New test.
* testsuite/libgomp.oacc-c-c++-common/pr85381.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-5.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381.c
Modified:
trunk/libgomp/ChangeLog

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Jan 12 23:06:47 2019
New Revision: 267898

URL: https://gcc.gnu.org/viewcvs?rev=267898&root=gcc&view=rev
Log:
2019-01-12  Jerry DeLisle  

PR libfortran/88776
* io/list_read.c (namelist_read): Use nml_err_ret path on read error
not based on stdin_unit.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug c/88817] Diagnostics improvement: Does not detect attempt to use void expression in some cases.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The controlling expression of a _Generic selection is not evaluated so I don't
see any undefined behavior in the test case, or any more justification for a
diagnostic.

[Bug c/88737] RFE: Track ownership moves

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #2)
> Wouldn't that break e.g. programs that
>   free (a);
>   return (uintptr_t) a % 16;
> or similar (i.e. inspect the bits of the pointer rather than what it points
> to)?
> That should be valid even after free, free doesn't modify the pointer, only
> says that what it points to is no longer available.

Strictly speaking (as described in bug 80532), the value of a pointer becomes
indeterminate after the lifetime of the object it points to ends.  This goes
for all memory: stack as well as the heap.  So the idea of clobbering the
pointer is sound, though it would certainly break code that uses the
indeterminate pointer anyway, such as after realloc.  But I agree that a
warning would be quite helpful here to help find such bad code.

I'm not sure I understand the purpose of the requested attribute or how it
might be used or where.

[Bug c++/88736] nullptr_t available without namespace qualification

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I agree.   defines C library names in both namespace std and the
global namespace but C++ library names only in std.  For some reason, GCC's
 defines nullptr_t in the global namespace (and libstdc++ 
in std).

[Bug c/88704] Accepts invalid program with [*] outside function prototype scope.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Confirmed, although I'd be more inclined to invest energy into including
-Wstrict-prototypes in -Wall or -Wextra than into diagnosing the VLA in
K&R-style definitions.

[Bug c/88700] C11 Annex K builtins

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Without Glibc support, adding the built-ins to GCC isn't realistic so I'm going
to resolve this request as Won't Fix.

[Bug target/88682] new test case c-c++-common/pr51628-10.c fails starting with its introduction in r267313

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Confirmed based on the latest test results for both targets:
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg01230.html
https://gcc.gnu.org/ml/gcc-testresults/2019-01/msg01245.html

[Bug c/88662] Document trap representations of _Bool

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
(In reply to gnzlbg from comment #2)
> > Because (unsigned int)b is undefined otherwise.
> 
> AFAICT this is only undefined behavior iff `b` has a trap representation.

Not necessarily.  It's undefined if b's value is indeterminate, whether or not
it's a trap representation, or whether or not b's type even has a trap
representation.  See C Defect Report 451 for some background:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_451.htm
I don't think copying arbitrary bits into an object changes that, unless those
bits come from an initialized object of the same type in the same program
execution.

That said, there has been a lot of confusion about padding bits and trap
representations so I'm not completely unsympathetic to the request, even
though, as Jonathan says, thos aspects of types are unspecified.  But rather
than documenting which bits are padding bits I think it should be sufficient to
either mention which types have padding bits, or expose some additional Common
Predefined Macros to make it possible to determine which ones do (and perhaps
even compute how many).

[Bug c++/88818] New: Segfault with vtable-verify LTO optimization

[jagapeyev at gmail dot com]

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

Bug ID: 88818
   Summary: Segfault with vtable-verify LTO optimization
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jagapeyev at gmail dot com
  Target Milestone: ---

struct a {
  virtual int b();
};
void c() {}

Compiling the above program with:
g++ -c test.cpp -O1 -flto -fvtable-verify=preinit

Results in the following error:
during GIMPLE pass: ealias
test.cpp: In function ‘_GLOBAL__sub_I.00099__Z1cv’:
test.cpp:4:11: internal compiler error: Segmentation fault
 void c() {}
   ^

Attached is the full gcc -v -save-temps output.

>From preliminary tests, -fvtable-verify=std vs -fvtable-verify=preinit makes no
difference.
Error does not exist with -O0 or -Og, but does exist at -O1 and higher.

[Bug c++/88818] Segfault with vtable-verify LTO optimization

[jagapeyev at gmail dot com]

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

John Agapeyev  changed:

   What|Removed |Added

 CC||jagapeyev at gmail dot com

--- Comment #1 from John Agapeyev  ---
GCC -v -save-temps output

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-O1' '-flto'
'-fvtable-verify=std' '-o' 'test.o' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE
test2.cpp -mtune=generic -march=x86-64 -std=c++17 -flto -fvtable-verify=std -O1
-fpch-preprocess -o test2.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1

/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++17' '-O1' '-flto'
'-fvtable-verify=std' '-o' 'test.o' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -fpreprocessed test2.ii -quiet
-dumpbase test2.cpp -mtune=generic -march=x86-64 -auxbase-strip test.o -O1
-std=c++17 -version -flto -fvtable-verify=std -o test2.s
GNU C++17 (GCC) version 8.2.1 20181127 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20181127, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 8.2.1 20181127 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20181127, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c228073cd86637479fc341ff509ca7e7
test2.cpp: In destructor ‘std::basic_ostream<_CharT,
_Traits>::sentry::~sentry()’:
test2.cpp:51414:69: warning: ‘bool std::uncaught_exception()’ is deprecated
[-Wdeprecated-declarations]
  if (bool(_M_os.flags() & ios_base::unitbuf) && !uncaught_exception())
 ^
test2.cpp:3994:8: note: declared here
   bool uncaught_exception() noexcept __attribute__ ((__pure__));
^~
during GIMPLE pass: ealias
test2.cpp: In function ‘_GLOBAL__sub_I.00099__ZN6crypto10DH_KeypairC2Ev’:
test2.cpp:60623:1: internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/88818] Segfault with vtable-verify LTO optimization

[jagapeyev at gmail dot com]

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

--- Comment #2 from John Agapeyev  ---
Ignore first comment, output was from older test file.

GCC -v output:


Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-O1' '-flto' '-fvtable-verify=preinit'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test
-O1 -version -flto -fvtable-verify=preinit -o /tmp/ccGxPiUI.s
GNU C++14 (GCC) version 8.2.1 20181127 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20181127, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1

/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../include/c++/8.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 8.2.1 20181127 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.1 20181127, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: c228073cd86637479fc341ff509ca7e7
during GIMPLE pass: ealias
test.cpp: In function ‘_GLOBAL__sub_I.00099__Z1cv’:
test.cpp:4:11: internal compiler error: Segmentation fault
 void c() {}
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

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

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #3)
> I'd use just
> struct S { short s; void *p; } __attribute__ ((__packed__));
> 
> int *
> foo (struct S *x)
> {
>   return (int *) (x->p);
> }
> for both languages.
> 
> Despite quite many tests added in the -Waddress-of-packed-member commit, I
> really don't see any testsuite coverage of the
>   warning_at (location, OPT_Waddress_of_packed_member,
>   "converting a packed %qT pointer (alignment %d) "
>   "to %qT (alignment %d) may may result in an "
>   "unaligned pointer value",
>   rhstype, rhs_align, type, type_align);
> warning (and note the "may may" bug in the wording there), is that covered
> by anything?

This is covered by gcc.dg/pr51628-20.c, gcc.dg/pr51628-21.c and
gcc.dg/pr51628-25.c.

> As for the other path, it doesn't care whether address is taken or not:
>   if (INDIRECT_REF_P (rhs))
> rhs = TREE_OPERAND (rhs, 0);
>   
>   if (TREE_CODE (rhs) == ADDR_EXPR)
> rhs = TREE_OPERAND (rhs, 0);
> while it is significant.  We shouldn't warn if we are reading content from
> the packed structure, but should warn if we are taking address (and for that
> needs to take into account the array to pointer conversions, whether they
> happen before or after this warning is reported).

I am testing:

diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index 79b2d8ad449..c937c016889 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -2752,9 +2752,15 @@ check_and_warn_address_of_packed_member (tree type, tree
rhs)
 {
   if (TREE_CODE (rhs) != COND_EXPR)
 {
+  if (TREE_CODE (rhs) == NOP_EXPR)
+  rhs = TREE_OPERAND (rhs, 0);
+
   while (TREE_CODE (rhs) == COMPOUND_EXPR)
   rhs = TREE_OPERAND (rhs, 1);

+  if (TREE_CODE (rhs) != ADDR_EXPR)
+  return;
+
   tree context = check_address_of_packed_member (type, rhs);
   if (context)
   {
(

[Bug fortran/61765] [7/8/9 Regression] [F03] Rejects valid BIND(C) ENTRY

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Jan 13 04:02:46 2019
New Revision: 267902

URL: https://gcc.gnu.org/viewcvs?rev=267902&root=gcc&view=rev
Log:
2019-01-12  Steven G. Kargl  

PR fortran/61765
* resolve.c (gfc_verify_binding_labels): Break if-elseif-elseif
structure into independent if's with a return to simplify logic.
Avoid a check for ENTRY name with bind(c).

2019-01-12  Steven G. Kargl  

PR fortran/61765
* gfortran.dg/pr61765.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr61765.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/61765] [7/8/9 Regression] [F03] Rejects valid BIND(C) ENTRY

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

[Bug fortran/32630] [meta-bug] ISO C binding

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630
Bug 32630 depends on bug 61765, which changed state.

Bug 61765 Summary: [7/8/9 Regression] [F03] Rejects valid BIND(C) ENTRY
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61765

   What|Removed |Added

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

[Bug c/51628] __attribute__((packed)) is unsafe in some cases (i.e. add -Waddress-of-packed-member, etc.)

[hjl.tools at gmail dot com]

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

--- Comment #59 from H.J. Lu  ---
A missing warning:

[hjl@gnu-cfl-1 pr51628-7]$ cat pr51628-33.c
struct pair_t
{
  char x;
  int i[4];
} __attribute__ ((packed, aligned (4)));

extern struct pair_t p;
extern void bar (int *);

void
foo (struct pair_t *p)
{
  bar (p ? p->i : (int *) 0);
}
[hjl@gnu-cfl-1 pr51628-7]$
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/ -O2 -S
pr51628-33.c
[hjl@gnu-cfl-1 pr51628-7]$

[Bug c++/84849] Ambiguous resolution of braze initializer list to a class with explicit constructors

[lichray at gmail dot com]

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

Zhihao Yuan  changed:

   What|Removed |Added

 CC||lichray at gmail dot com

--- Comment #6 from Zhihao Yuan  ---
Here is a possibly related case:

#include 

template 
struct pair
{
using value_type = pair>;

T a, b;

constexpr pair& operator=(value_type const& other)
{
a = other.a;
b = other.b;
return *this;
}

constexpr pair& operator=(value_type&& other)
{
a = std::move(other.a);
b = std::move(other.b);
return *this;
}
};

template 
constexpr pair tie(T& a, T& b) noexcept
{
return { a, b };
}

int main()
{
int a = 3;
int b = 5;
tie(a, b) = { b, a % b };  // works
tie(a, b) = { b, a };  // wat
}

Error messages are very similar https://godbolt.org/z/4FSeOO.

[Bug c/88704] Accepts invalid program with [*] outside function prototype scope.

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
(In reply to Martin Sebor from comment #2)
> Confirmed, although I'd be more inclined to invest energy into including
> -Wstrict-prototypes in -Wall or -Wextra than into diagnosing the VLA in
> K&R-style definitions.

Yeah, probably not worth fixing since K&R-style function definitions is an
obsolencent feature.

[Bug c/88731] [DR 481] Rejects well-formed program using bit-fields in _Generic.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #3 from Anders Granlund  ---
(In reply to jos...@codesourcery.com from comment #2)
> GCC makes the integer type of the bit-field in question "unsigned:4".  
> See DR#315 (also, see the line of C90 DRs that led to the wording changes 
> in C99 relating to types of bit-fields, references in 
> ).

Thanks for the explanation.