[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Attachment #41101|0   |1
is obsolete||

--- Comment #89 from Bernd Edlinger  ---
Created attachment 41103
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41103=edit
updated patch

should work in principle with LTO,
but there is still another bug
somewhere which makes __attribute__((may_alias))
and the std::byte handling fail in the end.

consider this test example:

cat t.cc
#include 
//namespace std { enum class byte: unsigned char {}; };
struct t  {
  int x;
  //std::byte kk[1];
  unsigned char k;
} __attribute__((may_alias));

t t1;
t t2;
t *t3;
t *t4;

void __attribute__((noinline, noclone))
test()
{
  t1 = t2;
  *t4 = *t3;
}

int main()
{
  test();
}

g++ -std=c++17 -O2 -fdump-rtl-final t.cc

t.cc.309r.final:
(insn:TI 6 2 7 2 (set (reg:DI 0 ax [orig:90 MEM[(const struct t &
{ref-all})] ] [90])
(mem/c:DI (symbol_ref:DI ("t2") [flags 0x2]  ) [0 MEM[(const struct t & {ref-all})]+0 S8 A64])) "t.cc":17 81
{*movdi_internal}
 (expr_list:REG_EQUIV (mem/c:DI (symbol_ref:DI ("t2") [flags 0x2] 
) [0 MEM[(const struct t & {ref-all})]+0 S8
A64])
(nil)))
(insn:TI 7 6 14 2 (set (mem/c:DI (symbol_ref:DI ("t1") [flags 0x2]  ) [2 t1+0 S8 A64])
(reg:DI 0 ax [orig:90 MEM[(const struct t & {ref-all})] ] [90]))
"t.cc":17 81 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 0 ax [orig:90 MEM[(const struct t &
{ref-all})] ] [90])
(nil)))
(insn 14 7 10 2 (set (reg/f:DI 0 ax [orig:87 t3.1_1 ] [87])
(mem/f/c:DI (symbol_ref:DI ("t3") [flags 0x2]  ) [1 t3+0 S8 A64])) "t.cc":18 81 {*movdi_internal}
 (expr_list:REG_EQUIV (mem/f/c:DI (symbol_ref:DI ("t3") [flags 0x2] 
) [1 t3+0 S8 A64])
(nil)))
(insn:TI 10 14 15 2 (set (reg:DI 1 dx [orig:91 MEM[(const struct t &
{ref-all})t3.1_1] ] [91])
(mem:DI (reg/f:DI 0 ax [orig:87 t3.1_1 ] [87]) [0 MEM[(const struct t &
{ref-all})t3.1_1]+0 S8 A32])) "t.cc":18 81 {*movdi_internal}
 (expr_list:REG_DEAD (reg/f:DI 0 ax [orig:87 t3.1_1 ] [87])
(nil)))
(insn 15 10 11 2 (set (reg/f:DI 0 ax [orig:88 t4.2_2 ] [88])
(mem/f/c:DI (symbol_ref:DI ("t4") [flags 0x2]  ) [1 t4+0 S8 A64])) "t.cc":18 81 {*movdi_internal}
 (expr_list:REG_EQUIV (mem/f/c:DI (symbol_ref:DI ("t4") [flags 0x2] 
) [1 t4+0 S8 A64])
(nil)))
(insn:TI 11 15 23 2 (set (mem:DI (reg/f:DI 0 ax [orig:88 t4.2_2 ] [88]) [0
*t4.2_2+0 S8 A32])
(reg:DI 1 dx [orig:91 MEM[(const struct t & {ref-all})t3.1_1] ] [91]))
"t.cc":18 81 {*movdi_internal}
 (expr_list:REG_DEAD (reg:DI 1 dx [orig:91 MEM[(const struct t &
{ref-all})t3.1_1] ] [91])
(expr_list:REG_DEAD (reg/f:DI 0 ax [orig:88 t4.2_2 ] [88])
(nil



I think the access to t1 uses alias set 2, and that is wrong.
The other accesses are ok.

[Bug libstdc++/79141] [6/7 Regression] std::pair<int,int> p = {}; fails to compile due to ambiguous overload

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com

--- Comment #2 from Ville Voutilainen  ---
Mine, patch available: https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00034.html

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[meissner at linux dot vnet.ibm.com]

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

--- Comment #11 from Michael Meissner  ---
On Fri, Mar 31, 2017 at 06:35:20PM +, kelvin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108
> 
> --- Comment #9 from kelvin at gcc dot gnu.org ---
> I've got a patch now that resolves this problem without creating regressions. 
> I'm attaching it for "discussion" here before I post for "official review".
> 
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c  (revision 246573)
> +++ gcc/config/rs6000/rs6000.c  (working copy)
> @@ -4273,8 +4273,30 @@ rs6000_option_override_internal (bool global_init_
>/* For the newer switches (vsx, dfp, etc.) set some of the older options,
>   unless the user explicitly used the -mno- to disable the code. 
> */
>if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_DFORM_SCALAR
> -  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0 ||
> TARGET_P9_MINMAX)
> +  || TARGET_P9_DFORM_VECTOR || TARGET_P9_DFORM_BOTH > 0)
>  rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~rs6000_isa_flags_explicit);
> +  else if (TARGET_P9_MINMAX)
> +{
> +  if (have_cpu)
> +   {
> + if (cpu_index == PROCESSOR_POWER9)
> +   /* legacy behavior: allow -mcpu-power9 with certain capabilities
> +  (eg -mno-vsx) explicitly disabled.  */

Note, -mpower9-minmax makes no sense without -mvsx, since it is a VSX
instruction.

It also requires upper reg support for the appropriate mode (i.e. double
requires TARGET_UPPER_REGS_DF and float requires TARGET_UPPER_REGS_SF, it is
probably simpler to require both).  This comes from a LRA behavior of crashing
if the constraint allows more registers than the register class allows.  We
could add additional constraints in the min/max insns if we wanted to support
no upper regs and min/max, but I don't think it is worth it.

(define_insn "*s3_vsx"
  [(set (match_operand:SFDF 0 "vsx_register_operand" "=,")
(fp_minmax:SFDF (match_operand:SFDF 1 "vsx_register_operand"
",")
(match_operand:SFDF 2 "vsx_register_operand"
",")))]
  "TARGET_VSX && TARGET__FPR"
{
  return (TARGET_P9_MINMAX
  ? "xscdp %x0,%x1,%x2"
  : "xsdp %x0,%x1,%x2");
}
  [(set_attr "type" "fp")])

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #88 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #87)
> On April 1, 2017 4:40:19 PM GMT+02:00, "bernd.edlinger at hotmail dot de"
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> >
> >--- Comment #86 from Bernd Edlinger 
> >---
> >Created attachment 41101 [details]
> >  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41101=edit
> >another trial patch
> >
> >This is another approach for a patch that reflects what I understood
> >so far what the C++17 spec wants from us.
> >I think it should resolve the issue Richard raised.
> 
> That doesn't properly work with LTO

oops...
I think this does not work either,
at cp/decl.c (start_enum):

  /* std::byte aliases anything.  */
  if (enumtype != error_mark_node
  && TYPE_CONTEXT (enumtype) == std_node
  && !strcmp ("byte", TYPE_NAME_STRING (enumtype)))
TYPE_ALIAS_SET (enumtype) = 0;

I looked at -flto -fdump-rtl-final
and see the alias set is 1:

#include 
//namespace std { enum class byte: unsigned char {}; };
union  t  {
  int x;
  std::byte k[1];
};
t t1;
t t2;
void test()
{
  t1.k[0] = t2.k[0];
}
int main()
{
  test();
}

g++ -std=c++17 -flto -fdump-rtl-final t.cc

/tmp/cc*.final:
(insn 5 2 6 2 (set (reg:QI 0 ax [orig:87 _1 ] [87])
(mem/j/c:QI (symbol_ref:DI ("t2") [flags 0x2]  ) [1 t2.k+0 S1 A32])) "t.cc":11 84 {*movqi_internal}
 (nil))
(insn 6 5 13 2 (set (mem/j/c:QI (symbol_ref:DI ("t1") [flags 0x2]  ) [1 t1.k+0 S1 A32])
(reg:QI 0 ax [orig:87 _1 ] [87])) "t.cc":11 84 {*movqi_internal}
 (nil))


[1 = alias set 1 but should be 0

[Bug tree-optimization/80281] [5/6/7 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
It has been just latent before that.
Let's change the testcase to:
int
main ()
{
  volatile int a = 0;
  long long b = 2147483648LL;
  int c = a % 2;
  int x = ((int) -b + c) % -2147483647;
  if (x != -1)
__builtin_abort ();
  return 0;
}
so that it works also on ILP32 without triggering UB.
Already in *.original it looks wrong:
int x = (c - (int) b) % 2147483647;
which is incorrect, because originally the negation has been performed in a
wider type where it didn't trigger UB, but in the narrower type it does.
In the original testcase we get -2147483648LL converted to -2147483648 int + 0.
But in what we have in *.original we have 2147483648LL converted to -2147483648
and compute 0 - (-2147483648), which is UB.
So, if we want to transform (int) -b + c into c - (int) b, we actually need to
do the subtraction in unsigned int type and convert back (until we have
separate wrapping signed arithmetic opcodes in GIMPLE if ever).
Thus it should be int x = (int) ((unsigned) c - (unsigned) b) % -2147483647;

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[rguenther at suse dot de]

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

--- Comment #87 from rguenther at suse dot de  ---
On April 1, 2017 4:40:19 PM GMT+02:00, "bernd.edlinger at hotmail dot de"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
>
>--- Comment #86 from Bernd Edlinger 
>---
>Created attachment 41101
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41101=edit
>another trial patch
>
>This is another approach for a patch that reflects what I understood
>so far what the C++17 spec wants from us.
>I think it should resolve the issue Richard raised.

That doesn't properly work with LTO

[Bug tree-optimization/80281] [5/6/7 Regression] Wrong constant folding

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r158965 I think.

[Bug tree-optimization/80281] [5/6/7 Regression] Wrong constant folding

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-01
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|Wrong constant folding  |[5/6/7 Regression] Wrong
   ||constant folding
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  Worked with GCC 4.4.

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

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

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

Bug ID: 80281
   Summary: Wrong constant folding
   Product: gcc
   Version: 7.0.1
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 7.0.1 for x86_64 miscompiles the following code.

% cat test.c

int main (void)
{
volatile int a = 0;
long b = 2147483648L;

int c = a % 2;
int x = ( (int)( -b ) + c  ) % -2147483647;

if (x != -1) __builtin_abort();

return 0;
}
% gcc-7.0 test.c -O3
% ./a.out
zsh: abort (core dumped)  ./a.out
% gcc-7.0 test.c -Os
% ./a.out
zsh: abort (core dumped)  ./a.out
% gcc-7.0 -v
Using built-in specs.
COLLECT_GCC=gcc-7.0
COLLECT_LTO_WRAPPER=/home/cappie/opt/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/cappie/opt/gcc-7.0.1 --disable-nls
--disable-multilib --program-suffix=-7.0 --enable-languages=c
Thread model: posix
gcc version 7.0.1 20170330 (experimental) (GCC)

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #11 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #9)
> Vlad, any thoughts on this?
> 
I've been working on this and a wrong allocation is a culprit.  According to
IRA dump,  the allocation should be what we expect.  But it is not.  I guess
there are a few factors to this.  First of all IRA has cost 65535 for moving
AREG into/from GENERAL_REGS.  And second factor is an overflow on 32-bit
machine when such big cost is used in IRA.

I'll continue my work on it next week.  I hope the patch will be ready in the
middle of the next week.

[Bug translation/80280] New: Missing closing quote (%>) c/semantics.c and c/c-typeck.c

[fmarchal at perso dot be]

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

Bug ID: 80280
   Summary: Missing closing quote (%>) c/semantics.c and
c/c-typeck.c
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

The following four messages lack a closing quote (%>) somewhere after the
%<#pragma...

In c/semantics.c:8523

  error ("%<#pragma omp cancel must specify one of "
 "%, %, % or % clauses");

In c/semantics.c:8560

  error ("%<#pragma omp cancellation point must specify one of "
 "%, %, % or % clauses");

In c/c-typeck.c:11867

  error_at (loc, "%<#pragma omp cancel must specify one of "
 "%, %, % or % "
 "clauses");

In c/c-typeck.c:11906

  error_at (loc, "%<#pragma omp cancellation point must specify one of "
 "%, %, % or % "
 "clauses");

[Bug c++/80176] [5/6/7 Regression] cannot bind reference to static member function using object access expression

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41102
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41102=edit
gcc7-pr80176.patch

Untested fix.

[Bug c++/80279] Implement DR 2061

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-01
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/80279] New: Implement DR 2061

[nathan at gcc dot gnu.org]

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

Bug ID: 80279
   Summary: Implement DR 2061
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

DR 2061.

inline namespace B {
  namespace C {
...
  }
}

namespace C { // this reopens B::C
  ...
}

[Bug translation/80278] New: Messages with untranslated string fragment in config/i386/i386.c

[fmarchal at perso dot be]

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

Bug ID: 80278
   Summary: Messages with untranslated string fragment in
config/i386/i386.c
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fmarchal at perso dot be
  Target Milestone: ---

In function ix86_option_override_internal() in config/i386/i386.c, several
messages are build like this:

   error ("generic CPU can be used only for %stune=%s %s",
  prefix, suffix, sw);

Here, sw is assigned an untranslated string literal:

  /* Set up prefix/suffix so the error messages refer to either the command
 line argument, or the attribute(target).  */
  if (main_args_p)
{
  prefix = "-m";
  suffix = "";
  sw = "switch";
}
  else
{
  prefix = "option(\"";
  suffix = "\")";
  sw = "attribute";
}

Such messages can't be translated properly because sw isn't translated.

An easy fix might be to use sw=_("switch") and sw=_("attribute") but, if you do
that, please add a comment to let the translators know that the nth %s in the
message is replaced with the translation for "switch" or "attribute".

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[sch...@linux-m68k.org]

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

--- Comment #7 from Andreas Schwab  ---
http://gcc.gnu.org/ml/gcc-testresults/2017-04/msg00082.html

The ICE is gone, but gnat.dg/stack_check[12].adb fail execution test.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

[bernd.edlinger at hotmail dot de]

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

--- Comment #86 from Bernd Edlinger  ---
Created attachment 41101
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41101=edit
another trial patch

This is another approach for a patch that reflects what I understood
so far what the C++17 spec wants from us.
I think it should resolve the issue Richard raised.

[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|jakub at gcc dot gnu.org   |jason at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Jason said he has a patch for this, so reassigning.

[Bug fortran/80235] ICE: coarrays, submodule

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #6 from vehre at gcc dot gnu.org ---
May be a duplicate of or similar to pr78983.

[Bug libgomp/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres  ---
> Anyway, here is an untested patch to bump the default on Darwin only.

The patch fixes the issue on darwin16. Testing on darwin10 in progress.

[Bug fortran/78293] [5/6/7 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 #7 from Dominique d'Humieres  ---
> > 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?

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

[vehre at gmx dot de]

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

--- Comment #6 from Andre Vehreschild  ---
Hi Paul,

I am busy doing Coarray work at the moment. So from my side: no time.

You may want to have a look whether the part in trans-expr.c fixes the issue
sufficiently or with just a small work-around in gfc_trans_allocate. But I
would not spend to much time on that, because the part in trans_allocate may
heavily depend on the new structure and therefore be a pain in the ass to port.
(But honestly, I haven't shed an eye on this).

HTH. 

- Andre

On Sat, 01 Apr 2017 12:03:20 +
"pault at gcc dot gnu.org"  wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293
> 
> --- Comment #5 from Paul Thomas  ---
> (In reply to Dominique d'Humieres from comment #4)
> > 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?
> 
> Cheers
> 
> Paul
>

[Bug fortran/69834] [OOP] Collision in derived type hashes

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas  ---
(In reply to paul.richard.tho...@gmail.com from comment #12)
> Hi Dominique,
> 
> I was intending to backport to 6-branch but wanted to be sure that no
> nasties come out of the woodwork on trunk.
> 
> Best regards
> 
> Paul
> 
> PS Will be back in France late tonight and will start picking up the
> threads again. My Mother's death and funeral have taken up the last 10
> days.
> 
> On 3 November 2016 at 11:15, dominiq at lps dot ens.fr
>  wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
> >
> > Dominique d'Humieres  changed:
> >
> >What|Removed |Added
> > 
> >  Status|NEW |WAITING
> >
> > --- Comment #11 from Dominique d'Humieres  ---
> > Paul,
> >
> > Are you planning to back port r241450? If no, is there any reason to keep 
> > this
> > PR open?
> >
> > --
> > You are receiving this mail because:
> > You are the assignee for the bug.
> > You reported the bug.

What do you think about backporting? I rather think that it would be safe after
all this time on trunk.

Paul

[Bug fortran/78293] [5/6/7 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 #5 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #4)
> 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?

Cheers

Paul

[Bug fortran/79382] DTIO ICE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #11 from Paul Thomas  ---
Fixed

Thanks for the report

Paul

[Bug fortran/80156] [7 Regression] Generic DTIO interface reported missing if public statement preceeds the interface block

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  ---
Although it is a shame that I do not see a way to emit a warning that the dtio
proc is missing in the original problem, it does not ice, at least, and the
runtime problem is fixed.

Thanks for the report

Paul

[Bug fortran/80235] ICE: coarrays, submodule

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #4)
> Reduced submodule
> 
> submodule ( m ) sm
> 
> contains
> 
>   module subroutine cgca_pfem_map( origin, rot, bcol, bcou )
>   implicit none
> real( kind=rdef ), intent( in ) :: &
>   origin(3),& ! origin of the "box" cs, in FE cs
>   rot(3,3), & ! rotation tensor *from* FE cs *to* CA cs
>   bcol(3),  & ! lower phys. coords of the coarray on image
>   bcou(3) ! upper phys. coords of the coarray on image
> 
> integer( kind=idef ) :: maxfe
> 
> maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 )
> call co_max( maxfe )
>  
> end subroutine cgca_pfem_map
> 
> end submodule sm

I am unable to reproduce this bug on FC23/x86_64.

Sorry! If you could greatly reduce it, I might be able to spot the problem.
Which statement in the reduced case above causes the ICE?

Paul

[Bug fortran/71838] ICE with OpenCoarrays on submodule

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #18 from Paul Thomas  ---
Fixed on trunk and 6-branch.

Thanks for the report

Paul

[Bug fortran/79676] [submodules] Compilation/linking error when module procedures PRIVATE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Fixed on trunk and 6-branch.

Thanks for the report

Paul

[Bug fortran/71838] ICE with OpenCoarrays on submodule

[pault at gcc dot gnu.org]

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

--- Comment #17 from Paul Thomas  ---
Author: pault
Date: Sat Apr  1 11:35:14 2017
New Revision: 246632

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

Backport from trunk
PR fortran/71838
* symbol.c (check_conflict): A dummy procedure in a submodule,
module procedure is not an error.
(gfc_add_flavor): Ditto.

2017-04-01  Paul Thomas  

Backport from trunk
PR fortran/71838
* gfortran.dg/submodule_26.f08 : New test.
* gfortran.dg/submodule_27.f08 : New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_26.f08
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/submodule_27.f08
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/symbol.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug ipa/80277] New: ipa-icf missing overlooking functions

[linux at carewolf dot com]

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

Bug ID: 80277
   Summary: ipa-icf missing overlooking functions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

Created attachment 41100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41100=edit
icf.cc

Several functions that produce identical assembler are not merged by ipa-icf. I
have attached an example, and only the two functions foo0 and foo1 that are
identical in every detail are meged, though all the foo* functions produce
identical assembler.

I theorice it is because the function signature is compared before the content,
and the templates and different types might cause that early comparison to fail
when it shouldn't.

I added a second test that just changed the return value but kept everything
else identical and it also wasn't merged.


A little unrelated: I noted the ipa-icf optimization is undone by -O3 as it
re-inlines, though that is kind of pointless unless it is needed for second
level inlining.

[Bug libstdc++/80276] New: pretty printer for std::unique_ptr<T[]> shows type as std::unique_ptr

[redi at gcc dot gnu.org]

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

Bug ID: 80276
   Summary: pretty printer for std::unique_ptr shows type as
std::unique_ptr
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

And also gives a GDB error:

(gdb) ptype/mt buf
type = Python Exception  No type named char [].:
class std::unique_ptr > [with _Tp = char
[], _Dp = std::default_delete] {
  private:
std::__uniq_ptr_impl _M_t;
}
(gdb) p buf
$3 = std::unique_ptr containing 0x75f46010 ""

[Bug rtl-optimization/67396] [5 regression] Performance regression compiling variadic function with many arguments in RTL DSE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|[5/6/7 regression]  |[5 regression] Performance
   |Performance regression  |regression compiling
   |compiling variadic function |variadic function with many
   |with many arguments in RTL  |arguments in RTL DSE
   |DSE |

--- Comment #12 from Jakub Jelinek  ---
This doesn't reproduce since r234709, even with 1 arguments even checking
compiler takes just 7 seconds.

[Bug debug/68860] [6/7/8 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|7.0 |8.0
Summary|[6/7 regression] FAIL:  |[6/7/8 regression] FAIL:
   |gcc.dg/guality/pr36728-1.c  |gcc.dg/guality/pr36728-1.c
   | -flto -O3 -g  line 16/7| -flto -O3 -g  line 16/7
   |arg1 == 1   |arg1 == 1

--- Comment #18 from Jakub Jelinek  ---
Deferring till we have early LTO debug info in.

[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
Why can't the middle-end/LTO handle comdat groups with some hidden and some
non-hidden aliases?  I don't see something inherently wrong on what the C++ FE
is doing.  Shouldn't we privatize the whole comdat group only if it has no
exported symbols in it?

[Bug fortran/79676] [submodules] Compilation/linking error when module procedures PRIVATE

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Sat Apr  1 09:35:52 2017
New Revision: 246631

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

Backport from trunk
PR fortran/79676
* module.c (mio_symbol_attribute): Remove reset of the flag
'no_module_procedures'.
(check_for_module_procedures): New function. Move declaration
of 'no_module_procedures' to above it.
(gfc_dump_module): Traverse namespace calling new function.

2017-04-01  Paul Thomas  

Backport from trunk
PR fortran/79676
* gfortran.dg/submodule_28.f08 : New test.


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

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug libgomp/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 41098
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41098=edit
gcc7-pr79876.patch

Found https://developer.apple.com/library/content/qa/qa1419/_index.html that
documents the default to be 512KB which is way too low (though it is unclear if
it is the same on all Darwin versions).
Anyway, here is an untested patch to bump the default on Darwin only.

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 41097
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41097=edit
gcc7-pr79390.patch

Untested fix.