[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Patch posted here:

https://gcc.gnu.org/ml/fortran/2017-12/msg00089.html

[Bug target/83585] New: [8 Regression] Assembler messages: Error: can't resolve `.text' {.text section} - `.LCOLDB0' {.text.unlikely section}

[asolokha at gmx dot com]

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

Bug ID: 83585
   Summary: [8 Regression] Assembler messages: Error: can't
resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: assemble-failure
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gas 2.29.1 rejects the code generated by gcc-8.0.0-alpha20171217 snapshot
(r255766) w/ -O2 (-O3, -Ofast) -g -fno-tree-dce -fno-guess-branch-probability
for the following snippet:

int
j3 (int tz)
{
  int wy;

  for (wy = 0; wy < 2; ++wy)
if (tz != 0)
  {
int yd;

for (yd = 0; yd < 2; ++yd)
  {
  }

return 0;
  }

  return;
}

% x86_64-pc-linux-gnu-gcc-8.0.0-alpha20171224 -O2 -g -fno-tree-dce
-fno-guess-branch-probability -w -c ixdsdxfe.c
/tmp/ccWUPZAP.s: Assembler messages:
/tmp/ccWUPZAP.s:215: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:216: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:220: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:221: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:228: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}
/tmp/ccWUPZAP.s:229: Error: can't resolve `.text' {.text section} - `.LCOLDB0'
{.text.unlikely section}

[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Likely a duplicate of PR80463.

[Bug other/83520] format string bug in libvtv

[charo.ctf at gmail dot com]

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

--- Comment #3 from Touma Hatano  ---
Sorry for misleading.
My point was that if we can replace
  snprintf (program_name, sizeof (program_name), program_invocation_name);
with
  snprintf (program_name, sizeof (program_name), "%s",
program_invocation_name);
, the program won't crash when program_invocation_name contains format
specifiers.

How do you think?

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[Keith.S.Thompson at gmail dot com]

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

--- Comment #4 from Keith Thompson  ---
I'm aware that the standard has not changed in this area from C90 to C99
to C11.  The conversion is undefined behavior, not a constraint violation,
in all three editions.

If the conversion is forbidden, what syntax rule or constraint does
it violate?

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Actually there is a common extension mentioned in N1570 about this case.

J.5.7 [Function pointer casts]

 1   A pointer to an object or to void may be cast to a pointer to a function,
allowing data to
be invoked as a function (6.5.4).
 2   A pointer to a function may be cast to a pointer to an object or to void,
allowing a
function to be inspected or modified (for example, by a debugger) (6.5.4).



- CUT 
This is not about undefined behavior being commonly defined either.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Your reading of the spec is different than the GCC folks read it.
See PR 11234 which requested the error in the first place.  Note C11 and
C89/C90 has not changed in this area as far as I can tell.

[Bug c/83584] "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[Keith.S.Thompson at gmail dot com]

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

--- Comment #1 from Keith Thompson  ---
Tested on x86_64 Ubuntu 17.04, gcc 7.1.0 built from source

[Bug c/83584] New: "ISO C forbids conversion of object pointer to function pointer type" -- no, not really

[Keith.S.Thompson at gmail dot com]

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

Bug ID: 83584
   Summary: "ISO C forbids conversion of object pointer to
function pointer type" -- no, not really
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com
  Target Milestone: ---

$ gcc --version
gcc (GCC) 7.1.0
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.

$ cat c.c
int main(void) {
typedef void (func)(void);
void *ptr = 0;
func *fptr = (func*)ptr;
}
$ gcc -std=c11 -pedantic-errors -c c.c
c.c: In function ‘main’:
c.c:4:18: error: ISO C forbids conversion of object pointer to function pointer
type [-Wpedantic]
 func *fptr = (func*)ptr;
  ^
$ 

In fact the conversion does not violate any syntax rule or constraint,
though its behavior is undefined.

N1570 6.5.4 p2-4 specifies the constraints on the cast operator. It
permits conversions between scalar types (which include pointer types). p4
specifically forbids conversions between pointer types and floating-point
types. There's nothing about pointer-to-function types.

6.3.2.3 defines the semantics of pointer conversions. It says nothing
about conversions between void* and pointer-to-function types -- which
means the behavior is undefined by omission.

The diagnostic should be a non-fatal warning when "-pedantic-errors"
is used, and it should be rephrased.

[Bug c++/83533] error: no type named 'X' in 'using = ...'

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
This was a bug in GCC 4.7.x which is fixed in GCC 4.8.0

We already fixed it, and do not support GCC 4.7 (or anything older than GCC 6),
so there's nothing more we can do. Either use the workaround or use a newer
version of GCC.

[Bug libstdc++/83237] Values returned by std::poisson_distribution are not distributed correctly

[paolo at gcc dot gnu.org]

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

--- Comment #5 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Sun Dec 24 22:08:52 2017
New Revision: 255993

URL: https://gcc.gnu.org/viewcvs?rev=255993=gcc=rev
Log:
2017-12-24  Michele Pezzutti 

PR libstdc++/83237
* include/bits/random.tcc (poisson_distribution<>::operator()):
Fix __x = 1 case - see updated Errata of Devroye's treatise.
* testsuite/26_numerics/random/poisson_distribution/operators/
values.cc: Add test.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.tcc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/poisson_distribution/operators/values.cc
trunk/libstdc++-v3/testsuite/26_numerics/random/pr60037-neg.cc

[Bug tree-optimization/83581] [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-linux-gnu
  Component|rtl-optimization|tree-optimization
   Target Milestone|--- |8.0

[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Most likely because the requirement that two different lambdas need not to
compare equal.

[Bug ipa/83582] GCC is unable to fold the code of identical lambda-expressions

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Case 1:
#include 
int main()
{
int arr[8];
auto sort = [] (auto x, auto y) { return false; };
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
std::sort(arr, arr + 8, sort);
}

Case 2:
#include 
int main()
{
int arr[8];

std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
std::sort(arr, arr + 8, [] (auto x, auto y) { return false; });
}

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[wilson at gcc dot gnu.org]

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

--- Comment #20 from Jim Wilson  ---
I don't see the distinction here.  Ia64 has instructions that operate on 32-bit
values too, like cmp4.

On sparc, given this testcase
int
sub (int i, int j, int k)
{
  return i + j + k;
}
the compiler generates
sub:
add %o0, %o1, %o0
add %o0, %o2, %o0
jmp %o7+8
 sra%o0, 0, %o0
Note that the add instruction operates on the entire 64-bit register, and after
the first add, we no longer have a valid 32-bit value, because there might have
been an overflow.  This is why we need the sra at the end to sign-extend the
return value, because we know that the upper 32-bits are don't care bits.

If you take a paradoxical subreg of a SImode reg after an add instruction, you
can't make any assumptions about the upper 32-bits of the value in the
register.  Exactly the same as ia64.

I do see that the fact that sparc has 32-bit shift instructions defined means
the testcase that fails on ia64 will not fail on sparc.  But if we rely on that
for the WORD_REGISTER_OPERATIONS definition, then it gets even messier than it
already is.

If nonzero_bits1 isn't changed, then we may need to remove the
WORD_REGISTER_OPERATIONS definition in the ia64 port.  Unfortunately, I don't
have access to ia64 hardware, so I can't easily check to see what will happen
if this is done.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[jrtc27 at jrtc27 dot com]

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

--- Comment #19 from James Clarke  ---
(In reply to Jim Wilson from comment #16)
> That referred patch was written by Eric Botcazou for PR59461 which is for
> SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value
> in a 64-bit reg are undefined.  So it does not appear to be correct for
> SPARC either.  Hence it appears that we need the same change for SPARC, and
> that breaks the fix for PR59461.  I think we need to revisit that.  If you
> have a paradoxical subreg of a reg, then it is only OK to use LOAD_EXTEND_OP
> if you know the value in the reg came from a memory location.  This check is
> missing.
> 
> If we are going to change the meaning of WORD_REGISTER_OPERATIONS, then we
> need a change to the docs also.  But I'm not convinced that this needs to
> change.

The difference is that SPARC has instructions to operate on 32-bit values in
the 64-bit registers, like many other RISC architectures, including for things
like shifts.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[wilson at gcc dot gnu.org]

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

--- Comment #18 from Jim Wilson  ---
SPARC defines WORD_REGISTER_OPERATIONS, and works the same as ia64.  The upper
bits of a 64-bit register after a 32-bit operation are don't care bits.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[jrtc27 at jrtc27 dot com]

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

--- Comment #17 from James Clarke  ---
(In reply to Eric Botcazou from comment #15)
> > Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS
> > should still be true on ia64 given the description in the documentation.
> 
> I disagree, WORD_REGISTER_OPERATIONS means that the (general) registers are
> always modified as a whole by arithmetic operations.  If that isn't the
> case, then the macro should not be defined (e.g Aarch64 doesn't define it
> although ARM does).

Ok, fair enough, the docs are all I have to go on, as opposed to your existing
knowledge of the codebase.

> > This regression was introduced in r242326, which added the `&& !REG_P
> > (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were
> > defined, which is a target-specific assumption.
> 
> No, see above, WORD_REGISTER_OPERATIONS means that the bits are defined.

Well, yes and no, then. The regression on ia64 *was* introduced then, but only
because of what you believe to be the existing incorrect use of
WORD_REGISTER_OPERATIONS. I doubt there's much more I can contribute to this
bug myself as I lack the knowledge of what is meant to happen deep inside GCC,
but certainly I can confirm that the issue is with nonzero_bits returning only
the lower 32 bits due to that if condition.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[wilson at gcc dot gnu.org]

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

--- Comment #16 from Jim Wilson  ---
That referred patch was written by Eric Botcazou for PR59461 which is for
SPARC, which operates same as Itanium, the upper 32-bits of a 32-bit value in a
64-bit reg are undefined.  So it does not appear to be correct for SPARC
either.  Hence it appears that we need the same change for SPARC, and that
breaks the fix for PR59461.  I think we need to revisit that.  If you have a
paradoxical subreg of a reg, then it is only OK to use LOAD_EXTEND_OP if you
know the value in the reg came from a memory location.  This check is missing.

If we are going to change the meaning of WORD_REGISTER_OPERATIONS, then we need
a change to the docs also.  But I'm not convinced that this needs to change.

[Bug c++/83583] New: ICE in synthesize_implicit_template_parm, at cp/parser.c:38794

[wouter at voti dot nl]

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

Bug ID: 83583
   Summary: ICE in synthesize_implicit_template_parm, at
cp/parser.c:38794
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wouter at voti dot nl
  Target Milestone: ---

The compiler ICE's on this construct. There are some simular bug reports which
might be the same problem or a related one, but they report a different
parser.c line.

using  arm-eabi-gcc (GCC) 7.2.0 -fconcepts

code:

template< typename T > 
concept bool has_main = requires {
   { T::main() } -> void;   
};  

template< typename T >
concept bool is_duration_with_polling = requires (
   has_main m
){ 
   { template callback< m >::init() } -> void
};

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[ebotcazou at gcc dot gnu.org]

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

--- Comment #15 from Eric Botcazou  ---
> Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS
> should still be true on ia64 given the description in the documentation.

I disagree, WORD_REGISTER_OPERATIONS means that the (general) registers are
always modified as a whole by arithmetic operations.  If that isn't the case,
then the macro should not be defined (e.g Aarch64 doesn't define it although
ARM does).

> This regression was introduced in r242326, which added the `&& !REG_P
> (SUBREG_REG (x))` to nonzero_bits1, thereby assuming that the high bits were
> defined, which is a target-specific assumption.

No, see above, WORD_REGISTER_OPERATIONS means that the bits are defined.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[segher at gcc dot gnu.org]

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to Jim Wilson from comment #11)

> This part
> 
> >r358 is known to have the high half zero:
> >   22: r358:DI=r357:SI#0^r341:SI#0
> 
> is wrong.  The upper bits of both registers are unknown bits, and xor of
> unknown bits does not return zero.

Yup, I don't know what I was thinking.

> I think the problem is in nonzero_bits1 in rtlanal.c, in the SUBREG case. 
> On ia64, we have WORD_REGISTER_OPERATIONS true, and load_extend_op of SImode
> is ZERO_EXTEND, so the code decides that the upper bits must be zero.  But
> LOAD_EXTEND_OP only applies to memory operations, and we do not have a
> subreg of memory here, we have a subreg of a register.

Right, that should be changed, that makes no sense at all.

Will that fix the problem here?

> When we have a
> subreg of a reg, on itanium, the upper bits are unknown.  So the
> optimization performed here is wrong.  Though one could perhaps argue that
> the ia64 port is using WORD_REGISTER_OPERATIONS wrong I suppose.

WORD_REGISTER_OPERATIONS isn't well-defined.

"""
@defmac WORD_REGISTER_OPERATIONS
Define this macro to 1 if operations between registers with integral mode
smaller than a word are always performed on the entire register.
Most RISC machines have this property and most CISC machines do not.
"""

What operations?  For some operations it can never be true (rotates, shifts,
all slightly more complex operations).  For machines that have explicit
operations in more than one size it cannot be true, either.

> I'm not sure what would happen if we removed that define.

When I removed WORD_REGISTER_OPERATIONS from the rs6000 backend a few things
regressed, but more things improved.

[Bug rtl-optimization/83565] RTL combine pass breaks shift result (at least on ia64)

[jrtc27 at jrtc27 dot com]

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

James Clarke  changed:

   What|Removed |Added

  Attachment #42961|0   |1
is obsolete||

--- Comment #13 from James Clarke  ---
Created attachment 42963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42963=edit
Higher bits of paradoxical subregs on ia64 are undefined

Thanks Jim, that makes sense. It seems to me that WORD_REGISTER_OPERATIONS
should still be true on ia64 given the description in the documentation. This
regression was introduced in r242326, which added the `&& !REG_P (SUBREG_REG
(x))` to nonzero_bits1, thereby assuming that the high bits were defined, which
is a target-specific assumption. The attached patch therefore encodes this
assumption in whether WORD_REGISTER_OPERATIONS is positive or negative; I
haven't modified any documentation as there's no point doing that if people
disagree with this approach.

[Bug ipa/83582] New: GCC is unable to fold the code of identical lambda-expressions

[jeanmichael.celerier at gmail dot com]

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

Bug ID: 83582
   Summary: GCC is unable to fold the code of identical
lambda-expressions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Case 1: https://godbolt.org/g/JvmxJr

Case 2: https://godbolt.org/g/FWo12z


It seems that the compiler should be able to pick up lambda functions with the
same implementation, at least in a given translation unit.

[Bug fortran/83560] list-directed formatting of INTEGER is missing plus on output when output open with SIGN='PLUS'

[urbanjost at comcast dot net]

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

--- Comment #6 from urbanjost at comcast dot net ---
Thanks! As always, I am astonished at what has been accomplished. Fortran's 
viability itself depends so much on the availability of an open compiler.

[Bug c++/83533] error: no type named 'X' in 'using = ...'

[povelikin.rostislav at gmail dot com]

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

--- Comment #3 from Rostislav Povelikin  
---
(In reply to Jonathan Wakely from comment #2)
> GCC 4.7.x has not been maintained or supported by the upstream GCC project
> for several years, and this is already fixed in GCC 4.8.0

Hi Jonathan,

Could you explain the nature of such bug? How to name it correctly?
The bug wasn't reproduced by myself on Fedora 23,24,25 with the same compiler
version.
Is it related to Debian?

Thanks

[Bug fortran/83567] Parametrized derived types: Segmentation fault when assigning a function return value

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
Created attachment 42962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42962=edit
A partial fix for the PR

The attached patch clears the ICE and yields the correct result. However, there
is still a memory leak because the automatically allocated parameterized
component 'foo' of 'w' is not freed before the call to addw.

I'll complete the fix, as soon as my tree is cleared of the fix for another PR
that I am working on.

Cheers

Paul

[Bug fortran/83567] Parametrized derived types: Segmentation fault when assigning a function return value

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-24
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Confirmed. Many thanks for the report.

The tree dump of addw shows what the problem is:

addvv (struct Pdtvec & restrict a, struct Pdtvec & restrict b)
{
  integer(kind=8) D.3776;
  void * restrict D.3777;
  struct Pdtvec c;

  try
{
  c.k = 3;
  c.k = a->k;
  c.foo.dim[0].lbound = 1;
  c.foo.dim[0].ubound = (integer(kind=8)) a->k;
  c.foo.dim[0].stride = 1;
  c.foo.offset = -1;
  D.3776 = (integer(kind=8)) a->k * 4;
  D.3777 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.3776, 1>);
  c.foo.data = D.3777;
  c.foo.dtype = 265;
  {
...snip...
  }
  return c;
}
  finally
{
  if ((integer(kind=4)[0:] * restrict) c.foo.data != 0B)
{
  __builtin_free ((void *) c.foo.data);
}
  c.foo.data = 0B;
}
}

c%foo is being initialized correctly but is being freed on exit from the
function.

I will post the fix as soon as the regression testing is complete.

Paul

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #12)
> No, the warning is gone from all releases that are still maintained.

Looks like this wasn't true.

[Bug rtl-optimization/83581] New: [8 Regression] ICE in expand_LOOP_VECTORIZED, at internal-fn.c:2397

[asolokha at gmx dot com]

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

Bug ID: 83581
   Summary: [8 Regression] ICE in expand_LOOP_VECTORIZED, at
internal-fn.c:2397
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-8.0.0-alpha20171217 snapshot (r255766) ICEs when compiling the following
snippet w/ -O3 (-Ofast)  -fno-tree-copy-prop -fno-tree-loop-im:

int ag, mv, v7;

int
nk (int g1)
{
  int *yw = 

  while (ag < 1)
{
  for (mv = 0; mv < 2; ++mv)
{
  *yw += !!g1 + 1;
  yw = 
}

  ++ag;
}

  return *yw;
}

% gcc-8.0.0-alpha20171217 -O3 -fno-tree-copy-prop -fno-tree-loop-im -c
ybdz3a46.c 
during RTL pass: expand
ybdz3a46.c: In function 'nk':
ybdz3a46.c:4:1: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.c:2397
 nk (int g1)
 ^~
0x61d137 expand_LOOP_VECTORIZED
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/internal-fn.c:2397
0x95f0c7 expand_call_stmt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:2587
0x95f0c7 expand_gimple_stmt_1
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:3613
0x95f0c7 expand_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:3779
0x9604b2 expand_gimple_basic_block
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:5797
0x964a86 execute
   
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171217/work/gcc-8-20171217/gcc/cfgexpand.c:6403

[Bug tree-optimization/83580] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 83580
   Summary: Wrong constant folding
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

GCC 8.0.0 for x86_64 miscompiles the following code.

% cat test.c
int a[2] =  {0,1};
int x =  129;
int main (void)
{
  volatile int v = 0;
  int t = x;
  for (int i = 0; i < (1+v+v+v+v+v+v+v+v+a[a[0]]); i++) {
t = a[(signed char)(130-x)];
  }
  if (t != 1) __builtin_abort();
  return 0;
}

% gcc-8.0.0 test.c
% ./a.out

% gcc-8.0.0 test.c -O3
% ./a.out
zsh: abort (core dumped)  ./a.out

% gcc-8.0.0 -v
Using built-in specs.
COLLECT_GCC=gcc-8.0.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-8.0.0/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-8.0.0 --disable-nls
--disable-multilib --program-suffix=-8.0.0 --enable-languages=c
Thread model: posix
gcc version 8.0.0 20171215 (experimental) (GCC)

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[asorenji at gmail dot com]

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

--- Comment #15 from Aso Renji  ---
(In reply to Jonathan Wakely from comment #14)
> What do you mean by "same problem"? The original testcase does not produce a 
> warning with GCC 6.3.0
No, this warning still appear if (and only if) you use -O2 or -O3 optimization
key (as it be in startpost with "g++ -O3 -Wstrict-aliasing test.cc -o
/dev/null" line).

If I don't use any optimization - yes, this warning don't appeared.

[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Should be fixed now.

[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Sun Dec 24 09:17:38 2017
New Revision: 255992

URL: https://gcc.gnu.org/viewcvs?rev=255992=gcc=rev
Log:
PR libstdc++/83450 avoid -Wreturn-type warning in test

PR libstdc++/83450
* testsuite/21_strings/basic_string/pthread18185.cc: Add return
statement.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/21_strings/basic_string/pthread18185.cc

[Bug libstdc++/83538] std::match_results C++14 conformance issue: reference != value_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-24
 Ever confirmed|0   |1

[Bug c++/83533] error: no type named 'X' in 'using = ...'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.0

--- Comment #2 from Jonathan Wakely  ---
GCC 4.7.x has not been maintained or supported by the upstream GCC project for
several years, and this is already fixed in GCC 4.8.0

[Bug libstdc++/68735] FAIL: libstdc++-prettyprinters/libfundts.cc print ab

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Those Python exceptions come from GDB, but I'm not sure why.

[Bug target/83008] [performance] Is it better to avoid extra instructions in data passing between loops?

[sergey.shalnov at intel dot com]

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

--- Comment #18 from sergey.shalnov at intel dot com ---
Yes, I agree that vector_store stage has it’s own vectorization cost.
And each vector_store has vector_construction stage. These stages are different
in gcc slp (as you know).
To better illustrate my point of view I would like to propose a patch.
I didn’t submit the patch to community yet because I think it is better to
discuss it before that.

index 0ca42b4..72e3123 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1825,7 +1825,7 @@ vect_analyze_slp_cost_1 (slp_instance instance, slp_tree
node,
record_stmt_cost (prologue_cost_vec, 1, vector_load,
  stmt_info, 0, vect_prologue);
  else if (dt == vect_external_def)
-   record_stmt_cost (prologue_cost_vec, 1, vec_construct,
+   record_stmt_cost (prologue_cost_vec, ncopies_for_cost,
vec_construct,
  stmt_info, 0, vect_prologue);
}
 }

[Bug fortran/83540] [8 Regression] Invalid code with MATMUL, -fno-realloc-lhs -ffrontend-optimize

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
(In reply to Harald Anlauf from comment #4)
> (In reply to Dominique d'Humieres from comment #3)
> > The code uses ALLOCATE without any realloc-lhs!-(
> 
> The problem shows up for any use of MATMUL as argument
> to a procedure, whether user-defined or intrinsic.
> Maybe the problem is just related to the needed temporary.

Correct, reallocation on assignment is used at the momemt
for creating the temporaries if the bounds are unknown.

[Bug middle-end/83557] missing last char in printf fmt string

[x37a5709 at gmail dot com]

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

--- Comment #3 from m68k  ---
Thanks for the feedback of this forgotten/unexpected behavior.

The funny part of this is, that the rules are not easy to adopt
see what printf("%c\r\n", 'A');

    5      .LC1:
    6 0002 25630D0A         .string    "%c\r\n" <--printf("%c\r\n", 'A');
    6  00
HERE \n is maintained, not taking into account puts behavior!!


\n is also maintained in some semantic wrong but syntax correct statement
see and compare:

printf("\r\n");   with printf("\r\n", ' ');

    3      .LC0:
    4  0D00         .string    "\r" <---printf("\r\n");
    5      .LC1:
    6 0002 0D0A00           .string    "\r\n" <---printf("\r\n", ' ');



and \n is also maintained when \n not at the end of a string
see what printf("\n\r");  brings

   11      .LC4:
   12 000d 0A0D00           .string    "\n\r" <---printf("\n\r)");






On 12/22/2017 04:57 PM, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83557
>
> Andrew Pinski  changed:
>
> What|Removed |Added
> 
>   Status|UNCONFIRMED |RESOLVED
>   Resolution|--- |INVALID
>
> --- Comment #1 from Andrew Pinski  ---
> printf("\r\n");
>
> Gets converted into puts("\r");  as allowed by the C standard.  The C standard
> says \n is a new line and puts will put a newline marker on the stdout.
>
> If you don't want this conversion use -fno-builtins, -fno-builtin-printf,
> -ffree-standing (I think that is the option name).
>

[Bug middle-end/83557] missing last char in printf fmt string

[x37a5709 at gmail dot com]

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

--- Comment #2 from m68k  ---
Thanks for the feedback of this forgotten/unexpected behavior.

The funny part of this is, that the rules are not easy to adopt


see what printf("%c\r\n", 'A'); 

   5.LC1:
   6 0002 25630D0A  .string "%c\r\n" <--printf("%c\r\n", 'A'); 
   6  00
HERE \n is maintained, not taking into account puts behavior!!


\n is also maintained in some semantic wrong but syntax correct statement
see:

printf("\r\n");   with printf("\r\n", ' ');

   3.LC0:
   4  0D00  .string "\r"  <---printf("\r\n"); 
   5.LC1:
   6 0002 0D0A00.string "\r\n"<---printf("\r\n", ' ');



and \n is also maintained when \n not at the end of a string
and see what printf("\n\r"); 

  11.LC4:
  12 000d 0A0D00.string "\n\r"  <---printf("\n\r)");

[Bug libstdc++/83450] FAIL: 21_strings/basic_string/pthread18185.cc (test for excess errors)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-24
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Control cannot reach the end of that function, but I assume pthread_exit isn't
marked noreturn on HPUX.

[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  ---
(In reply to Aso Renji from comment #13)
> Still have same problem in g++ 6.3.0. So, please reopen this bug.

What do you mean by "same problem"? The original testcase does not produce a
warning with GCC 6.3.0

If you get a warning for a different piece of code then please open a new bug,
this one is fixed.

[Bug libstdc++/83511] Missing default argument for basic_string_view::substr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-24
 Ever confirmed|0   |1

[Bug c++/83484] constexpr not evaluated at compile time

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|link-failure|accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-24
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
(In reply to Wilhelm M from comment #3)
> Here ist a simplified version of a MCVE:
> 
> template
> struct X {
> static constexpr int x = 0;
> static constexpr int y = 1;
> };
> 
> template<>
> constexpr int X<1>::x = 2; // should be ok, but gives duplicate
> initialization error

The compiler is correct.

> template<>
> constexpr int X<1>::y; // should be ill-formed (constexpr must be
> initialized), but gives undefined reference

How do you get an undefined reference if the previous definition gives an
error?

But I think you're right that it should be ill-formed, and that makes the
original testcase ill-formed. So the bug is "accepts-invalid" not
"link-failure".

[Bug c++/83473] pragma problems with raw string literals

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-12-24
Version|5.4.0   |6.3.0
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
GCC 5 is no longer maintained.