[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA

[marco_atzeri at yahoo dot it]

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

marco atzeri  changed:

   What|Removed |Added

  Attachment #44949|0   |1
is obsolete||

--- Comment #10 from marco atzeri  ---
Created attachment 45348
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45348=edit
updated patch for 7.3.0 - validated for style

refreshed patch that passes the 
 check_GNU_style.sh control.

Only formatting and removal of not needed comments versus previous one.
Previous one was applied on 7.4 for cygwin binary package without any build
problem

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
for the v4sf issue (v2sf has a similar issue too):
(define_insn "vec_extract"
  [(set (match_operand: 0 "nonimmediate_operand" "=Um,r")
(vec_select:
  (match_operand:VQ2 1 "s_register_operand" "w,w")
  (parallel [(match_operand:SI 2 "immediate_operand" "i,i")])))]


That does not allow w (neon/vfp register) constraint as a dst so everything
needs to go through GPRs.

There is no vec_extract for V2DF which causes it to go through memory.

For the init part, the biggest issue is neon_expand_vector_init falls back to
doing everything in memory instead of doing "insertations" if there are a small
number of elements (<= 4, though you could do some gpr logical operations to
get to that number if needed):
  /* Construct the vector in memory one field at a time
 and load the whole vector.  */
  mem = assign_stack_temp (mode, GET_MODE_SIZE (mode));
  for (i = 0; i < n_elts; i++)
emit_move_insn (adjust_address_nv (mem, inner_mode,
i * GET_MODE_SIZE (inner_mode)),
XVECEXP (vals, 0, i));
  emit_move_insn (target, mem);

- CUT 
Note aarch64_expand_vector_init has some interesting ideas that could be
repeated here (and more due to the overlapping of lower d, q, and s registers).

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-05
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
  _5 = BIT_FIELD_REF ;
  _6 = BIT_FIELD_REF ;
  _7 = _5 * _6;

Here is a shorter testcase for one of the issues:
typedef float f32x4 __attribute__((vector_size(16)));
typedef double f64x2 __attribute__((vector_size(16)));


float f(f32x4 v1, f32x4 v2)
{
  return v1[0] * v2[0];
}
double d(f64x2 v1, f64x2 v2)
{
  return v1[0] * v2[0];
}

- CUT 
This is the extraction issue.

There is a generation issue too:
typedef float f32x4 __attribute__((vector_size(16)));
typedef double f64x2 __attribute__((vector_size(16)));


f32x4 f1(float a, float b, float c, float d)
{
  return (f32x4){a,b,c,d};
}
f64x2 d1(float a, float b)
{
  return (f64x2){a,b};
}
 CUT 
I think they both should be filed seperately too and make this depdent on those
two issues.

[Bug fortran/88653] Is this a compiler bug?

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle  ---
OK, I had one other test fail which is one that requires inspection that my
testsuite compares the output to a reference file. This required only updating
my reference file to accomodate the fix where we took the spaces out inside the
parens for complex number output.

So with the discussed fixes NIST tests also pass for me.

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #4 from Andrew Pinski  ---
(In reply to Devin Hussey from comment #3)
> Well, it is still not as efficient as it should be.
> 
> This would be the code that only uses VFP:

That I agree with.  But arm32 is not where most of the work is being put into
...

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[husseydevin at gmail dot com]

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

Devin Hussey  changed:

   What|Removed |Added

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

--- Comment #3 from Devin Hussey  ---
Well, it is still not as efficient as it should be.

This would be the code that only uses VFP:

fmul:
vadd.f32s0, s0, s4
vadd.f32s1, s1, s5
vadd.f32s2, s2, s6
vadd.f32s3, s3, s7
bx  lr

dmul:
vadd.f64d0, d0, d2
vadd.f64d1, d1, d3
bx  lr

There is no need to keep swapping in and out of NEON registers.

[Bug middle-end/88670] [meta-bug] generic vector extension issues

[husseydevin at gmail dot com]

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

Bug 88705 Summary: [ARM][Generic Vector Extensions] float32x4/float64x2 vector 
operator overloads scalarize on NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88705

   What|Removed |Added

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

[Bug target/61367] Annoying rtx cost information in middle end dumps on arm/aarch64 targets

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed a long time ago by:
+2016-11-16  Andrew PInski  
+
+   * config/aarch64/aarch64.opt (mverbose-cost-dump): New option.
+   * config/aarch64/aarch64.c (aarch64_rtx_costs): Use
+   flag_aarch64_verbose_cost instead of checking for details dump.
+   (aarch64_rtx_costs_wrapper): Likewise.

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> This is expected.  

For reference the patch which changed the behavior between 4.5.0 and 4.6.0:
https://gcc.gnu.org/ml/gcc-patches/2010-06/msg02102.html

[Bug target/88705] [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is expected.  

See PR43703 for details on why.

Basically arm32 neon does not handle denormals at all.

It is a bug in clang (or rather their choice) to use them and not get valid
IEEE results.

[Bug middle-end/88670] [meta-bug] generic vector extension issues

[pinskia at gcc dot gnu.org]

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

Bug 88705 Summary: [ARM][Generic Vector Extensions] float32x4/float64x2 vector 
operator overloads scalarize on NEON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88705

   What|Removed |Added

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

[Bug target/88705] New: [ARM][Generic Vector Extensions] float32x4/float64x2 vector operator overloads scalarize on NEON

[husseydevin at gmail dot com]

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

Bug ID: 88705
   Summary: [ARM][Generic Vector Extensions] float32x4/float64x2
vector operator overloads scalarize on NEON
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: husseydevin at gmail dot com
  Target Milestone: ---

For some reason, GCC scalarizes float32x4_t and float64x2_t on ARM32 NEON when
using vector extensions. 

typedef float f32x4 __attribute__((vector_size(16)));
typedef double f64x2 __attribute__((vector_size(16)));

f32x4 fmul (f32x4 v1, f32x4 v2)
{
   return v1 * v2;
}
f64x2 dmul (f64x2 v1, f64x2 v2)
{
   return v1 * v2;
}

Expected output:

arm-none-eabi-gcc (git commit 640647d4, not the latest) -O3 -S -march=armv7-a
-mfloat-abi=hard -mfpu=neon

fmul:
vmul.f32 q0, q0, q1
bx lr
dmul:
vmul.f64 d1, d1, d3
vmul.f64 d0, d0, d2
bx lr

Actual output:

fmul:
vmov.32 r3, d0[0]
sub sp, sp, #16
vmovs12, r3
vmov.32 r3, d2[0]
vmovs9, r3
vmov.32 r3, d0[1]
vmul.f32s12, s12, s9
vstr.32 s12, [sp]
vmovs13, r3
vmov.32 r3, d2[1]
vmovs10, r3
vmov.32 r3, d1[0]
vmul.f32s13, s13, s10
vstr.32 s13, [sp, #4]
vmovs14, r3
vmov.32 r3, d1[1]
vmovs15, r3
vmov.32 r3, d3[0]
vmovs11, r3
vmov.32 r3, d3[1]
vmul.f32s14, s14, s11
vstr.32 s14, [sp, #8]
vmovs0, r3
vmul.f32s0, s15, s0
vstr.32 s0, [sp, #12]
vld1.64 {d0-d1}, [sp:64]
add sp, sp, #16
bx  lr
dmul:
push{r4, r5, r6, r7}
sub sp, sp, #96
vstrd0, [sp, #64]
vstrd1, [sp, #72]
vstrd2, [sp, #48]
vstrd3, [sp, #56]
vldr.64 d17, [sp, #64]
vldr.64 d19, [sp, #48]
vldr.64 d16, [sp, #72]
vldr.64 d18, [sp, #56]
vmul.f64d17, d17, d19
vmul.f64d16, d16, d18
vstr.64 d17, [sp, #32]
ldrdr0, [sp, #32]
mov r4, r0
mov r5, r1
strdr4, [sp]
vstr.64 d16, [sp, #40]
ldr r2, [sp, #40]
ldr ip, [sp, #44]
str r2, [sp, #8]
str ip, [sp, #12]
vld1.64 {d0-d1}, [sp:64]
add sp, sp, #96
pop {r4, r5, r6, r7}
bx  lr

The same thing happens for other operators.

Oddly, according to Godbolt, GCC 4.5 actually did 32-bit float vectors
properly, but regressed more and more each release starting in 4.6.

[Bug ipa/88702] [6/7/8 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The only pass that can do about this (at least right now) is reassoc (both 1
and 2), which is too late for inlining.  So, either teach fnsplit not to
separate multiple if comparisons of the same variable against constants, or
schedule reasoc or just the maybe_optimize_range_tests part thereof in some
early pass.

[Bug ipa/88702] [6/7/8 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka  ---
> With what options?  I'm getting 3 bit tests both with -O2 and -O3, both when
> using C and C++.  And get that also if I rewrite the function to use a switch
> instead.

-O2 -flto and then look into release_ssa dump.
In Firefox we then fail to inline things back together. I am debugging
that but already producing that at firstplace is bad.

[Bug c/88704] New: 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

Bug ID: 88704
   Summary: Accepts invalid program with [*] outside function
prototype scope.
   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):

  void f(a)
int a[*];
  {
  }

  int main()
  {
  }

Compilation command line:

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

Observed behaviour:

  No error message outputed.

Expected behaviour:

  An error message outputed.

  The program is invalid because [*] occurs outside function prototype scope.

Note:

  Clang gives the expected error message.

[Bug ipa/88702] [6/7/8 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
With what options?  I'm getting 3 bit tests both with -O2 and -O3, both when
using C and C++.  And get that also if I rewrite the function to use a switch
instead.

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
With the patch referenced in comment #5 and with bug 88546 fixed there are no
-Wmissing-attributes warnings in GCC builds.

For reference, the following is the warning breakdown from my bootstrap on
x86_64-linux with the patch for pr88546 applied:

DiagnosticCount   UniqueFiles
-Wmisleading-indentation 43   27   27
-Wimplicit-function-declaration   2053
-Wimplicit-fallthrough=  1211
-Wmaybe-uninitialized1054
-Wcast-function-type  743
-Waddress-of-packed-member771
-Wpragmas 611
-Wstringop-truncation 511
-Wformat-truncation=  531
-Wincompatible-pointer-types  421
-Walloca-larger-than= 421
-Wsign-compare211

[Bug c/88698] Relax generic vector conversions

[husseydevin at gmail dot com]

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

--- Comment #5 from Devin Hussey  ---
Well, if we are aiming for strict compliance, might as well throw out every GCC
extension in existence (including vector extensions), those aren't strictly
compliant to the C/C++ standard. /s

The whole point of extensions are to be an extension that violates the
standard.


#include 

uint64x2_t mult(uint64x2_t top, uint64x2_t bot)
{
return top * bot;
}


I am breaking two rules here:
1. Using operator overloads, which are not part of the standard.
2. Implying a nonexistent instruction, as there is no vmul.i64. (it is
scalarized at the moment, but I explained in bug 88510 that there are better
options)


Clang even allows this:


#include 

uint32x4_t mult(uint16x8_t top, uint32x4_t bot)
{
return top * bot;
}


In which it will reinterpret all to the widest lane type.

[Bug c/88546] Copy attribute unusable for weakrefs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed via r267591.

[Bug c/88546] Copy attribute unusable for weakrefs

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Sat Jan  5 00:57:30 2019
New Revision: 267591

URL: https://gcc.gnu.org/viewcvs?rev=267591=gcc=rev
Log:
PR c/88546 - Copy attribute unusable for weakrefs

gcc/c-family/ChangeLog:

PR c/88546
* c-attribs.c (handle_copy_attribute): Avoid copying attribute leaf.
Handle C++ empty throw specification and C11 _Noreturn.
(has_attribute): Also handle C11 _Noreturn.

gcc/ChangeLog:

PR c/88546
* attribs.c (decls_mismatched_attributes): Avoid warning for attribute
leaf.

gcc/testsuite/ChangeLog:

PR c/88546
* g++.dg/ext/attr-copy.C: New test.
* gcc.dg/attr-copy-4.c: Disable macro expansion tracking.
* gcc.dg/attr-copy-6.c: New test.
* gcc.dg/attr-copy-7.c: New test.


Added:
trunk/gcc/testsuite/g++.dg/ext/attr-copy.C
trunk/gcc/testsuite/gcc.dg/attr-copy-6.c
trunk/gcc/testsuite/gcc.dg/attr-copy-7.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/attribs.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/attr-copy-4.c
trunk/libgcc/gthr-posix.h
trunk/libgfortran/libgfortran.h

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

[vries at gcc dot gnu.org]

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

Bug ID: 88703
   Summary: oacc_validate_dims allows invalid dimensions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider oacc_validate_dims on trunk:
...
oacc_validate_dims (tree fn, tree attrs, int *dims, int level, unsigned used)
{
  tree purpose[GOMP_DIM_MAX];
  unsigned ix;
  tree pos = TREE_VALUE (attrs);

  /* Make sure the attribute creator attached the dimension 
 information.  */
  gcc_assert (pos);

  for (ix = 0; ix != GOMP_DIM_MAX; ix++)
{
  purpose[ix] = TREE_PURPOSE (pos);
  tree val = TREE_VALUE (pos);
  dims[ix] = val ? TREE_INT_CST_LOW (val) : -1;
  pos = TREE_CHAIN (pos);
}

  bool changed = targetm.goacc.validate_dims (fn, dims, level);

  /* Default anything left to 1 or a partitioned default.  */
  for (ix = 0; ix != GOMP_DIM_MAX; ix++)
if (dims[ix] < 0)
  {
/* The OpenACC spec says 'If the [num_gangs] clause is not  
   specified, an implementation-defined default will be used;   
   the default may depend on the code within the construct.'
   (2.5.6).  Thus an implementation is free to choose   
   non-unity default for a parallel region that doesn't have
   any gang-partitioned loops.  However, it appears that there  
   is a sufficient body of user code that expects non-gang  
   partitioned regions to not execute in gang-redundant mode.   
   So we (a) don't warn about the non-portability and (b) pick  
   the minimum permissible dimension size when there is no  
   partitioned execution.  Otherwise we pick the global 
   default for the dimension, which the user can control.  The  
   same wording and logic applies to num_workers and
   vector_length, however the worker- or vector- single 
   execution doesn't have the same impact as gang-redundant 
   execution.  (If the minimum gang-level partioning is not 1,  
   the target is probably too confusing.)  */
dims[ix] = (used & GOMP_DIM_MASK (ix)
? oacc_default_dims[ix] : oacc_min_dims[ix]);
changed = true;
  }

  if (changed)
{
  /* Replace the attribute with new values.  */
  pos = NULL_TREE;
  for (ix = GOMP_DIM_MAX; ix--;)
pos = tree_cons (purpose[ix],
 build_int_cst (integer_type_node, dims[ix]), pos);
  oacc_replace_fn_attrib (fn, pos);
}
}
...

It does the following:
- read the dimensions set in the attributes
- call targetm.goacc.validate_dims on those dimensions
- apply oacc_default_dims[ix] or oacc_min_dims[ix] to set remaining unset
  dimensions
- update the dimensions in the attributes

However, it's possible that the resulting dimensions are in fact invalid.

Consider this test-case on og8 branch:
...
$ cat libgomp/testsuite/libgomp.oacc-c-c++-common/test.c
/* { dg-do run { target openacc_nvidia_accel_selected } } */
/* { dg-additional-options "-fopenacc-dim=:32
-foffload=-mlong-vector-in-workers" } */

#include 

#define N 2048

unsigned int a[N];
unsigned int b[N];
unsigned int c[N];
unsigned int n = N;

int
main (void)
{
#pragma acc parallel vector_length (128) copyin (a,b) copyout (c)
  {
#pragma acc loop worker
for (unsigned int i = 0; i < n; i++)
  #pragma acc loop vector
  for (unsigned int j = 0; j < n; j++)
;
  }

  return 0;
}
...

This generates these dimensions in the .s file:
...
//:FUNC_MAP "main$_omp_fn$0", 0x1, 0x20, 0x80
...
so, num_workers * vector_length == 0x20 * 0x80 == 32 * 128 == 4096 (while the
maximum allowed is 1024 == maximum CTA size).

This causes a runtime error:
...
libgomp: The Nvidia accelerator has insufficient resources to launch
'main$_omp_fn$0' with num_workers = 32 and vector_length = 128; recompile the
program with 'num_workers = x and vector_length = y' on that offloaded region
or '-fopenacc-dim=-:x:y' where x * y <= 1024.
...

An easy way to detect this problem at compile time is by adding an assert here:
...
diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index aac0aa8b27a..7e3efa1032e 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -700,6 +700,7 @@ oacc_validate_dims
? oacc_default_dims[ix] : oacc_min_dims[ix]);
changed = true;
   }
+  gcc_assert (!targetm.goacc.validate_dims (fn, dims, level));

   if (changed)
 {
...

For the test-case, the compiler will enter the second call to
targetm.goacc.validate_dims with dims {1, 32, 

[Bug c/88698] Relax generic vector conversions

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Devin Hussey from comment #2)
> It is to be noted that Clang has -Wvector-conversion, which is the
> equivalent of -fno-lax-vector-conversions, however, it is a warning that
> only occurs with -Weverything. Not even -Wall -Wextra -Wpedantic in C++ mode
> will enable it. 

Sounds like clang decided to emulate GCC 3.4.x behavior and follow newer GCC's
behavior.

[Bug c/88698] Relax generic vector conversions

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
At one point -flax-vector-conversions was default and did the option did not
exist.  

https://gcc.gnu.org/ml/gcc/2006-10/msg00682.html

See also:
https://gcc.gnu.org/ml/gcc/2006-11/msg00051.html


NOTE having this option on is required to be complaint with both the Altivec
and SPU PEMs.  I remember when this discussion was happening since I was
working on PowerPC and I even voted against having an option to allowing the
lax conversion part.

[Bug fortran/88653] Is this a compiler bug?

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  ---
> Didn't someone just do some work on MAX1?

pr88658, fix at https://gcc.gnu.org/ml/fortran/2019-01/msg6.html.

[Bug c/88698] Relax generic vector conversions

[husseydevin at gmail dot com]

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

--- Comment #2 from Devin Hussey  ---
What I am saying is that I think -flax-vector-conversions should be default, or
we should only have minimal warnings instead of errors.

That will make generic vectors much easier to use.

It is to be noted that Clang has -Wvector-conversion, which is the equivalent
of -fno-lax-vector-conversions, however, it is a warning that only occurs with
-Weverything. Not even -Wall -Wextra -Wpedantic in C++ mode will enable it. 

If Clang thinks this is such a minor issue that it won't even warn with -Wall
-Wextra -Wpedantic, why does GCC consider it an error?



However, if you want examples, here:

Example 1 (SSE2)

Here, we are trying to use an intrinsic which accepts and returns an __m128i 
(defined as "long long __attribute__((vector_size(16)))") with a u32x4 (defined
as "uint32_t __attribute__((vector_size(16)))")


#include 
#include 

typedef uint32_t u32x4 __attribute__((vector_size(16)));

u32x4 shift(u32x4 val)
{
return _mm_srli_epi32(val, 15);
}


On Clang, it will happily accept that, only complaining on -Wvector-conversion.

GCC will fail to compile. 

There are three ways around that:
1. Typedef u32x4 to __m128i. This is unreasonable, because that causes the
operator overloads and constructors to operate on 64-bit integers instead of
32-bit.
2. Add -flax-vector-conversions. Requiring someone to add a warning suppression
flag to compile your code is often seen as code smell.
3. Cast. Good lord, if you thought intrinsics were ugly, this will change your
mind:

return (u32x4)_mm_srli_epi32((__m128i)val, 15);

or C++-style:

return static_cast(_mm_srli_epi32(static_cast<__m128i>(val), 15));


Example 2 (ARMv7-a + NEON):


#include 
_Static_assert(sizeof(unsigned long) == sizeof(unsigned int), "use 32-bit
please");

typedef unsigned long u32x4 __attribute__((vector_size(16)));

u32x4 shift(u32x4 val)
{
return vshrq_n_u32(val, 15);
}


This is the second issue: unsigned long and unsigned int are the same size and
should have no issues converting between each other.

This often comes from a situation where uint32_t is set to unsigned long.


Example 3 (Generic):


typedef unsigned u32x4 __attribute__((vector_size(16)));
typedef unsigned long long u64x2 __attribute__((vector_size(16)));

u64x2 cast(u32x4 val)
{
return val;
}


This should emit a warning without a cast. I would recommend an error, but
Clang without -Wvector-conversion accepts this without any complaining.


Example 4 (Generic): 


typedef unsigned u32x2 __attribute__((vector_size(8)));
typedef unsigned long long u64x2 __attribute__((vector_size(16)));


u64x2 cast(u32x2 val)
{
return val;
}


This is clearly an error. There should be __builtin_convertvector which is
being tracked in a different bug, but that is not the point.

[Bug fortran/69101] [F03] IEEE_SELECTED_REAL_KIND is not generic

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Assignee|fxcoudert at gcc dot gnu.org   |kargl at gcc dot gnu.org

--- Comment #11 from kargl at gcc dot gnu.org ---
I have a part 1 patch that addresses IEEE_SELECTED_REAL_KIND
in an initialization expression.

[Bug c++/88699] [9 Regression] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |
   Priority|P3  |P1

--- Comment #4 from Jakub Jelinek  ---
Reduced testcase:

template 
struct A {
  void operator= (int);
  template  class B;
};
template 
template 
struct A::B : A {
  using A::operator=;
  void operator= (B);
};

[Bug libstdc++/77776] C++17 std::hypot implementation is poor

[emsr at gcc dot gnu.org]

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

--- Comment #2 from emsr at gcc dot gnu.org ---
I have this in another tree which solves the inf issue:
  namespace __detail
  {
// Avoid including all of 
template
  constexpr _Tp
  __fmax3(_Tp __x, _Tp __y, _Tp __z)
  { return std::fmax(std::fmax(__x, __y), std::fmax(__y, __z)); }

template
  constexpr _Tp
  __hypot3(_Tp __x, _Tp __y, _Tp __z)
  {
if (std::isnan(__x)
 || std::isnan(__y)
 || std::isnan(__z))
  return std::numeric_limits<_Tp>::quiet_NaN();
else
  {
__x = std::abs(__x);
__y = std::abs(__y);
__z = std::abs(__z);
const auto __amax = __fmax3(__x, __y, __z);
if (__amax == _Tp{0})
  return _Tp{0};
else if (std::__detail::__isinf(__amax))
  return std::numeric_limits<_Tp>::infinity();
else
  {
__x /= __amax;
__y /= __amax;
__z /= __amax;
return __amax * std::sqrt(__x * __x + __y * __y + __z * __z);
  }
  }
  }
  }

I get your point about scaling and adding smallest first.  I have access to
std::fma().

For me I think this means:
/*
  const auto __amax = max(max(__x, __y), __z);
  const auto __l0 = min(__z, max(__x, __y));
  const auto __l1 = min(__y, __x);

  const auto __scale = 1 / __amax;

  __l0 *= __scale;
  __l1 *= __scale;
  // Add the two smaller values first.
  const auto __lo = __l0 * __l0 + __l1 * __l1;
  const auto __r  = __amax * sqrt(fma(__h1, __h1, __lo));

*/

[Bug fortran/88190] compile_options.allow_std does not allow to distinguish between GFC_STD_GNU and GFC_STD_LEGACY

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Any further thoughts on this?

[Bug fortran/88653] Is this a compiler bug?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Jerry DeLisle  ---
I am getting a fail on FM308.f:

54   PASS
55   PASS
56   PASS
57   PASS
58   PASS
59   PASS
60   PASS
61   PASS
62   PASS
63   FAIL 0.88000E+000.0E+00

  --

 END OF PROGRAM FM308

1 TESTS FAILED
   31 TESTS PASSED
0 TESTS DELETED

This is with my original test files and test script. So I do think something is
wrong. Test 63 is:

C   FCVS PROGRAM 308  -  TEST 063  
08640308
C  
08650308
C TEST 063 ATTEMPTS TO OVERRIDE THE TYPING OF INTEGER FOR THE  
08660308
C INTRINSIC FUNCTION MAX1 WITH TYPE-STATEMENT TYPING OF REAL.  
08670308
C  
08680308

Didn't someone just do some work on MAX1?

[Bug target/88616] [9 Regression] ICE in gimplify_expr at gcc/gimplify.c:13363

[raj.khem at gmail dot com]

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

--- Comment #4 from Khem Raj  ---
I am seeing similar ICE when compiling QT 5.12 on armhf, I have a un-reduced
case but I think its same problem. Since the reduced case fails with my built
gcc as well, I can test it out once a fix is available.

[Bug ipa/88702] New: [6/7/8 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox

[hubicka at gcc dot gnu.org]

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

Bug ID: 88702
   Summary: [6/7/8 regression] We do terrible job optimizing
IsHTMLWhitespace from Firefox
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

compiling:

int IsHTMLWhitespace(int aChar) { 
  return aChar == 0x0009 || aChar == 0x000A ||  
 aChar == 0x000C || aChar == 0x000D ||  
 aChar == 0x0020; 
}
q(int a,int b, int c)
{
  return IsHTMLWhitespace (a) && IsHTMLWhitespace (b) && IsHTMLWhitespace (c);
}

we do quite funny things by ipa-splitting IsHTMLWhitespace:

IsHTMLWhitespace (int aChar)
{
  unsigned int aChar.1_1;
  unsigned int _2;
  _Bool _3;
  _Bool _4;
  _Bool _5;
  int iftmp.0_6;
  int iftmp.0_8;

   [100.00%]:
  aChar.1_1 = (unsigned int) aChar_7(D);
  _2 = aChar.1_1 + 4294967287;
  _3 = _2 <= 1;
  _4 = aChar_7(D) == 12;
  _5 = _3 | _4;
  if (_5 != 0)
goto ; [46.00%]
  else
goto ; [54.00%]

   [54.00%]:
  iftmp.0_8 = IsHTMLWhitespace.part.0 (aChar_7(D));

   [100.00%]:
  # iftmp.0_6 = PHI <1(2), iftmp.0_8(3)>
  return iftmp.0_6;

}

this is partly caused by the fact that we are not able to optimize early the
sequence of compares to shift. In Firefox later we fail to inline the functions
and produce some terrible code which slows down rerf-reftest/dep-check-1.html
Firefox benchmark

[Bug c/88701] [9 Regression] Internal compiler error for valid program using compound literal with variably modified type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
Thanks for the bisect.

[Bug c/88701] [9 Regression] Internal compiler error for valid program using compound literal with variably modified type.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r259641.

[Bug c++/88699] [9 Regression] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 CC||jakub at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Indeed, started with r267096.

[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

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
A similar sentiment is also shared within WG14.  See item 12 in section 6.1 of
the last meeting minutes for the two options under consideration (remove or
fix): http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2307.pdf.  Since there
is no proposal for fixing the problems it's unclear how it might impact the
APIs.  Until that's resolved, implementing support for the current API would be
risky.

In the meantime, the C++ proposal for contracts has gained strong support and
might provide a superior alternative.

[Bug c/88701] [9 Regression] Internal compiler error for valid program using compound literal with variably modified type.

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-04
   Target Milestone|--- |9.0
Summary|Internal compiler error for |[9 Regression] Internal
   |valid program using |compiler error for valid
   |compound literal with   |program using compound
   |variably modified type. |literal with variably
   ||modified type.
 Ever confirmed|0   |1

--- Comment #2 from Joseph S. Myers  ---
Does not appear with GCC 8 branch, so a regression, can someone bisect to find
what commit introduced this ICE?

internal compiler error: in get_parm_info, at c/c-decl.c:7517
0x5992b3 get_parm_info(bool, tree_node*)
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-decl.c:7517
0x7e92e7 c_parser_parms_list_declarator
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:4024
0x7e9403 c_parser_parms_declarator
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:3939
0x7e2ae9 c_parser_direct_declarator_inner
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:3868
0x7f8ead c_parser_declaration_or_fndef
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:1999
0x800bef c_parser_external_declaration
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:1653
0x801611 c_parser_translation_unit
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:1534
0x801611 c_parse_file()
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:19807
0x853afb c_common_parse_file()
/scratch/jmyers/fsf/gcc-mainline/gcc/c-family/c-opts.c:1151
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/88700] C11 Annex K builtins

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
Consensus in glibc is that Annex K is badly designed and should not be 
supported at all.  See 
 proposing 
obsoletion or removal.

[Bug c/88701] Internal compiler error for valid program using compound literal with variably modified type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Another test case that also gives internal compiler error with the same
compilation command line:

  void f(int n, int [(int (*)[n]) { 0 } == 0]);

  int main()
  {
  }

[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Fri Jan  4 22:48:45 2019
New Revision: 267583

URL: https://gcc.gnu.org/viewcvs?rev=267583=gcc=rev
Log:
PR c/88363 - alloc_align attribute doesn't accept enumerated arguments

gcc/c-family/ChangeLog:

PR c/88363
* c-attribs.c (positional_argument): Also accept enumerated types.

gcc/testsuite/ChangeLog:

PR c/88363
* c-c++-common/attributes-4.c: New test.

gcc/ChangeLog:

PR c/88363
* doc/extend.texi (attribute alloc_align, alloc_size): Update.


Added:
trunk/gcc/testsuite/c-c++-common/attributes-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-attribs.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug c/88701] New: Internal compiler error for valid program using compound literal with variably modified type.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88701
   Summary: Internal compiler error for valid program using
compound literal with variably modified type.
   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):

  void f(int [(int (*)[*]) { 0 } == 0]);

  int main()
  {
  }

Compilation command line:

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

Observed behaviour:

  Internal compiler error.

[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed in r267583.

[Bug c/88700] C11 Annex K builtins

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this should be implemented in glibc rather than GCC first.

[Bug c/88700] New: C11 Annex K builtins

[jg at jguk dot org]

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

Bug ID: 88700
   Summary: C11 Annex K builtins
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Would GCC consider adding C11 Annex K safe functions as builtins?
I feel they would be very useful. Currently only we use them on MSCV builds.

Clang is thinking of adding these bultins - this is where the thread began
http://lists.llvm.org/pipermail/cfe-dev/2016-February/047149.html

As JF explains, they can just wrap regular builtins
(memcpy_s, memmove_s, strcpy_s, strncpy_s, strcat_s, strncat_s, strtok_s,
memset_s, strerror_s, strerrorlen_s, strnlen_s)

Saw this list of current GCC builtins
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html


glibc "stdint.h" would need this adding as well - should I open a glibc ticket
for that proposed change?

My code below:

#ifdef (__STDC_WANT_LIB_EXT1__)
#if __STDC_WANT_LIB_EXT1__ >= 1
#define RSIZE_MAX (SIZE_MAX >> 1)

#endif
#endif

[Bug target/88638] [9 Regression] FAIL: *string-format-1.* on darwin

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
I submitted the patch below for review.  Dominique, if you have an opportunity
to test it on Darwin and let me know if there are any outstanding problems that
would be great.
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00181.html

[Bug d/88654] Hangs in libphobos testsuite

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #4)
> 
> My i686-linux bootstraps are done through a couple of executable scripts in
> ~/hbin directory on x86_64-linux:
> for i in ~/hbin/*; do echo ===$i===; cat $i; done
> ===/home/jakub/hbin/as===
> #!/bin/sh
> exec /usr/bin/as --32 "$@"
> ===/home/jakub/hbin/g++===
> #!/bin/sh
> exec /usr/bin/g++ -m32 "$@"
> ===/home/jakub/hbin/gcc===
> #!/bin/sh
> exec /usr/bin/gcc -m32 "$@"
> ===/home/jakub/hbin/ld===
> #!/bin/sh
> case "$*" in
>   --version) cat <<\EOF
> GNU ld version 2.20.52.0.1-10.fc17 20100131
> Copyright 2012 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
> EOF
>   exit 0;;
> esac
> exec /usr/bin/ld -m elf_i386 -L /usr/lib/ "$@"
> 
> and then
> PATH=~/hbin:$PATH i386 ../configure
> --enable-languages=default,obj-c++,lto,go,brig,d
> --enable-checking=yes,rtl,extra \
> && PATH=~/hbin:$PATH i386 make -j32 bootstrap > LOG 2>&1 \
> && PATH=~/hbin:$PATH i386 make -j32 -k check > LOGC 2>&1; \
> ../contrib/test_summary > LOGT 2>&1
> and that got stuck forever if libcurl.i?86 wasn't installed (only
> libcurl.x86_64 and libcurl-devel.x86_64), but works
> fine now that I also have libcurl.i?86 installed.
> 

I can't say I followed this to the letter, but I could not reproduce.

RUNTESTFLAGS="unittests.exp" LIBRARY_PATH=/usr/lib32 PATH=~/hbin:$PATH \
  i386 make check -j8; \
  ../contrib/test_summary


Naturally, the libphobos testsuite took over 660 seconds to finish.  But still
it eventually ended.

Going to deal with [2] and [3] anyway to prevent hitting the timeout in the
first place anyway.

[Bug c++/88699] [9 Regression] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|tree check fail: expected   |[9 Regression] tree check
   |function_decl, have |fail: expected
   |using_decl in add_method,   |function_decl, have
   |at cp/class.c:1137  |using_decl in add_method,
   ||at cp/class.c:1137

[Bug c++/88699] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
Most likely started with r267096.

[Bug target/88188] ICE in print_operand, at config/rs6000/rs6000.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Not worth backporting IMHO.

[Bug lto/48200] Implement function attribute for symbol versioning (.symver)

[fw at gcc dot gnu.org]

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

--- Comment #28 from Florian Weimer  ---
It seems that using symbol aliases (via .symver) in conjunction with LTO and a
version script which has a local: * clause causes the LTO plugin to assume that
the aliased function definitions are not (externally) referenced, so GCC will
elide them.  The workaround for now appears to be to put __attribute__
((externally_visible)) on the aliased functions, so that GCC assumes that there
is a reference to them that it cannot see.

-flto-partition=none may also be needed.

[Bug c++/88699] tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Bug seems to start someplace between revision 266950 and 267100.

[Bug c++/88699] New: tree check fail: expected function_decl, have using_decl in add_method, at cp/class.c:1137

[dcb314 at hotmail dot com]

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

Bug ID: 88699
   Summary: tree check fail: expected function_decl, have
using_decl in add_method, at cp/class.c:1137
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 45347
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45347=edit
gzipped C++ source code

For the attached C++ code, with recent gcc trunk, I get this:

$ ~/gcc/results/bin/gcc -c -w bug492.cc
bug492.cc:145738:16: internal compiler error: tree check: expected
function_decl, have using_decl in add_method, at cp/class.c:1137
145738 | class Mat::fixed : public Mat
   |^
0x7bbfe5 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9811
0x5e5f3d tree_check(tree_node*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3176
0x5e5f3d add_method(tree_node*, tree_node*, bool)
../../trunk/gcc/cp/class.c:1137
0x8a4ac1 finish_struct(tree_node*, tree_node*)
../../trunk/gcc/cp/class.c:7149

I'll have my usual go at reducing the code and providing a range
of revisions where I think gcc trunk has gone wrong.

[Bug c/88698] Relax generic vector conversions

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
It would help if you could write some (very short) functions illustrating the
behavior you are requesting. "convert", "compatible" all depend about the
context in which they appear.

[Bug c++/87364] Pretty print of enumerator never prints the id, always falls back to C-style cast output

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Will Wray from comment #4)
> I reckon that demangling is the cause of the spurious warning.
> It seems that demangle continues to output enums with C-style cast:
> 
>   template type  TreeVector::Tree
>demangles as  TreeVector::Tree
> 
> Is this demangle angle a red-herring?
> Is the C-style cast mandated by Itanium CXXABI for enum output?

The ABI doesn't mandate how exactly it is demangled, but there is nothing in
the mangled name that would allow it to be demangled as E::a or a.
E.g. with

enum E { a = 0, b = 1 };
template 
const char *foo (void) { return __PRETTY_FUNCTION__; }
void bar (void) { foo  (); foo  (); }

the mangled names are _Z3fooIL1E0EEPKcv and _Z3fooIL1E1EEPKcv and that is what
the ABI says; there is no way to recover that 0 is a and 1 is b.
__PRETTY_FUNCTION__ is const char* foo() [with E e = a] etc. (previously this
was [with E e = (E)0] ).  Similarly, in .debug_info, DW_AT_name for the
functions used to be foo<(E)0> and now is foo.

> Is demangler code even able to look up enumerators?

No.

> (I mean, does it have access to sufficient type information).

Demangler works just on a string, it doesn't have access to debuginfo etc.

I'd say we should revert to what we used to do when emitting stuff for RTTI or
debug info and do what your patch does only for compiler diagnostics.
Unlike the enumerator ids, the casts with exact constants are much easier to
handle for tools that don't have always full context.

[Bug c/88698] New: Relax generic vector conversions

[husseydevin at gmail dot com]

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

Bug ID: 88698
   Summary: Relax generic vector conversions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: husseydevin at gmail dot com
  Target Milestone: ---

GCC is far too strict about vector conversions. 

Currently, mixing generic vector extensions and platform-specific intrinsics
almost always requires either a cast or -flax-vector-extensions, which is
annoying and breaks a lot of things Clang happily accepts.

Here is my proposal:
* x86's __mNi should implicitly convert between any N-bit vector. This matches
the void pointer-like behavior of SSE's vectors.
* Any vector with equivalent lane types and number of lanes should convert
without an issue. For example, uint32_t vector_size(16) and NEON's uint32x4_t
have no reason not to be compatible. 
* Signed <-> unsigned should act like other implicit signed <-> unsigned
conversions, -Wextra in C and warning in C++.
* Implicit conversions between different vectors of the same size should emit
an error.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #6 from Anders Granlund  ---
Thanks for the explanation.

[Bug testsuite/88697] New: New test case gcc.target/powerpc/pr88457.c in r267307 fails because of glibc requirement

[seurer at gcc dot gnu.org]

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

Bug ID: 88697
   Summary: New test case gcc.target/powerpc/pr88457.c in r267307
fails because of glibc requirement
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

It is failing because it requires GLIBC 2.23 and newer and some (most) of our
test machines don't have that.  

This sort of thing has come up before and I don't think anyone has ever come up
with a clean solution for it.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88457.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -m32 -mcpu=power7 -O1 -fexpensive-optimizations
--param ira-max-conflict-table-size=0 --param max-cse-insns=3 -c -mcpu=e300c3
-S -o pr88457.s
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88457.c:6:6:
error: target_clones attribute needs GLIBC (2.23 and newer) that exports
hardware capability bits
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88457.c:6:6:
error: default 'target_clones' attribute was not set
compiler exited with status 1
FAIL: gcc.target/powerpc/pr88457.c (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88457.c:6:6:
error: target_clones attribute needs GLIBC (2.23 and newer) that exports
hardware capability bits
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr88457.c:6:6:
error: default 'target_clones' attribute was not set

[Bug fortran/88653] Is this a compiler bug?

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
I have my eye on this one folks.

[Bug target/88640] ICE in mark_reachable_handlers, at tree-eh.c:3926

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
-Ofast -fsignaling-nans is a really weirdo combination of options, it says that
NaNs aren't honored, but sNaNs are, so in this case it folds a _7 = 1.0 * _2
that is marked that could throw into just _7 = _2; which can't throw (because
HONOR_SNANS is false due to HONOR_NANS being false).

Anyway, the ICE is because recip does:
  gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
  gimple_assign_set_rhs_code (stmt, MULT_EXPR);
  fold_stmt_inplace ();
  update_stmt (stmt);
and fold_stmt_inplace doesn't do maybe_clean_eh_stmt and the caller
(tree-ssa-math-opts.c has many similar spots) don't do either.  Or during
analysis phase of these optimizations we should just punt if any relevant stmts
can throw.

[Bug target/88696] New: Power VSX builtins missing vmuluwm / vector int vec_mul (vector int, vector int);

[cand at gmx dot com]

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

Bug ID: 88696
   Summary: Power VSX builtins missing vmuluwm / vector int
vec_mul (vector int, vector int);
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cand at gmx dot com
  Target Milestone: ---
Target: ppc64le

Seems gcc is currently missing the VSX built-in that multiplies int vectors.
The vmuluwm instruction seems otherwise supported by gcc codegen.

vector int vec_mul (vector int, vector int);
vector unsigned int vec_mul (vector unsigned int, vector unsigned int);

It was added in ISA 2.07 aka POWER8. Apologies if the "target" component is not
the right place for this.

[Bug libstdc++/85517] std::variant exception safety problems

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Xiaoyi Zhang from comment #0)
> 2. Conversion assignment operator=(T&&)
> According to [variant.assign] 23.7.3.3 (11.3): if
> is_nothrow_constructible == false &&
> is_nothrow_move_constructible == true, equivalent to
> operator=(variant(std::forward(t))).
> 
> Failure case: If Tj has a nothrow move constructor, the standard requires
> strong guarantee (that a temporary variant be created first and move it into
> *this). The current implementation always invokes emplace(), which has only
> basic guarantee.

My patch on PR 87431 comment 10 fixes this, by giving emplace the strong
guarantee for such types.

[Bug target/84010] problematic TLS code generation on 64-bit SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
(> So, as far as I see it, we have two choices:
> 
> 1. Disable all X -> LE relaxations in the linker. Works, but then gives
> suboptimal performance if some code linked into an executable is built with
> -fPIC rather than -fPIE (or nothing).

At least we could implement the possibility, even if not enabled by default.
See PR binutils/22740.

> 2. Apply this patch to GCC (assuming it still applies cleanly...).

Don't worry, the SPARC back-end doesn't move that fast. ;-)

> I'm struggling to understand what you meant by "relaxation is required in
> all cases"; did you mean *forbidden* in all cases (i.e. my point 1)?

Required in all cases to have a bug in the final code.

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Maybe like this:

--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -439,7 +439,7 @@ namespace __variant
   constexpr bool
   _M_valid() const noexcept
   {
-   if constexpr ((is_scalar_v<_Types> && ...))
+   if constexpr ((is_trivially_copyable_v<_Types> && ...))
  return true;
return this->_M_index != __index_type(variant_npos);
   }
@@ -1185,6 +1185,23 @@ namespace __variant
{
  static_assert(_Np < sizeof...(_Types),
"The index should be in [0, number of alternatives)");
+
+ using type = variant_alternative_t<_Np, variant>;
+ // If constructing the value can throw but move assigning it can't,
+ // construct in a temporary and then move assign from it. This gives
+ // the strong exception safety guarantee, ensuring we never become
+ // valueless.
+ if constexpr (is_trivially_copyable_v
+ && !is_nothrow_constructible_v)
+   {
+ // If move assignment cannot throw then we can provide the
+ // strong exception safety guarantee, and never become valueless.
+ variant __tmp(in_place_index<_Np>,
+   std::forward<_Args>(__args)...);
+ *this = std::move(__tmp);
+ return std::get<_Np>(*this);
+   }
+
  this->~variant();
  __try
{
@@ -1208,6 +1225,20 @@ namespace __variant
{
  static_assert(_Np < sizeof...(_Types),
"The index should be in [0, number of alternatives)");
+
+ using type = variant_alternative_t<_Np, variant>;
+ if constexpr (is_trivially_copyable_v
+ && !is_nothrow_constructible_v,
+_Args...>)
+   {
+ // If move assignment cannot throw then we can provide the
+ // strong exception safety guarantee, and never become valueless.
+ variant __tmp(in_place_index<_Np>, __il,
+   std::forward<_Args>(__args)...);
+ *this = std::move(__tmp);
+ return std::get<_Np>(*this);
+   }
+
  this->~variant();
  __try
{

[Bug target/84010] problematic TLS code generation on 64-bit SPARC

[jrtc27 at jrtc27 dot com]

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

--- Comment #11 from James Clarke  ---
(In reply to Eric Botcazou from comment #9)
> > There are similar problems for other TLS models which can be relaxed, but
> > even worse than this, local dynamic uses a sethi/xor for the offset from the
> > defining module's block to load a signed 32-bit value, but since it's marked
> > as SI I assume a spill/reload will truncate the top 32 bits and thus lose
> > any sign extension if it's negative, breaking it even with linker relaxation
> > disabled.
> 
> It turns out that this sethi/xor pair cannot generate a negative value
> according to the calculation formulas of R_SPARC_TLS_LDO_HIX22 &
> R_SPARC_TLS_LDO_LOX10 available at
> https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html
> 
> So, if the above formulas are [correct], relaxation is required in all cases.

Yes, for Local Dynamic itself, the offset will always be positive, since it's
the offset from the start of that module's TLS block. However, *all* TLS
models, including Local Dynamic, can currently be relaxed to Local Exec on
SPARC, which always generates negative offsets (Variant II, so static TLS
blocks come just before TP).

So, as far as I see it, we have two choices:

1. Disable all X -> LE relaxations in the linker. Works, but then gives
suboptimal performance if some code linked into an executable is built with
-fPIC rather than -fPIE (or nothing).

2. Apply this patch to GCC (assuming it still applies cleanly...).

I'm struggling to understand what you meant by "relaxation is required in all
cases"; did you mean *forbidden* in all cases (i.e. my point 1)?

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE  Uni-Bielefeld.DE> ---
[...]
> I may try a build on Solaris 10 with the snv_121 assembler myself.
> The sparc machine is busy until tomorrow night; I may try a Solaris
> 10/x86 build instead since you say you're seeing the same error there.

I've now completed c,c++-only bootstraps of gcc 7.4.0 with the snv_121
as on Solaris 10/SPARC and x86 without issues, using a self-compiled gcc
4.9.0 as bootstrap compiler.

Which brings me back to a previous suggestion: please try bootstrapping
a vanilla gcc 4.9.x yourself and use the result to build gcc
7.3.0/7.4.0.

[Bug c/88695] Accepts invalid program with incompatible function types.

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
It's DR#316 that's relevant here (where the committee agreed with my 
interpretation that implies this example is valid, and reiterated their 
intent not to fix issues with unprototyped functions in the standard), not 
DR#317.

[Bug d/88654] Hangs in libphobos testsuite

[ibuclaw at gdcproject dot org]

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

--- Comment #5 from Iain Buclaw  ---
(In reply to Jakub Jelinek from comment #4)
> 
> If the test doesn't fail if it fails to load libcurl (and doesn't get
> stuck), it is fine too.
> If it fails if it is missing, yeah, something like a tcl procedure somewhere
> in libphobos/testsuite/lib/*.exp would do.
> As libphobos itself doesn't need libcurl-devel, it is just dlopen, so I
> think you want to test that
> #include 
> 
> int
> main ()
> {
>   void *h = dlopen ("libcurl.so.4"); // etc., whatever the library will try
> to dlopen
>   ...
> }
> will succeed dlopening it.


The names it will try before giving up:

---
version (OSX)
static immutable names = ["libcurl.4.dylib"];
else version (Posix)
{
static immutable names = ["libcurl.so", "libcurl.so.4",
"libcurl-gnutls.so.4", "libcurl-nss.so.4", "libcurl.so.3"];
}
else version (Windows)
static immutable names = ["libcurl.dll", "curl.dll"];
---

I think a link test would be good enough, as iff curl exists, but it has a
different name to any of the above, then the std.net.curl module needs fixing.

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Fri, 4 Jan 2019, jakub at gcc dot gnu.org wrote:

> Joseph, is there any meaning for DECL_EXTERNAL & TREE_STATIC, or is that
> invalid flag combination?  If the latter, we should go with the latter patch,
> but I'm afraid I have no access to Windows and no way to test.

I think a gnu_inline function definition is both DECL_EXTERNAL and 
TREE_STATIC.

[Bug c++/88694] constexpr isn't captured correctly in lambda

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-04
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase with no headers, clang++ -std=c++17 accepts this.

template  struct A {
  static constexpr T e = U;
  constexpr operator int () { return e; }
};
template  struct B {};
template 
using C
#ifdef __clang__
  = __make_integer_seq;
#else
  = B;
#endif
template 
void foo (U f, B) { (f (A{}), ...); }
template 
void bar (U f) { foo (f, C{}); }
struct D { template  void print (); };

int
main ()
{
  D d;
  bar ([&](auto i) { auto x = [&] { d.print(); }; });
}

Older versions of g++ reject it with
‘__closure’ is not a constant expression
instead and before r248384 it is rejected because __integer_pack hasn't been
implemented.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to jos...@codesourcery.com from comment #1)
> 6.3.2.1#2 (conversion of lvalues to rvalues): "If the lvalue has an 
> incomplete type and does not have array type, the behavior is undefined.".  
> Cf. bug 36941 (noting how DR#106 confuses things by allowing dereferences 
> of pointers to qualified void).

(Incorrectly added an additional comment instead of replying)

What about this modified test case?

  struct S *p;

  void f(void);

  int main()
  {
f();

&*p;
  }

  struct S { int x; };

  void f()
  {
static struct S s = { 0 };
p = 
  }

It gives the same error message (using the same compilation command line), and
there is no lvalue to rvalue conversion of *p in this case, because of the
operator & .

Clang accept that test case without any errors.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

--- Comment #4 from Anders Granlund  ---
(In reply to Jonathan Wakely from comment #2)
> See PR 64526 and DR 317.

(Forgot to reply instead of adding an additional comment)

Yes, the type of  f  does have a prototype.

That fact is however not relevant here.

Note that I'm not making any calls to  f  here. I am only using  f  in a way
that requires its type to be compatible with  void (int) .

The prototype mentioned in 6.7.3/15 refers to the prototype of the type  void
(int)  in this case.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

--- Comment #3 from Anders Granlund  ---
Yes, the type of  f  does have a prototype.

That fact is however not relevant here.

Note that I'm not making any calls to  f  here. I am only using  f  in a way
that requires its type to be compatible with  void (int) .

The prototype mentioned in 6.7.3/15 refers to the prototype of the type  void
(int)  in this case.

[Bug c/87964] c-attribs.c:3965: possible cut'n'paste error ?

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|8.0 |9.0
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
The typo was introduced in r265980 (GCC 9) and has been fixed in r266335.

[Bug c/88363] [9 Regression] alloc_align attribute doesn't accept enumerated arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00740.html

[Bug target/84010] problematic TLS code generation on 64-bit SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
> So, if the above formulas are incorrect, relaxation is required in all cases.

...are correct...

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[wilco at gcc dot gnu.org]

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

--- Comment #11 from Wilco  ---
(In reply to Jakub Jelinek from comment #10)
> If the compiler knew say from PGO that pos is usually a multiple of certain
> power of two and that the loop usually iterates many times (I guess the
> latter can be determined from comparing the bb count of the loop itself and
> its header), it could emit something like:
> static int func2(int max, int pos, unsigned char *cur)
> {
>   unsigned char *p = cur + pos;
>   int len = 0;
>   if (max > 32 && (pos & 7) == 0)
> {
>   int l = ((1 - ((uintptr_t) cur)) & 7) + 1;
>   while (++len != l)
> if (p[len] != cur[len])
>   goto end;
>   unsigned long long __attribute__((may_alias)) *p2 = (unsigned long
> long *) [len];
>   unsigned long long __attribute__((may_alias)) *cur2 = (unsigned long
> long *) [len];
>   while (len + 8 < max)
> {
>   if (*p2++ != *cur2++)
> break;
>   len += 8;
> }
>   --len;
> }
>   while (++len != max)
> if (p[len] != cur[len])
>   break;
> end:
>   return cur[len];
> }
> 
> or so (untested).  Of course, it could be done using SIMD too if there is a
> way to terminate the loop if any of the elts is different and could be done
> in that case at 16 or 32 or 64 characters at a time etc.
> But, without knowing that pos is typically some power of two this would just
> waste code size, dealing with the unaligned cases would be more complicated
> (one can't read the next elt until proving that the current one is all
> equal), so it would need to involve some rotations (or permutes for SIMD).

Given it is compressing data both pointers will typically be misaligned. Pos
would be fairly random and len does not usually start from zero either. And
it's highly unlikely it will iterate more than a few bytes. Compression matches
are typically just a few bytes long. So unrolling is the only useful
optimization for this kind of code.

[Bug target/84010] problematic TLS code generation on 64-bit SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  ---
> There are similar problems for other TLS models which can be relaxed, but
> even worse than this, local dynamic uses a sethi/xor for the offset from the
> defining module's block to load a signed 32-bit value, but since it's marked
> as SI I assume a spill/reload will truncate the top 32 bits and thus lose
> any sign extension if it's negative, breaking it even with linker relaxation
> disabled.

It turns out that this sethi/xor pair cannot generate a negative value
according to the calculation formulas of R_SPARC_TLS_LDO_HIX22 &
R_SPARC_TLS_LDO_LOX10 available at
https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html

So, if the above formulas are incorrect, relaxation is required in all cases.

[Bug target/88027] PowerPC generates slightly weird code for memset

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from acsawdey at gcc dot gnu.org ---
Backport to 8 tested ok and is now checked in as 267580.

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

[samtebbs at gcc dot gnu.org]

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

--- Comment #10 from Sam Tebbs  ---
Author: samtebbs
Date: Fri Jan  4 16:26:38 2019
New Revision: 267579

URL: https://gcc.gnu.org/viewcvs?rev=267579=gcc=rev
Log:
[PATCH][GCC][Aarch64] Change expected bfxil count in
gcc.target/aarch64/combine_bfxil.c to 18 (PR/87763)

gcc/testsuite/Changelog:

2019-01-04  Sam Tebbs  

PR gcc/87763
* gcc.target/aarch64/combine_bfxil.c: Change scan-assembler-times bfxil
count to 18.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/gcc.target/aarch64/combine_bfxil.c

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
If the compiler knew say from PGO that pos is usually a multiple of certain
power of two and that the loop usually iterates many times (I guess the latter
can be determined from comparing the bb count of the loop itself and its
header), it could emit something like:
static int func2(int max, int pos, unsigned char *cur)
{
  unsigned char *p = cur + pos;
  int len = 0;
  if (max > 32 && (pos & 7) == 0)
{
  int l = ((1 - ((uintptr_t) cur)) & 7) + 1;
  while (++len != l)
if (p[len] != cur[len])
  goto end;
  unsigned long long __attribute__((may_alias)) *p2 = (unsigned long long
*) [len];
  unsigned long long __attribute__((may_alias)) *cur2 = (unsigned long long
*) [len];
  while (len + 8 < max)
{
  if (*p2++ != *cur2++)
break;
  len += 8;
}
  --len;
}
  while (++len != max)
if (p[len] != cur[len])
  break;
end:
  return cur[len];
}

or so (untested).  Of course, it could be done using SIMD too if there is a way
to terminate the loop if any of the elts is different and could be done in that
case at 16 or 32 or 64 characters at a time etc.
But, without knowing that pos is typically some power of two this would just
waste code size, dealing with the unaligned cases would be more complicated
(one can't read the next elt until proving that the current one is all equal),
so it would need to involve some rotations (or permutes for SIMD).

[Bug tree-optimization/88693] [9 Regression] Wrong code since r263018

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug tree-optimization/88567] [9 Regression] ICE in get_initial_defs_for_reduction when building 521.wrf_r on AArch64 SVE

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Created attachment 45345
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45345=edit
Candidate patch

I'll test the attached over the weekend.  Seems to pass initial spot-testing.

[Bug tree-optimization/88398] vectorization failure for a small loop to do byte comparison

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
For context, this is the hot loop in 557.xz_r from SPEC2017

[Bug c/64526] No warning on function call with excessive arguments

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|RESOLVED|NEW
   Last reconfirmed||2019-01-04
 Resolution|INVALID |---
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #6 from Jonathan Wakely  ---
Reopening as a request for a warning.

[Bug other/88691] Add support for -fuse-ld=lld (https://lld.llvm.org/)

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #1 from Eric Gallager  ---
This has already been done. Dup of bug 83243.

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

[Bug driver/83243] -fuse-ld=lld

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dilyan.palauzov at aegee dot 
org

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

[Bug c/88695] Accepts invalid program with incompatible function types.

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
See PR 64526 and DR 317.

[Bug c/88695] Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

--- Comment #1 from Anders Granlund  ---
Correction:

The second standard reference should be 6.7.6.3/15 and not 6.7.3/15.

[Bug fortran/88685] [8/9 regression] pointer class array argument indexing

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Fri, Jan 04, 2019 at 09:40:52AM +, antony at cosmologist dot info wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
> 
> --- Comment #2 from Antony Lewis  ---
> I think the individual elements are correct, it's the array indexing 
> operations
> that are wrong (this is clearer in the longer example; looks a like wrong
> stride). E.g. printing this in the main program after calling doit
> 

Ah, yeah, that is what my small change to doit() shows.

[Bug c/88695] New: Accepts invalid program with incompatible function types.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88695
   Summary: Accepts invalid program with incompatible function
types.
   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):

  void f()
  {
  }

  int main()
  {
void (*g)(int) = 0;
 == g;
  }

Compilation command line:

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

Observed behaviour:

  No error messages outputed.

Expected behaviour:

  An error message outputed.

  The program is invalid due to the following paragraphs of the standard:

  6.5.9/2:

  "One of the following shall hold:
   —  both operands have arithmetic type;
   —  both operands are pointers to qualified or unqualified versions of
  compatible types;
   —  one operand is a pointer to an object type and the other is a pointer to
a 
  qualified or unqualified version of void; or
   —  one operand is a pointer and the other is a null pointer constant."

  6.7.3/15:

  "... If one type has a parameter type list and the other type is specified by
   a function definition that contains a (possibly empty) identifier list, both
   shall agree in the number of parameters, and the type of each prototype
   parameter shall be compatible with the type that results from the
application
   of the default argument promotions to the type of the corresponding
   identifier. ..."

[Bug tree-optimization/88567] [9 Regression] ICE in get_initial_defs_for_reduction when building 521.wrf_r on AArch64 SVE

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
BTW, turns out that this is the same ICE as gcc.dg/vect/pr63379.c,
which was on my list of things to look at in stage 4.

[Bug tree-optimization/88693] [9 Regression] Wrong code since r263018

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[9 Regression] Wrong code   |[9 Regression] Wrong code
   |since r263511   |since r263018
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The actual bug is earlier, it is not a FE bug, but tree-ssa-strlen.c bug,
caused by r263018 change.

__attribute__((noipa)) void
foo (char *p)
{
  if (__builtin_strlen (p) != 9)
__builtin_abort ();
}

int
main ()
{
  static unsigned char u[9] = "abcdefghi";
  char b[100];
  __builtin_memcpy (b, u, sizeof (u));
  b[sizeof (u)] = 0;
  foo (b);
  return 0;
}

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #10)
> So, is this actually a regression?  I.e. is there a testcase that fails with
> trunk?

I believe this issue is latent on trunk.

[Bug tree-optimization/88567] [9 Regression] ICE in get_initial_defs_for_reduction when building 521.wrf_r on AArch64 SVE

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-04
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
I'll take a look.

[Bug c/88568] [7/8/9 Regression] 'dllimport' no longer implies 'extern' in C

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org,
   ||jyong at gcc dot gnu.org
Summary|[8/9 Regression]|[7/8/9 Regression]
   |'dllimport' no longer   |'dllimport' no longer
   |implies 'extern' in C   |implies 'extern' in C

--- Comment #3 from Jakub Jelinek  ---
Guess it regressed with the PR24293 change then.

I think the problem is that handle_dll_attribute has for dllimport on
VAR_DECLs:
  /* `extern' needn't be specified with dllimport.
 Specify `extern' now and hope for the best.  Sigh.  */
  DECL_EXTERNAL (node) = 1;
  /* Also, implicitly give dllimport'd variables declared within
 a function global scope, unless declared static.  */
  if (current_function_decl != NULL_TREE && !TREE_STATIC (node))
TREE_PUBLIC (node) = 1;
The problem is that the decl is previously TREE_STATIC and TREE_PUBLIC and
setting it also DECL_EXTERNAL results in an unusual combination of flags.

So, either we can tweak the code reporting the issues and hope TREE_STATIC &&
DECL_EXTERNAL means something reasonable elsewhere:

--- gcc/c/c-decl.c.jj   2019-01-01 12:37:48.628458597 +0100
+++ gcc/c/c-decl.c  2019-01-04 15:13:03.281213304 +0100
@@ -5100,7 +5100,8 @@ finish_decl (tree decl, location_t init_
   if ((RECORD_OR_UNION_TYPE_P (TREE_TYPE (decl))
  || TREE_CODE (TREE_TYPE (decl)) == ENUMERAL_TYPE)
  && DECL_SIZE (decl) == NULL_TREE
- && TREE_STATIC (decl))
+ && TREE_STATIC (decl)
+ && !DECL_EXTERNAL (decl))
incomplete_record_decls.safe_push (decl);

   if (is_global_var (decl) && DECL_SIZE (decl) != NULL_TREE)

or we should change handle_dll_attribute to:

--- gcc/attribs.c   2019-01-01 12:37:18.066960036 +0100
+++ gcc/attribs.c   2019-01-04 15:41:55.949812827 +0100
@@ -1691,6 +1691,7 @@ handle_dll_attribute (tree * pnode, tree
 a function global scope, unless declared static.  */
  if (current_function_decl != NULL_TREE && !TREE_STATIC (node))
TREE_PUBLIC (node) = 1;
+ TREE_STATIC (node) = 0;
}

   if (*no_add_attrs == false)

Joseph, is there any meaning for DECL_EXTERNAL & TREE_STATIC, or is that
invalid flag combination?  If the latter, we should go with the latter patch,
but I'm afraid I have no access to Windows and no way to test.

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
So, is this actually a regression?  I.e. is there a testcase that fails with
trunk?

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Jeffrey A. Law from comment #8)
> That's an indication you've likely done something wrong with your local
> properties HJ.  LCM inherently also does LICM since LICM is just a special
> case of PRE.

The LCM algorithm isn't appropriate here since it may place a vxorps
inside the loop.  Simple testcase show this:

$ cat badcase.c

extern float f;
extern double d;
extern int i;

void
foo (int n, int k)
{
  for (int j = 0; j != n; j++)
if (j < k)
  d = f;
}

It generates

...
loop:
  if(j < k)
vxorps  %xmm0, %xmm0, %xmm0
vcvtss2sd  %xmm1, %xmm0, %xmm0
  ...
loopend
...

This is because LCM only works when there is a certain benifit.  But for
conditional branch, LCM wouldn't move

   vxorps  %xmm0, %xmm0, %xmm0

out of loop. It's suboptimal.

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
That's an indication you've likely done something wrong with your local
properties HJ.  LCM inherently also does LICM since LICM is just a special case
of PRE.

[Bug rtl-optimization/88593] [9 Regression] cleanup_cfg may make cached dominance info stale

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Jakub Jelinek from comment #6)
> Is anyone going to test the #c5 patch and submit if it passes?

We won't test it.  We no longer use LCM to insert vxorps since LCM generates
vxorps inside the loop.

[Bug target/84010] problematic TLS code generation on 64-bit SPARC

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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