[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jakub at gcc dot gnu.org]

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

--- Comment #51 from Jakub Jelinek  ---
Yes, I just didn't have time for that yet.

[Bug fortran/90329] Incompatibility between gfortran and C lapack calls

[jb at gcc dot gnu.org]

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

--- Comment #50 from Janne Blomqvist  ---
Jakub, should your fix be backported to the gcc-7 branch as well, considering
that the PR 87689 fix was applied to that branch as well?

[Bug other/91048] Recent changes to contrib/mklog cause failure

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org

--- Comment #2 from Janne Blomqvist  ---
Thanks for the report. Fixed, closing.

[Bug other/91048] Recent changes to contrib/mklog cause failure

[jb at gcc dot gnu.org]

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

--- Comment #1 from Janne Blomqvist  ---
Author: jb
Date: Tue Jul  2 05:54:31 2019
New Revision: 272921

URL: https://gcc.gnu.org/viewcvs?rev=272921&root=gcc&view=rev
Log:
mklog/91048: Open ~/.mklog in string mode.

2019-07-02  Janne Blomqvist  

PR other/91048
* mklog (read_user_info): Open ~/.mklog in string mode.

Modified:
trunk/contrib/ChangeLog
trunk/contrib/mklog

[Bug c/79632] params.def should not contain redundant comments

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
What exactly is the harm of the redundancy? I don't think this is too big of an
issue...

[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2017-02-22 00:00:00 |2019-7-2
 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Confirmed.

[Bug fortran/37336] [F03] Finish derived-type finalization

[juergen.reuter at desy dot de]

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

--- Comment #30 from Jürgen Reuter  ---
Are there any plans on finishing the finalization implementation? To me it
looks that the missing cases are the last open issues (besides some minor known
bug) to claim complete F2003 implementation.

[Bug c++/91051] New: [9 Regression] Template conversion operator don't match when converting to constant rvalue reference

[gufideg at gmail dot com]

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

Bug ID: 91051
   Summary: [9 Regression] Template conversion operator don't
match when converting to constant rvalue reference
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gufideg at gmail dot com
  Target Milestone: ---

The following code was compiling in older GCC version, but don't compile with
GCC 9.1:

struct probe {
template
operator T const&& ();
};

void frob(int const&) {}

int main() {
frob(probe()); // don't work with GCC 9.1
}

The expected result is the template conversion operator to rvalue reference to
constant to be called, then binding to the lvalue reference to constant.

This bug don't apply to non templated conversion operator:

struct probe {
operator int const&& ();
};

void frob(int const&) {}

int main() {
frob(probe()); // works under GCC 9.1
}

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[jvdelisle at gcc dot gnu.org]

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

--- Comment #24 from Jerry DeLisle  ---
On a different Ryzen machine:

$ ./run.sh 
1024   3.2604169845581055 
2048   2.7804551124572754 
4096   2.6416599750518799 
8192   2.5986809730529785 
16384   2.5525100231170654 
32768   2.5145640373229980 
65536   9.2993371486663818 
131072   9.0313489437103271

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #3 from Alan Modra  ---
We don't always emit .machine because that is a waste of time if the .machine
cpu matches the original cpu passed on the command line to gas.  .machine
reloads the gas opcode table, which may take a significant time.

[Bug c++/90490] [9 Regression] ICE on noexcept with decltype expression

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c++/60223] [c++11] ICE with C++11-style default template parameter

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
Fixed.

[Bug c++/90490] [9 Regression] ICE on noexcept with decltype expression

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jul  2 00:23:41 2019
New Revision: 272918

URL: https://gcc.gnu.org/viewcvs?rev=272918&root=gcc&view=rev
Log:
PR c++/90490 - fix decltype issues in noexcept-specifier.
* except.c (build_noexcept_spec): Call
instantiate_non_dependent_expr_sfinae before
build_converted_constant_expr instead of calling
instantiate_non_dependent_expr after it.  Add
processing_template_decl_sentinel.

* g++.dg/cpp0x/noexcept43.C: New test.
* g++.dg/cpp0x/noexcept44.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/noexcept43.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/noexcept44.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/except.c

[Bug c++/60223] [c++11] ICE with C++11-style default template parameter

[mpolacek at gcc dot gnu.org]

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

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Tue Jul  2 00:22:37 2019
New Revision: 272917

URL: https://gcc.gnu.org/viewcvs?rev=272917&root=gcc&view=rev
Log:
PR c++/60223 - ICE with T{} in non-deduced context.
* pt.c (unify): Allow COMPOUND_LITERAL_P in a non-deduced context.

* g++.dg/cpp0x/nondeduced1.C: New test.
* g++.dg/cpp0x/nondeduced2.C: New test.
* g++.dg/cpp0x/nondeduced3.C: New test.
* g++.dg/cpp0x/nondeduced4.C: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/nondeduced1.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/nondeduced2.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/nondeduced3.C
branches/gcc-9-branch/gcc/testsuite/g++.dg/cpp0x/nondeduced4.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/pt.c

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||amodra at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |bergner at gcc dot 
gnu.org

--- Comment #2 from Peter Bergner  ---
I will work on a patch.  A somewhat related issue is why don't we emit a
.machine  directive?  We only seems to emit one when we don't specify
-mcpu=... and did not configure gcc with --with-cpu=...  On LE, the compiler is
always built as if a --with-cpu=... option was used, even if the user didn't
use it, so we never emit .machine directives on LE.

[Bug target/91050] -mdejagnu-cpu= does not affect the -m assembler option

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Target||powerpc*-*-*
 CC||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #1 from Peter Bergner  ---
The bug seems to be that our *asm_cpu: spec file only checks for -mcpu=... and
not for both -mcpu=... and -mdejagnu-cpu=

[Bug target/91050] New: -mdejagnu-cpu= does not affect the -m assembler option

[bergner at gcc dot gnu.org]

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

Bug ID: 91050
   Summary: -mdejagnu-cpu= does not affect the -m
assembler option
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

The -mdejagnu-cpu= option is supposed to behave exactly like -mcpu=
except for that -mcpu= option cannot override it.  We want/need that
behavior in some of our testsuite test cases.  However, with Alan's patch that
stopped gcc from always passing -many to the assembler for POWER, we are now
seeing problems like the following test case:

bergner@pike:~/gcc/BUGS/dejagnu-cpu$ cat bug.c 
unsigned long
foo (void)
{
  unsigned long addr;
  asm ("lnia %0" : "=r" (addr));  /* "lnia" is new in POWER9.  */
  return addr;
}
bergner@pike:~/gcc/BUGS/dejagnu-cpu$ gcc -O2 -c -mcpu=power8 bug.c
/tmp/ccSEBrVw.s: Assembler messages:
/tmp/ccSEBrVw.s:13: Error: unrecognized opcode: `lnia'
bergner@pike:~/gcc/BUGS/dejagnu-cpu$ gcc -O2 -c -mcpu=power9 bug.c
bergner@pike:~/gcc/BUGS/dejagnu-cpu$ gcc -O2 -c -mcpu=power9
-mdejagnu-cpu=power9 bug.c
bergner@pike:~/gcc/BUGS/dejagnu-cpu$ gcc -O2 -c -mcpu=power8
-mdejagnu-cpu=power9 bug.c
/tmp/ccKQFygo.s: Assembler messages:
/tmp/ccKQFygo.s:13: Error: unrecognized opcode: `lnia'
bergner@pike:~/gcc/BUGS/dejagnu-cpu$ gcc -O2 -c -mdejagnu-cpu=power9 bug.c
/tmp/ccKQFygo.s: Assembler messages:
/tmp/ccKQFygo.s:13: Error: unrecognized opcode: `lnia'

In this case, "lnia" is an instruction added in power9.  However, we can see
from above, that -mdejagnu-cpu=power9 alone is not enough to get the test case
to compile/assemle correctly.  It seems the -m assembler option we use is
only affected by -mcpu= and not -mdejagnu-cpu= which is a bug.

[Bug c++/91049] New: wrong location in -Wreturn-local-addr for a return throw

[msebor at gcc dot gnu.org]

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

Bug ID: 91049
   Summary: wrong location in -Wreturn-local-addr for a return
throw
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The location of the underlining in the warning for the test case below is
wrong: it should point at the &i:

$ cat a.C && gcc -O2 -S -Wall a.C
struct X { };

void* f (int i)
{
  X x;
  return i ?
 &i :
 throw x;
}
a.C: In function ‘void* f(int)’:
a.C:8:16: warning: function may return address of local variable
[-Wreturn-local-addr]
8 |  throw x;
  |^
a.C:3:14: note: declared here
3 | void* f (int i)
  |  ^


Clang gets it right:

a.C:7:11: warning: address of stack memory associated with parameter 'i'
returned [-Wreturn-stack-address]

 &i :

  ^

[Bug c++/91049] wrong location in -Wreturn-local-addr for a return throw

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||90556
   Severity|normal  |minor


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
[Bug 90556] [meta-bug] bogus/missing -Wreturn-local-addr

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[tkoenig at gcc dot gnu.org]

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

--- Comment #23 from Thomas Koenig  ---
Some numbers for the provisionary patch, varying the
size for the buffers.

With the patch, the original benchmark (minus some output, only
the elapsed time is shown) and the script

for a in 1024 2048 4096 8192 16384 32768 65536 131072
do
rm -f out.dat
sync ; sync; sync
sleep 1
echo -n $a
GFORTRAN_BUFFER_SIZE_UNFORMATTED=$a ./a.out
done
rm -f out.dat
sync

I get on my home Ryzen box with ext4

1024   2.959884643555 
2048   2.4514980316162109 
4096   2.2090110778808594 
8192   1.9955158233642578 
16384   2.0065548419952393 
32768   1.9320869445800781 
65536   1.9494299888610840 
131072   1.8885779380798340  

On gcc135 (POWER9) I get

1024   6.2069039344787598 
2048   3.5782949924468994 
4096   2.2184860706329346 
8192   1.4914679527282715 
16384   1.1247980594635010 
32768  0.95092821121215820 
65536  0.85877490043640137 
131072  0.82407808303833008

and on gcc115 (aarch64):

1024   10.543070077896118 
2048   7.3426060676574707 
4096   5.7169480323791504 
8192   4.7394258975982666 
16384   4.2912349700927734 
32768   4.0224111080169678 
65536   3.8719530105590820 
131072   3.8628818988800049

so 64 k looks like a good choice, except for the Ryzen machine,
where 8k would be sufficient.

[Bug other/91048] New: Recent changes to contrib/mklog cause failure

[kelvin.nilsen at gmail dot com]

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

Bug ID: 91048
   Summary: Recent changes to contrib/mklog cause failure
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin.nilsen at gmail dot com
  Target Milestone: ---

./contrib/mklog crashes, even on very simple diff files.  Sample traceback
report follows:

./contrib/mklog svn.diffs.7-1-2019 >svn.ChangeLog
Traceback (most recent call last):
 File “./contrib/mklog”, line 470, in 
   main()
 File “./contrib/mklog”, line 357, in main
   name, email = read_user_info()
 File “./contrib/mklog”, line 105, in read_user_info
   if cache.match(r’^\s*([a-zA-Z0-9_]+)\s*=\s*(.*?)\s*$’, s):
 File “./contrib/mklog”, line 57, in match
   self.last_match = re.match(p, s) if isinstance(p, str) else p.match(s)
 File “/usr/lib/python3.5/re.py”, line 163, in match
   return _compile(pattern, flags).match(string)
TypeError: cannot use a string pattern on a bytes-like object

I get these problems with any diff file.  In this case, my diff file consists
only of the following:

kelvin@genoa:~/gcc-root/gcc-trunk$ cat svn.diffs.7-1-2019 
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 272909)
+++ gcc/doc/extend.texi (working copy)
@@ -5371,6 +5371,8 @@ Kernel functions must have @code{void} return type
 @node PowerPC Function Attributes
 @subsection PowerPC Function Attributes

+kelvin is clowning around here to try to figure out mklog behavior.
+
 These function attributes are supported by the PowerPC back end:

 @table @code

[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR

[amylaar at gcc dot gnu.org]

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

--- Comment #21 from Jorn Wolfgang Rennecke  ---
Author: amylaar
Date: Mon Jul  1 21:48:55 2019
New Revision: 272911

URL: https://gcc.gnu.org/viewcvs?rev=272911&root=gcc&view=rev
Log:
PR middle-end/66726
* tree-ssa-phiopt.c (factor_out_conditional_conversion):
Tune heuristic from PR71016 to allow MIN / MAX.
* testsuite/gcc.dg/tree-ssa/pr66726-4.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr66726-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse  ---
https://gmplib.org/manual/Build-Options.html#index-Generic-C documents
--disable-assembly as the official way to disable asm. But I am surprised that
even with the snapshot you had asm. Looking at the current sources, if you
configure for a host none-*-*, it sets enable_assembly=no, same as
--disable-assembly.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #23 from dave.anglin at bell dot net ---
On 2019-07-01 3:12 p.m., elowe at elowe dot com wrote:
> My configure line was:
>
>   $ ../gcc-8.3.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc8.3
> --with-as=/usr/local/bin/as --without-gnu-ld --disable-nls --disable-libgomp
> --disable-libgcj --enable-shared --enable-threads=posix CC=gcc -mlp64 CXX=g++
> -mlp64
I'm going to suggest that you add "--with-gnu-as" and
"--with-ld=/usr/ccs/bin/ld" options.  I
might have path for HP ld wrong.  Also, make sure CC and CXX are quoted.  There
is a dependence
in ia64.c, etc, on the assembler dialect (TARGET_GNU_AS).  There's also a
dependence on
TARGET_HPUX_LD.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #22 from EML  ---
Thanks for the hints and options

on IA64, I used the GNU AS (2.32), but the HP LD (ld: 92453-07 linker ld HP
Itanium(R) B.12.65  IPF/IPF)

Well, this is historically how you do it, I believe you need to use the HP
linker as the dynamic loader won't work with the GNU linker.

I have some tests I want to run. - Note, I started with 8.3.0 because I
understood (and you have confirmed) that this ran on Debian ia64. So generally
the assembler must know how to put together the instructions properly for the
CPU.

My configure line was:

  $ ../gcc-8.3.0/configure --enable-languages=c,c++ --prefix=/usr/local/gcc8.3
--with-as=/usr/local/bin/as --without-gnu-ld --disable-nls --disable-libgomp
--disable-libgcj --enable-shared --enable-threads=posix CC=gcc -mlp64 CXX=g++
-mlp64

(Note, the CC and CXX are for getting it build in 64bit - leaving that off will
generate a 32bit version)

Yes, this all is somewhat unrelated to the original bug report - probably
should be moved to some other report.

[Bug c++/91044] /home/hugo/Code_Block/C++_Tutorial/cadenas_tipo_c.cpp|12|error: no matching function for call to ‘getline(std::string [50], int, char)’|

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to hugo from comment #2)
> Please see the following page that defines a getline:
> https://en.cppreference.com/w/cpp/string/basic_string/getline

That's the URL I gave you.

> This other page defines another type of getline:
> https://en.cppreference.com/w/cpp/string/basic_string/getline

That's the same URL again.

> And if you compile the sample source code, you get an error in the line
> where the following instruction is: for (std::string line;
> std::getline(input, line); ) {
> sum += std::stoi(line);

No you don't, it compiles fine.

> Can you help me?

No, this is the wrong place to learn C++. Try https://stackoverflow.com

[Bug target/91047] PowerPC: inline assembly doesn't know the difference between altivec and vsx registers

[shawn at git dot icu]

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

Shawn Landden  changed:

   What|Removed |Added

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

--- Comment #2 from Shawn Landden  ---
"When using the register constraint wathat takes VSX registers, you must use
%x in the template so that the correct register is used. Otherwise the
register number output in the assembly file will be incorrect if an Altivec
register is an operand of a VSX instruction that expects VSX register
numbering."

[Bug target/91047] PowerPC: inline assembly doesn't know the difference between altivec and vsx registers

[shawn at git dot icu]

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

--- Comment #1 from Shawn Landden  ---
My bad, the argument is passed in vr2, but this is not the same as vs2.

[Bug target/91047] New: PowerPC: inline assembly doesn't know the difference between altivec and vsx registers

[shawn at git dot icu]

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

Bug ID: 91047
   Summary: PowerPC: inline assembly doesn't know the difference
between altivec and vsx registers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shawn at git dot icu
  Target Milestone: ---

AltiVec registers are differn't registers from VSX registers, and even when the
VSX register class ("wa"[1]) is specified to an inline assembly, gcc doesn't
put the variable in the right register

#include 
#include 
void store_unaligned(vector unsigned char vec, unsigned char *dest) {
uintptr_t zero = 0;

__asm__ volatile ("stxvb16x %0, %1, %2\n\t"
  :
  : "wa" (vec), "r" (zero), "r" ((uintptr_t)dest));
}

compiled with gcc -mvsx unaligned.c --save-temps -c -O3

store_unaligned:
.LFB0:
.cfi_startproc
li 9,0
#APP
 # 6 "unaligned.c" 1
stxvb16x 2, 9, 5 <=== gcc needs to move it from vr3 to vs2, but didn't

[Bug middle-end/90923] hash_map destroys elements without constructing them

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Committed in r272893.

[Bug middle-end/90923] hash_map destroys elements without constructing them

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Mon Jul  1 18:33:36 2019
New Revision: 272893

URL: https://gcc.gnu.org/viewcvs?rev=272893&root=gcc&view=rev
Log:
PR middle-end/90923 - hash_map destroys elements without constructing them

gcc/ChangeLog:

PR middle-end/90923
* hash-map.h (hash_map::put): On insertion invoke element ctor.
(hash_map::get_or_insert): Same.  Reformat comment.
* hash-set.h (hash_set::add): On insertion invoke element ctor.
* hash-map-tests.c (test_map_of_type_with_ctor_and_dtor): New.
* hash-set-tests.c (test_map_of_type_with_ctor_and_dtor): New.
* hash-table.h (hash_table::operator=): Prevent copy assignment.
 (hash_table::hash_table (const hash_table&)): Use copy ctor
 instead of assignment to copy elements.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/hash-map-tests.c
trunk/gcc/hash-map.h
trunk/gcc/hash-set-tests.c
trunk/gcc/hash-set.h
trunk/gcc/hash-table.h

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[andrewm.roberts at sky dot com]

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

--- Comment #14 from Andrew Roberts  ---
One final point even vanilla gcc 9.1.0 fails to build gmp standalone if
CFLAGS is set, so issue with Raspbian compiler is that it is probably setting
CFLAGS and thus messing up gmp build.

To cause standalone gmp 6.1.2 build to fail with vanilla gcc release:
CFLAGS="-v" ; export CFLAGS
tar -xf gmp-6.1.2.tar.*
cd gmp-6.1.2
./configure
make

but ./configure --enable-assembly=no is fine.

Of course the system binutils could be out of whack also, but rebuilding that
is a job for another day.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #21 from dave.anglin at bell dot net ---
On 2019-07-01 12:53 p.m., elowe at elowe dot com wrote:
> Working assembler for hello world program:
>
> => 0x4c90 <+0>: [MII]   alloc r33=ar.pfs,5,4,0
>0x4c91 <+1>: mov r34=r12
>0x4c92 <+2>: mov r32=b0
>0x4ca0 <+16>:[MII]   mov r35=r1
>0x4ca1 <+17>:addl r36=-16,r1;;
>0x4ca2 <+18>:nop.i 0x0
>
> Bad assembler:
>
> => 0x4c00 <+0>: [MII]   alloc r33=ar.pfs,5,4,0
>0x4c01 <+1>: mov r34=r12
>0x4c02 <+2>: mov r32=b0
>0x4c10 <+16>:[MLX]   cmp.lt p0,p0=r0,r0 <<< Illegal
> Instruction
>0x4c11 <+17>:movl r36=0x42c0180;;
>0x4c20 <+32>:[MIB]   add r36=r1,r36
>0x4c21 <+33>:nop.i 0x0
I can't help with ia64 instructions.  This looks like a different bug from the
original report.

Are you using GNU or HP tools?  Did you specify "--with-gnu-as" and/or
"--with-gnu-ld" in
your configure options?

On hppa, the HP assembler is not recommended.  I'm a bit surprised that the
illegal instruction
wasn't an assembler error.

I would switch to testing trunk as any fix will be applied to it first.

If you add "-da" to the compile options for the hello world program, you should
see the RTL
generated in various compilation stages.  Ultimately, the final stage is output
as assembler.  Comparing
your working compiler to the broken compiler may give clues as to what is
broken and when it occurs.

"-save-temps -v" is another useful option.  It saves intermediate files and
shows intermediate
compilation commands.

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[andrewm.roberts at sky dot com]

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

--- Comment #13 from Andrew Roberts  ---
Just tried --enable-assembly=no with the standalone build of gmp
and this does seem to work as advertised. Everything symlinked to .c rather
than .asm files, and no .asm or .s files built at all.

Building gmp standalone with the broken raspbian compiler and setting
CFLAGS="-v" works when configuring using --enable-assembly=no, but fails
without it. 

Long term this is probably the best way forward...

[Bug tree-optimization/91020] Enhance SRA to deal with "omp simd array" variables

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Created attachment 46543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46543&action=edit
Proof-of-concept patch

This is a proof of concept (and only mildly tested) patch which leads
to successful vectorization of the second (C) testcase.

The main downside is that it probably makes SRA code even less
readable than it is now as it creates slightly unnatural special parts
of the access tree which do not adhere to normal rules of the data
structure.  And that is even without attempting to address the issue
in comment #2, which will add more special case handling and will
probably require some heuristics too.  Of course, even that will not
help if the aggregates in question are addressable.

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #20 from Hanoch Haim  ---
One more thing. I would expect that the issue would be in CTimeHistogram
functions (defined as aligned) but the code generation issue was in the parent
object ( CCPortLatency) 
Why the compiler assumed that if one of the internal objects is defined as
aligned the  parent is aligned too?

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #20 from dave.anglin at bell dot net ---
On 2019-07-01 12:53 p.m., elowe at elowe dot com wrote:
> Dave, that link is to Debian HPPA - not IA64 (I cannot find Debian IA64 
> working
> from that site)
Sorry, here is ia64 link:
https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=ia64&ver=8.3.0-7&stamp=1556533635&raw=0

[Bug target/90963] [10 Regression] FAIL: gcc.c-torture/execute/built-in-setjmp.c execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

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

--- Comment #6 from John David Anglin  ---
Fixed.

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #19 from Hanoch Haim  ---
After some investigation, I think it is not a gcc issue,  please verify. 
One of the internal object does not include a 64B alignment.

#define __rte_cache_aligned __attribute__((__aligned__(64)));

class CTimeHistogram {

} __rte_cache_aligned;


class CCPortLatency {
public:
 CTimeHistogram  m_hist;  
} __rte_cache_aligned;  <<= without this, it is not aligned while the code
generation assumed it is aligned !

class Root {

CCPortLatency port;

} __rte_cache_aligned;


Is it valid? why the code generation assumed the CCPortLatency is aligned
because one of its internal is aligned?

[Bug target/90963] [10 Regression] FAIL: gcc.c-torture/execute/built-in-setjmp.c execution test

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
Author: danglin
Date: Mon Jul  1 16:55:42 2019
New Revision: 272891

URL: https://gcc.gnu.org/viewcvs?rev=272891&root=gcc&view=rev
Log:
PR target/90963
* config/pa/pa.md (builtin_longjmp): Restore hard_frame_pointer_rtx
using saved frame pointer.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/pa/pa.md

[Bug c/91046] missing warning about empty translation unit

[vincent-gcc at vinc17 dot net]

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

--- Comment #2 from Vincent Lefèvre  ---
It warns with -pedantic, but not without. This is an issue if this is not
guaranteed to "work" with GCC (now or in the future). Indeed, the case of an
empty translation unit may need additional code. For instance, in
gcc/dwarf2out.c, there is a comment:

  /* Even if there are no children of this DIE, we must output the information
 about the compilation unit.  Otherwise, on an empty translation unit, we
 will generate a present, but empty, .debug_info section.  IRIX 6.5 `nm'
 will then complain when examining the file.  First mark all the DIEs in
 this CU so we know which get local refs.  */

Thus empty translation units seem to be supported there, but it is not obvious
that this is the case everywhere. A warning by default would make the user
aware of that.

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[andrewm.roberts at sky dot com]

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

--- Comment #12 from Andrew Roberts  ---
GMP 6.1.0 and later support the following configure option:
--enable-assembly   enable the use of assembly loops [default=yes]

not sure if this could be used to stop gmp using assembler.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #19 from EML  ---
Dave, that link is to Debian HPPA - not IA64 (I cannot find Debian IA64 working
from that site)

Working assembler for hello world program:

=> 0x4c90 <+0>: [MII]   alloc r33=ar.pfs,5,4,0
   0x4c91 <+1>: mov r34=r12
   0x4c92 <+2>: mov r32=b0
   0x4ca0 <+16>:[MII]   mov r35=r1
   0x4ca1 <+17>:addl r36=-16,r1;;
   0x4ca2 <+18>:nop.i 0x0

Bad assembler:

=> 0x4c00 <+0>: [MII]   alloc r33=ar.pfs,5,4,0
   0x4c01 <+1>: mov r34=r12
   0x4c02 <+2>: mov r32=b0
   0x4c10 <+16>:[MLX]   cmp.lt p0,p0=r0,r0 <<< Illegal
Instruction
   0x4c11 <+17>:movl r36=0x42c0180;;
   0x4c20 <+32>:[MIB]   add r36=r1,r36
   0x4c21 <+33>:nop.i 0x0

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[andrewm.roberts at sky dot com]

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

--- Comment #11 from Andrew Roberts  ---
Richard,
the cpu supports mls (its a ARM Cortex A72). 

Comment 2 shows the -v output for both building gmp within gcc and standalone.
When building gmp in tree using Raspbian compiler:

as --gdwarf2 -v -I . -I ../../../gcc-9.1.0/gmp/mpn -I .. -I
../../../gcc-9.1.0/gmp -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5
--noexecstack -o divrem_1.o tmp-divrem_1.s

The issue is that when building gmp in tree no assembler code is supposed to be
used.

This looks like a problem with the Raspbian build of gcc breaking something. 
Possibly relating to CFLAGS, as setting CFLAGS to -v also causes the standalone
build of gmp to break with similar assembler errors.

When building an original gcc-8.3.0 or 9.1.0 release using the system gmp (not
in tree), this compiler can then be used to rebuild its self with gmp in tree
with no issues. So problem is specific to the Raspbian host compiler.

[Bug c++/91044] /home/hugo/Code_Block/C++_Tutorial/cadenas_tipo_c.cpp|12|error: no matching function for call to ‘getline(std::string [50], int, char)’|

[baronahugo31 at gmail dot com]

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

--- Comment #2 from hugo  ---
Please see the following page that defines a getline:
https://en.cppreference.com/w/cpp/string/basic_string/getline

This other page defines another type of getline:
https://en.cppreference.com/w/cpp/string/basic_string/getline
And if you compile the sample source code, you get an error in the line where
the following instruction is: for (std::string line; std::getline(input, line);
) {
sum += std::stoi(line);

Can you help me?

[Bug middle-end/64242] Longjmp expansion incorrect

[ebotcazou at gcc dot gnu.org]

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

--- Comment #35 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Jul  1 16:27:06 2019
New Revision: 272890

URL: https://gcc.gnu.org/viewcvs?rev=272890&root=gcc&view=rev
Log:
PR middle-end/64242
* config/sparc/sparc.md (nonlocal_goto): Restore frame pointer last.
Add frame clobber and schedule blockage.

Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/sparc/sparc.md

[Bug web/90334] documentation for getting read-write SVN access is misleading

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #5)
> Maybe just saying "sourceware.org / gcc.gnu.org" would be good enough to
> avoid confusion. That's obviously not a URL that you're supposed to copy &
> paste.

Yes, that would be an improvement.

[Bug middle-end/64242] Longjmp expansion incorrect

[ebotcazou at gcc dot gnu.org]

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

--- Comment #34 from Eric Botcazou  ---
Author: ebotcazou
Date: Mon Jul  1 16:26:38 2019
New Revision: 272889

URL: https://gcc.gnu.org/viewcvs?rev=272889&root=gcc&view=rev
Log:
PR middle-end/64242
* config/sparc/sparc.md (nonlocal_goto): Restore frame pointer last.
Add frame clobber and schedule blockage.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sparc/sparc.md

[Bug c/91046] missing warning about empty translation unit

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
gcc warns for me:

$ echo "" >> empty.c
$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic empty.c
empty.c:1: warning: ISO C forbids an empty translation unit [-Wpedantic]
1 | 
  | 
$

For comparison, clang puts this under its own separate flag: 

$ clang -c -Wall -Wextra -pedantic empty.c
empty.c:1:1: warning: ISO C requires a translation unit to contain at least one
declaration [-Wempty-translation-unit]
^
1 warning generated.
$

So maybe it's worth splitting -Wempty-translation-unit off from -Wpedantic in
gcc too, so it's separately controllable?

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #18 from Alexander Monakov  ---
It seems the problem is not in CCPortLatency::Create, but rather one of its
callers. Try to investigate in gdb where a misaligned pointer is derived from a
64-byte aligned pointer to the toplevel g_trex object (i.e. work up the stack
from the point of the crash).

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak  ---
The asm dump claims that the access is aligned to 32bytes:

#(insn 14 31 9 2 (set (mem:V4DI (plus:DI (reg/f:DI 3 bx [orig:90 this ] [90])
#(const_int 64 [0x40])) [6 MEM[(long unsigned int *)this_6(D) +
64B]+0 S32 A256])
#(reg:V4DI 21 xmm0 [92])) "../../src/stateful_rx_core.cpp":254 1228
{movv4di_internal}
# (nil))
vmovdqa %ymm0, 64(%rbx) # 14movv4di_internal/4  [length = 5]


which gets expanded from:

;; MEM[(long unsigned int *)this_6(D) + 64B] = { 0, 0, 0, 0 };

(insn 13 12 14 (set (reg:V4DI 92)
(const_vector:V4DI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])) "../../src/stateful_rx_core.cpp":254 -1
 (nil))

(insn 14 13 0 (set (mem:V4DI (plus:DI (reg/f:DI 90 [ this ])
(const_int 64 [0x40])) [6 MEM[(long unsigned int *)this_6(D) +
64B]+0 S32 A256])
(reg:V4DI 92)) "../../src/stateful_rx_core.cpp":254 -1
 (nil))

So, not a target issue.

[Bug testsuite/91045] gcc installing

[dorianbrice at hotmail dot fr]

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

--- Comment #2 from Dorian ROSSE  ---
Thank you I send the e-mail to the good mailling list 😊

Regards.


Dorian ROSSE.



Provenance : Courrier pour
Windows 10




De : redi at gcc dot gnu.org 
Envoyé : Monday, July 1, 2019 4:20:55 PM
À : dorianbr...@hotmail.fr
Objet : [Bug testsuite/91045] gcc installing

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug report, you should ask on the gcc-h...@gcc.gnu.org mailing
list for assistance instead.

runtest is part of the dejagnu package, which you need to run the testsuite.

--
You are receiving this mail because:
You reported the bug.

[Bug c++/91040] [9/10 Regression] Incorrect "invalid use of non-lvalue array" error in conditional assignment with throw

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
So another dup of 90393.

[Bug testsuite/91045] gcc installing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is not a bug report, you should ask on the gcc-h...@gcc.gnu.org mailing
list for assistance instead.

runtest is part of the dejagnu package, which you need to run the testsuite.

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #16 from Hanoch Haim  ---
The global/parent object CGlobalTRex is aligned (64B) as expected:

(gdb) p &g_trex
$1 = (CGlobalTRex *) 0xc365c0 

Could you explain why it is a problem to define the internal objects with the
aligment like the parent (64B)?

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to Richard Biener from comment #14)
> (In reply to Hanoch Haim from comment #12)
> > Removing __rte_cache_aligned does not solve the issue
> > 
> >  
> > diff --git a/src/time_histogram.h b/src/time_histogram.h
> > index 07e66b49..26a37248 100755
> > --- a/src/time_histogram.h
> > +++ b/src/time_histogram.h
> > @@ -133,10 +133,10 @@ private:
> >  uint32_t m_win_cnt;
> >  uint32_t m_hot_max;
> >  dsec_t   m_max_ar[HISTOGRAM_QUEUE_SIZE]; // Array of maximum latencies
> > for previous periods
> > -uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE] __rte_cache_aligned
> > ;
> > +uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE]  ;
> >  // Hdr histogram instance
> >  hdr_histogram *m_hdrh;
> > -};
> > +} __rte_cache_aligned;
> 
> There are more aligned attributes.  I see
> 
> class CLatencyManager : public TrexRxCore {
> ...
>  volatile bool m_do_stop __attribute__((__aligned__(64))) ;
> 
> struct rte_ring {
>  char name[32] __attribute__((__aligned__(64)));
> 
> class CFlowGenListPerThread {
> ...
> } __attribute__((__aligned__(64)));
> 
> etc.
> 
> Can you check the .bss section Alignment in the final executable/shared
> object?
> Do you by chance substitute the program loader for something not honoring
> large alignment of .bss sections?

You can also check with a debugger whether your global static object
is properly aligned.

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
(In reply to Hanoch Haim from comment #12)
> Removing __rte_cache_aligned does not solve the issue
> 
>  
> diff --git a/src/time_histogram.h b/src/time_histogram.h
> index 07e66b49..26a37248 100755
> --- a/src/time_histogram.h
> +++ b/src/time_histogram.h
> @@ -133,10 +133,10 @@ private:
>  uint32_t m_win_cnt;
>  uint32_t m_hot_max;
>  dsec_t   m_max_ar[HISTOGRAM_QUEUE_SIZE]; // Array of maximum latencies
> for previous periods
> -uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE] __rte_cache_aligned
> ;
> +uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE]  ;
>  // Hdr histogram instance
>  hdr_histogram *m_hdrh;
> -};
> +} __rte_cache_aligned;

There are more aligned attributes.  I see

class CLatencyManager : public TrexRxCore {
...
 volatile bool m_do_stop __attribute__((__aligned__(64))) ;

struct rte_ring {
 char name[32] __attribute__((__aligned__(64)));

class CFlowGenListPerThread {
...
} __attribute__((__aligned__(64)));

etc.

Can you check the .bss section Alignment in the final executable/shared object?
Do you by chance substitute the program loader for something not honoring
large alignment of .bss sections?

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #13 from Hanoch Haim  ---
One more thing, The parent object is defined with 64Byte alignment 

class CGlobalTRex  {
..

} __rte_cache_aligned;

static CGlobalTRex  trex;

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

Hanoch Haim  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #12 from Hanoch Haim  ---
Removing __rte_cache_aligned does not solve the issue


diff --git a/src/time_histogram.h b/src/time_histogram.h
index 07e66b49..26a37248 100755
--- a/src/time_histogram.h
+++ b/src/time_histogram.h
@@ -133,10 +133,10 @@ private:
 uint32_t m_win_cnt;
 uint32_t m_hot_max;
 dsec_t   m_max_ar[HISTOGRAM_QUEUE_SIZE]; // Array of maximum latencies for
previous periods
-uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE] __rte_cache_aligned ;
+uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE]  ;
 // Hdr histogram instance
 hdr_histogram *m_hdrh;
-};
+} __rte_cache_aligned;

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #11 from Hanoch Haim  ---
thanks for the quick answer. 
The parent object is static (bss) and wasn't dynmicly allocated using
new/malloc. 
gcc set the address of the parent object and the childs. 

Is there a way to solve it without removing the alignment?

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #18 from dave.anglin at bell dot net ---
On 2019-06-30 6:19 p.m., elowe at elowe dot com wrote:
> I can compile the stage1 compiler xgcc - however, the stage1 compiler 
> generates
> executables the immediately crash. It will happily build libgcc, but cannot
> generate correct executables and will not finish the "configure" step for
> libstdc++ (which attempts to compile and run various conftest.c programs) -
> these are pretty simple programs. I also tried to compile a simple "Hello
> World" program, but it crashes immediately when run.
The only way to make progress is to debug the above problems.  The issue is
likely hp-ux
specific as gcc-8 builds successfully on Debian linux:
https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=hppa&ver=8.3.0-7&stamp=1556503087&raw=0

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Richard Biener  ---
I can reproduce the aligned stores with -O3 -march=core-avx2 with GCC 7/8/9.

note that when I check alignof(CCPortLatency) I do get 64 byte alignment
because it has a private member of type CTimeHistogram which has a member

uint64_t m_hcnt[HISTOGRAM_SIZE_LOG][HISTOGRAM_SIZE]
__attribute__((__aligned__(64))) ;

This kind of overaligned type doesn't play well with "old" C++ new but
you need support for overaligned types which is only in newer C++ standards
or resort to posix_memalign or friends to allocate memory.

Or simply drop the aligned attribute from above.

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[dje at gcc dot gnu.org]

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

--- Comment #22 from David Edelsohn  ---
The following are unofficial results on an unspecified system running GPFS. 
These should not be considered official anything and should not be referenced
for benchmarking.

Test using 2.50e+08 doubles
Block size of file system: 16777216
bs =   1024, 126.53 MiB/s
bs =   2048, 218.69 MiB/s
bs =   4096, 335.00 MiB/s
bs =   8192, 436.25 MiB/s
bs =  16384, 774.91 MiB/s
bs =  32768, 619.28 MiB/s
bs =  65536, 1018.89 MiB/s
bs = 131072, 659.44 MiB/s
bs = 262144, 629.90 MiB/s
bs = 524288, .63 MiB/s
bs =1048576, 678.90 MiB/s
bs =2097152, 1029.28 MiB/s
bs =4194304, 668.27 MiB/s
bs =8388608, 662.53 MiB/s
bs =   16777216, .37 MiB/s
bs =   33554432, 694.28 MiB/s
bs =   67108864, 1091.94 MiB/s

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #9 from Hanoch Haim  ---
Attached. I hope this is what you are looking for.

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #8 from Hanoch Haim  ---
Created attachment 46542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46542&action=edit
stateful_rx_core.ss

[Bug target/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #7 from Hanoch Haim  ---
Created attachment 46541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46541&action=edit
stateful_rx_core.ii

compress ii

[Bug c++/91044] /home/hugo/Code_Block/C++_Tutorial/cadenas_tipo_c.cpp|12|error: no matching function for call to ‘getline(std::string [50], int, char)’|

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
You get an error because that's not valid C++.

I don't know what you think those calls to getline are supposed to do, but
there is no matching function in the C++ standard library.

https://en.cppreference.com/w/cpp/string/basic_string/getline

[Bug c/91046] New: missing warning about empty translation unit

[vincent-gcc at vinc17 dot net]

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

Bug ID: 91046
   Summary: missing warning about empty translation unit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

The C standard forbids empty translation units, and if the program is compiled
successfully (as what GCC does by default), the behavior of this program is
undefined (currently, even with GCC, as the behavior is not specified by its
manual). Thus GCC should issue a warning, even without -pedantic.

Alternatively, GCC could explicitly define the behavior as an extension (if
this is currently the case) and document it in its manual, in which case the
warning could be issued only with -pedantic as now. It should be sufficient to
say that empty translation units are allowed, since the text of the C standard
would not need additional specifications to make the behavior unambiguous.

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[rearnsha at gcc dot gnu.org]

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

--- Comment #10 from Richard Earnshaw  ---
(In reply to Andrew Roberts from comment #9)
> For completeness I've also built gcc 8.3.0 with in tree gmp 6.1.2 using the
> newly built 9.1.0. And then in turn used this gcc 8.3.0 to rebuild gcc 9.1.0
> with in tree gmp.
> 
> So the host gcc 8.3.0 doesn't work building gcc with in tree gmp.
> But all the versions I have built (9.1.0 and 8.3.0) build this correctly.

So if I've understood all this correctly, this is happening when assembling a
file written in assembly, rather than one generated by GCC itself.

The most likely source of the problem here is that your system compiler is
trying to set the CPU for the assembler to use on the command line, but that
CPU is then older than the one the file is expecting (MLS was new in ARMv7
(strictly, ARMv6t2, but that's probably not relevant to the pi)).

So can you run the command with -v and show what options are being passed to
the assembler?

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||dominik.infuehr at gmail dot 
com

--- Comment #14 from Richard Biener  ---
Proposed here: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01874.html

[Bug fortran/88079] warn about procedure arguments without INTENT

[mark.eggleston at codethink dot com]

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

--- Comment #6 from MarkEggleston  ---
Where a module is used:

module foo
  implicit none

  interface
subroutine dusty(n)
  integer :: n
end subroutine
  end interface

contains
  subroutine bar(n)
integer, intent(in) :: n
real :: x
print *,"bar before dusty", n
call dusty(n)
print *,"bar after dusty", n
  end subroutine bar

end module foo

subroutine dusty(n)
  integer :: n
  n = n - 1
end

program main
  use foo
  implicit none
  integer :: n
  n = 5
  call bar(n)

end program main

The call to dusty in bar would be with an implicit interface were it not for
the interface block. I get the same warnings as in comment 5.

I would like to also issue a warning for the interface block but don't I know
where I could insert an code to issue a warning anywhere near the interface
block. I know where the dummy variable is processed from a lexical point of
view but I don't know where the interface block is handled. Some indication of
where to look would be greatly appreciated.

[Bug c++/91043] GCC produces unaligned vmovdqa vector data access

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Hanoch Haim from comment #5)

> if anything else is needed I would provide it
Please follow the procedure, outlined in [1].

[1] https://www.gnu.org/software/gcc/bugs/

[Bug testsuite/91045] New: gcc installing

[dorianbrice at hotmail dot fr]

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

Bug ID: 91045
   Summary: gcc installing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dorianbrice at hotmail dot fr
  Target Milestone: ---
  Host: bitfenix-server

Created attachment 46540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46540&action=edit
answer of command line './configure --enable-languages=c,c++,go --with-gmp
--with-mpfr --with-mpc && make && make install'

hello,


My error when I want to compile gcc :

/bin/bash: line 17: runtest: command not found

I found It errors by launch 'make check' before 'make' because I can't 'make'
gcc 9,

I installed some packages for try to build gcc :

gmp, mpfr, mpc,

gmp, mpfr and mpc are in the same root than gcc (opt)

I try to install for c, c++ ang go program by :

--enable-languages=c,c++,go

Thank you in advance to help me install gcc 9 :)

Regards.


Dorian ROSSE.

[Bug fortran/88079] warn about procedure arguments without INTENT

[mark.eggleston at codethink dot com]

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

--- Comment #5 from MarkEggleston  ---
Given the program below:

program main
  implicit none
  integer :: n
  n = 5
  call bar(n)

end program main

subroutine bar(n)
  integer, intent(in) :: n
  real :: x
  print *,"bar before dusty", n
  call dusty(n)
  print *,"bar after dusty", n
end subroutine bar

subroutine dusty(n)
  integer :: n
  n = n - 1
end

the attached patch produces the following warnings:

pr88079_2.f90:19:2:

   19 |   n = n - 1
  |  1
Warning: Dummy variable 'n' in assignment at (1) has missing INTENT or VALUE
[-Wintent]
pr88079_2.f90:13:15:

   13 |   call dusty(n)
  |   1
Warning: Dummy variable 'n' at (1) has INTENT(IN) and may be modified
[-Wintent]
pr88079_2.f90:17:18:

   17 | subroutine dusty(n)
  |  1
Warning: Dummy variable 'n' in assignment at (1) has missing INTENT or VALUE
[-Wintent]

Note: if compiles with a standard earlier than Fortran 2003 "or VALUE" will be
omitted.

I'm not happy with the location of the last warning which is why it is worded
as it is. I would prefer the following:

   18 |   integer :: n
  |   1
Warning: Missing INTENT or VALUE at (1)

I currently don't know enough about identifying the location of a warning or
error to determine whether this can be done.

Where dusty(n) is called the interface to dusty is known, however, this is not
always the case so the attribute of the associate dummy variable can always be
checked. To help identify a potential problem -Wimplicit-inteface can be used.

[Bug c++/91044] New: /home/hugo/Code_Block/C++_Tutorial/cadenas_tipo_c.cpp|12|error: no matching function for call to ‘getline(std::string [50], int, char)’|

[baronahugo31 at gmail dot com]

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

Bug ID: 91044
   Summary: /home/hugo/Code_Block/C++_Tutorial/cadenas_tipo_c.cpp|
12|error: no matching function for call to
‘getline(std::string [50], int, char)’|
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baronahugo31 at gmail dot com
  Target Milestone: ---

The following program provides an error each time you call getline: 
#include
#include

#define NULO'\0'

using   namespace std;

int main(){

stringnombre[50], apellido1[50], apellido2[50], completo[150];
cout<<  "Nombre: ";
getline(nombre, 50, '\n');
cout<<  "\nPrimer Apellido: ";
getline(apellido1, 50, '\n');
cout<<  "\nSegundo Apellido: ";
getline(apellido2, 50, '\n');
completo=NULO;
cout<<  "\n\nSu nombre completo es: "   <<  completo<<  endl;
cin.get();
}

The same happens when the following instruction is changed to char:
   char nombre[50], apellido1[50], apellido2[50], completo[150];

Every time an instruction with getline appears, you get an error

Sincerely
hugo barona

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Oh, and with late FRE even the original testcase now works.  DSE fails to
eliminate the memcpy () and thus consequently the stores to the temporary
array.  We don't have DECL_IS_OPERATOR_DELETE it seems and there's
no clobber of the associated memory before it that could help.  There's
also EH that I'm not sure will interfere with DSE of the temporary array
stores.

  __BB(2,guessed_local(118111600)):
  D_29441[0ul] = 10;
  D_29441[1ul] = 20;
  D_29441[2ul] = 30;
  _34 = operator new (12ul);
  goto __BB3(precise(134217728));

  __BB(3,guessed_local(118078057)):
  _32 = _34 + 12ul;
  __builtin_memcpy (_34, &D_29441, 12ul);
  __l ={v} {CLOBBER};
  _44 = _34 + 4ul;
  _47 = _44 + 4ul;
  operator delete (_34);
  D_29454 ={v} {CLOBBER};
  D_29454 ={v} {CLOBBER};
  D_29441 ={v} {CLOBBER};
  return 160;

  __BB(4,precise(0)):
L7:
  __MEM  ((struct _Vector_base *)&D_29454) ={v} {CLOBBER};
  resx 13


I somehow remember a bug or even patches about the missing
DECL_IS_OPERATOR_DELETE?

[Bug fortran/88079] warn about procedure arguments without INTENT

[mark.eggleston at codethink dot com]

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

--- Comment #4 from MarkEggleston  ---
Created attachment 46539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46539&action=edit
Warn about missing intent or value

Work in progress. Warns at declaration, assignment and possible modification of
a procedure argument.

[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Marc Glisse from comment #11)
> (In reply to Richard Biener from comment #10)
> > Wit GCC 9 and trunk we are left with
> > 
> >[local count: 118111600]:
> >   MEM[(int *)&D.30957] = 85899345930;
> >   D.30957[2] = 30;
> >   _33 = operator new (12);
> >   __builtin_memcpy (_33, &D.30957, 12);
> >   _41 = MEM[(const int &)_33];
> >   __init_42 = _41 + 100;
> >   _50 = MEM[(const int &)_33 + 4];
> >   __init_19 = __init_42 + _50;
> >   _14 = MEM[(const int &)_33 + 8];
> >   __init_16 = _14 + __init_19;
> >   operator delete (_33);
> >   D.30957 ={v} {CLOBBER};
> >   return __init_16;
> > 
> > here I think operator new clobbers D.30957 which escapes at the memcpy call.
> 
> I thought we had code saying that nothing can escape through memcpy?
> 
> > This prevents a late FRE from doing its job (not sure if a late one is
> > really needed).
> 
> With
> 
> #include 
> inline void* operator new(std::size_t n){return __builtin_malloc(n);}
> inline void operator delete(void*p)noexcept{__builtin_free(p);}
> inline void operator delete(void*p,std::size_t)noexcept{__builtin_free(p);}
> 
> I get
> 
>   _33 = __builtin_malloc (12);
>   MEM[(char * {ref-all})_33] = 85899345930;
>   MEM[(char * {ref-all})_33 + 8B] = 30;
>   _12 = MEM[(const int &)_33];
>   __init_49 = _12 + 100;
>   _38 = MEM[(const int &)_33 + 4];
>   __init_36 = _38 + __init_49;
>   _14 = MEM[(const int &)_33 + 8];
>   __init_16 = _14 + __init_36;
>   __builtin_free (_33);
>   return __init_16;
> 
> where FRE should work.

It does (late FRE is now in).  Even DOM could have handled the memory refs
but it fails to forward the pointer adjustment for the second load and
also seems to be confused about alias type differences.  IL before DOM:

  __BB(2,guessed_local(118111600)):
  _34 = __builtin_malloc (12ul);
  _32 = _34 + 12ul;
  __MEM  ((char * {ref-all})_34) = 10;
  __MEM  ((char * {ref-all})_34 + _Literal (char * {ref-all}) 4) = 20;
  __MEM  ((char * {ref-all})_34 + _Literal (char * {ref-all}) 8) = 30;
  __l ={v} {CLOBBER};
  __init_3 = 110;
  _2 = _34 + 4ul;
  _19 = 2ul;
  _35 = __MEM  ((const int &)_34 + _Literal (const int &) 4);
  __init_26 = __init_3 + _35;
  _45 = _2 + 4ul;
  _22 = _19 + 18446744073709551615ul;
  _23 = __MEM  ((const int &)_2 + _Literal (const int &) 4);
  __init_16 = _23 + __init_26;
  _17 = _45 + 4ul;
  _14 = _22 + 18446744073709551615ul;
  __builtin_free (_34);
  D_29464 ={v} {CLOBBER};
  D_29464 ={v} {CLOBBER};
  return __init_16;

and the reason why DOM doesn't handle the first load is equal_mem_array_ref_p
dispatches to operand_equal_p but that considers the refs non-equal
(that's correct - DOM should have used OEP_ADDRESS_OF here since we already
constrained the access otherwise).  For DOM this leaves the failed CSE
of the second load.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c++ |libstdc++

--- Comment #5 from Jonathan Wakely  ---
I think this is a libstdc++ bug, because Clang has always rejected the example
with any version of the libstdc++ headers. And I know what's going on, and
might have a fix.

[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode

[andrewm.roberts at sky dot com]

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

--- Comment #9 from Andrew Roberts  ---
For completeness I've also built gcc 8.3.0 with in tree gmp 6.1.2 using the
newly built 9.1.0. And then in turn used this gcc 8.3.0 to rebuild gcc 9.1.0
with in tree gmp.

So the host gcc 8.3.0 doesn't work building gcc with in tree gmp.
But all the versions I have built (9.1.0 and 8.3.0) build this correctly.

[Bug c++/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #5 from Hanoch Haim  ---
It was fast. 

The way to build are here

https://github.com/cisco-system-traffic-generator/trex-core/wiki#how-to-build-trex

```
$ git clone g...@github.com:cisco-system-traffic-generator/trex-core.git
$cd linux_dpdk
$./b configure  
$./b build

```


with gcc 7.x/8.x only this function are with wrong optimization 


if anything else is needed I would provide it

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug c++/91043] GCC produces unaligned vmovdqa vector data access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-07-01
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Please provide preprocessed source and the full compiler command-line to
reproduce.  See https://gcc.gnu.org/bugs.html

[Bug c++/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #3 from Hanoch Haim  ---
With Ubuntu gcc7.4 package, there is no bug. 
I've built the gcc from source and it has an issue. There are a diffrent
configuration values

[Bug web/90334] documentation for getting read-write SVN access is misleading

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Maybe just saying "sourceware.org / gcc.gnu.org" would be good enough to avoid
confusion. That's obviously not a URL that you're supposed to copy & paste.

[Bug c++/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

--- Comment #2 from Hanoch Haim  ---
/usr/local/gcc-8.3/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-8.3/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.3/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=c,c++
--prefix=/usr/local/gcc-8.3
Thread model: posix
gcc version 8.3.0 (GCC) 
[csi-kiwi-03]>

[Bug c++/91043] GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

Hanoch Haim  changed:

   What|Removed |Added

 Target||x86
   Host||x86

--- Comment #1 from Hanoch Haim  ---
/usr/local/gcc-7.4/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-7.4/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-7.4/libexec/gcc/x86_64-pc-linux-gnu/7.4.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib --enable-languages=c,c++
--prefix=/usr/local/gcc-7.4
Thread model: posix
gcc version 7.4.0 (GCC) 
[csi

[Bug c++/91043] New: GCC produces unaligned vmovdqa vector data access

[hhaim at cisco dot com]

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

Bug ID: 91043
   Summary: GCC produces unaligned vmovdqa vector data access
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hhaim at cisco dot com
  Target Milestone: ---

**The project**: 
https://github.com/cisco-system-traffic-generator/trex-core

**how to compile**: 
https://github.com/cisco-system-traffic-generator/trex-core/wiki#how-to-build-trex

The commit with a workaround:

https://github.com/cisco-system-traffic-generator/trex-core/commit/39e7f535f96f0f5b4406db667be7bc775ce3e515

**The issue**: 
gcc 7/8 generate vector instruction on a variables that was allocated by the
gcc and it seems as not aligned 


the struct is defined like that 

static CGlobalTRex g_trex;

It includes 

CLatencyManager m_mg; 

which includes 

CLatencyManagerPerPort  m_ports[TREX_MAX_PORTS];


class CLatencyManagerPerPort {
public:
 CCPortLatency  m_port;   << crash is on the function reset of this
object 
 CPortLatencyHWBase  *  m_io;
 uint32_t   m_flag;
};


**Workaround**: 

Adding no-sse to this function solves the issue 

__attribute__((noinline,target("no-sse2"))) 
void CCPortLatency::reset(){





void CCPortLatency::reset(){


warning: bad breakpoint number at or near '0x585763'
(gdb) disassemble 0x585763 
Dump of assembler code for function CCPortLatency::Create(unsigned char,
unsigned short, unsigned short, unsigned short, CCPortLatency*,
CLatencyPktMode*, CNatRxManager*):
   0x005856a0 <+0>: push   %rbp
   0x005856a1 <+1>: mov%rsp,%rbp
   0x005856a4 <+4>: push   %r12
   0x005856a6 <+6>: push   %r10
   0x005856a8 <+8>: lea0x10(%rbp),%r10
   0x005856ac <+12>:push   %rbx
   0x005856ad <+13>:mov%rdi,%rbx
   0x005856b0 <+16>:sub$0x8,%rsp
   0x005856b4 <+20>:mov(%r10),%rax
   0x005856b7 <+23>:movb   $0x0,0x3f(%rbx)
   0x005856bb <+27>:mov0x8(%r10),%rdi
   0x005856bf <+31>:mov%rax,(%rbx)
   0x005856c2 <+34>:test   %rax,%rax
   0x005856c5 <+37>:je 0x585795 
   0x005856cb <+43>:mov%esi,%eax
   0x005856cd <+45>:mov%sil,0x31(%rbx)
   0x005856d1 <+49>:movzbl %sil,%esi
   0x005856d5 <+53>:not%eax
   0x005856d7 <+55>:mov%rdi,0x8(%rbx)
   0x005856db <+59>:and$0x1,%eax
   0x005856de <+62>:movb   $0x1,0x3e(%rbx)
   0x005856e2 <+66>:movl   $0x12345678,0x28(%rbx)
   0x005856e9 <+73>:movl   $0x1,0x38(%rbx)
   0x005856f0 <+80>:mov%cx,0x34(%rbx)
   0x005856f4 <+84>:mov%dx,0x32(%rbx)
   0x005856f8 <+88>:mov%r8w,0x36(%rbx)
   0x005856fd <+93>:mov%r9,0x10(%rbx)
   0x00585701 <+97>:mov%al,0x19(%rbx)
   0x00585704 <+100>:   mov%al,0x18(%rbx)
   0x00585707 <+103>:   movq   $0x0,0x1c(%rbx)
   0x0058570f <+111>:   cmpb   $0x0,0xc2e938(%rsi)
   0x00585716 <+118>:   je 0x585721 
   0x00585718 <+120>:   movb   $0x1,0x24(%rbx)
   0x0058571c <+124>:   movb   $0x1,0x24(%r9)
   0x00585721 <+129>:   lea0x100(%rbx),%r12
---Type  to continue, or q  to quit---
   0x00585728 <+136>:   mov%r12,%rdi
   0x0058572b <+139>:   callq  0x590320 
   0x00585730 <+144>:   mov0x6a8449(%rip),%rdi# 0xc2db80

   0x00585737 <+151>:   callq  0x4c5be0 
   0x0058573c <+156>:   mov0x28(%rbx),%eax
   0x0058573f <+159>:   mov%r12,%rdi
   0x00585742 <+162>:   vpxor  %xmm0,%xmm0,%xmm0
   0x00585746 <+166>:   movb   $0x0,0x30(%rbx)
   0x0058574a <+170>:   movq   $0x0,0xc0(%rbx)
   0x00585755 <+181>:   movq   $0x0,0xc8(%rbx)
   0x00585760 <+192>:   mov%eax,0x2c(%rbx)
=> 0x00585763 <+195>:   vmovdqa %ymm0,0x40(%rbx) << crash here
   0x00585768 <+200>:   vmovdqa %ymm0,0x60(%rbx)
   0x0058576d <+205>:   vmovdqa %ymm0,0x80(%rbx)
   0x00585775 <+213>:   vmovdqa %ymm0,0xa0(%rbx)

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Possible dup of PR90756 ?

[Bug web/63873] target links in Concepts Index in gccint do not work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Jonathan Wakely  ---
Since this seems to be confusing people, the bug is not "the URL gives a 4040
error", it's that there is no index-INIT_005fEXPR-1907 anchor that the
#index-INIT_005fEXPR-1907 fragment can link to.

So the index entry links to the top of the page, not to the docs for INIT_EXPR.

And that is not fixed, because there are no ID or NAME attributes anywhere in
the page, so no #foobar fragment will ever link anywhere except the top of the
page.

[Bug c++/91040] [9/10 Regression] Incorrect "invalid use of non-lvalue array" error in conditional assignment with throw

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-01
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0

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

[Bug libgcc/90929] libgcc MIPS __clear_cache shouldn't be a no-op

[dragan.mladjeno...@rt-rk.com]

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

Dragan Mladjenovic  changed:

   What|Removed |Added

 CC||dragan.mladjeno...@rt-rk.co
   ||m

--- Comment #2 from Dragan Mladjenovic  ---
For mips64-linux-gnuabi64 the backend emits the direct call to libc's
_flush_cache so the __clear_cache is never used. This test invokes
__clear_cache explicitly, but there is another issue in that llvm will use
__clear_cache libcall for __builtin___clear_cache on mips, so it won't work
unless you ship/link the compiler_rt along with it.

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
This fails for all versions (7,8,9) for me:

$ cat pr91042.cc
typedef enum { Op_swap_rb, Op_matrix_3x3 } Op;
template  struct A {
  typedef T __attribute__((vector_size(N * sizeof(T V;
};
template  using Vec = typename A::V;
using F = Vec<4, float>;
using U8 = Vec<4, unsigned char>;
template  void store(P p1, T p2) {
  __builtin_memcpy(p1, &p2, sizeof(p2));
}
template  D cast(S p1) { return D{p1[3]}; }
Op *a;
int b;
F c, d;
void exec_ops() {
  while (true)
switch (*a) {
case Op_swap_rb: {
  F t = c;
  c = d;
  d = t;
}
case Op_matrix_3x3:
  __attribute__((__vector_size__(4))) unsigned char e = cast(d);
  store(&b, e);
}
}

[Bug other/89259] liboffloadmic/runtime/offload_omp_host.cpp:692: pointless test ?

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-01
 CC||hjl.tools at gmail dot com,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
I can confirm that.

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to ktkachov from comment #6)
> ahh, GCC 7 ICEs on the full testcase for me, but not on the reduced one

Yes, you are right. I'm reducing that one more time with GCC7.

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
ahh, GCC 7 ICEs on the full testcase for me, but not on the reduced one

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[ktkachov at gcc dot gnu.org]

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

--- Comment #5 from ktkachov at gcc dot gnu.org ---
(In reply to Martin Liška from comment #4)
> @Kyril: Is it really failing for GCC 7.x ?
> 
> For me it works:
> 
> $ arm-suse-linux-gnueabi-g++-7 -v
> gcc version 7.4.1 20190424 [gcc-7-branch revision 270538] (SUSE Linux) 
> 
> $ arm-suse-linux-gnueabi-g++-7 ~/Programming/testcases/pr91042.cc -c -O2
> In function 'void store(P, T) [with T = __vector(4) unsigned int; P = int*]',
> inlined from 'void exec_ops()' at
> /home/marxin/Programming/testcases/pr91042.cc:23:12:
> /home/marxin/Programming/testcases/pr91042.cc:8:19: warning: 'void*
> __builtin_memcpy(void*, const void*, unsigned int)' writing 16 bytes into a
> region of size 4 overflows the destination [-Wstringop-overflow=]
>__builtin_memcpy(p1, &p2, sizeof(p2));
>^

Yeah, it ICE's for me (even with 6.5.0), just double-checked:
gcc version 7.4.1 20190627

--with-arch=armv7-a --with-fpu=neon --with-float=hard --with-arch=armv7-a

[Bug middle-end/88056] gcc/config/i386/host-mingw32.c:170: use of out of scope pointer ?

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, it's really a use-after-scope issue.

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
@Kyril: Is it really failing for GCC 7.x ?

For me it works:

$ arm-suse-linux-gnueabi-g++-7 -v
gcc version 7.4.1 20190424 [gcc-7-branch revision 270538] (SUSE Linux) 

$ arm-suse-linux-gnueabi-g++-7 ~/Programming/testcases/pr91042.cc -c -O2
In function 'void store(P, T) [with T = __vector(4) unsigned int; P = int*]',
inlined from 'void exec_ops()' at
/home/marxin/Programming/testcases/pr91042.cc:23:12:
/home/marxin/Programming/testcases/pr91042.cc:8:19: warning: 'void*
__builtin_memcpy(void*, const void*, unsigned int)' writing 16 bytes into a
region of size 4 overflows the destination [-Wstringop-overflow=]
   __builtin_memcpy(p1, &p2, sizeof(p2));
   ^

[Bug middle-end/91042] [7/8/9 Regression] ICE in convert_move, at expr.c:218

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat pr91042.cc
typedef enum { Op_swap_rb, Op_matrix_3x3 } Op;
template  struct A {
  typedef T __attribute__((vector_size(N * sizeof(int V;
};
template  using Vec = typename A::V;
using F = Vec<4, float>;
template  void store(P p1, T p2) {
  __builtin_memcpy(p1, &p2, sizeof(p2));
}
Op a;
int b;
F c, d;
__attribute__((__vector_size__(4 * sizeof(int unsigned e;
void exec_ops() {
  while (true)
switch (a) {
case Op_swap_rb: {
  F t = c;
  c = d;
  d = t;
}
case Op_matrix_3x3:
  store(&b, e);
}
}