[Bug tree-optimization/91033] [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
08:57 < richi> jakub: can we delay scatter/gather store recog to 
   vectorizable_store/load, thus always detect the dataref pattern 
   but only later decide if we can vectorize it?
08:58 < richi> jakub: this way we could also decide, based on cost, to do 
   strided accesses / vector construction instead (might be 
   profitable for V2DF for example)

[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code, lto
   Priority|P3  |P1
 CC||hubicka at gcc dot gnu.org

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-01
 Blocks||85316
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
[Bug 85316] [meta-bug] VRP range propagation missed cases

[Bug target/91041] obsolete arm-pe support in arm backend

[wilson at gcc dot gnu.org]

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

--- Comment #1 from Jim Wilson  ---
FYI I noticed this while trying to answer a question on gcc-help, otherwise I'm
not doing any arm work at present.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |10.0

[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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||arm-linux-gnueabihf

--- Comment #7 from Richard Biener  ---
We configure GMP for none-*-* to disable CPU specific paths and later pass
AM_CFLAGS="-DNO_ASM" which should disable more of that.

If this doesn't work anymore then it has to be adjusted.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to work||8.3.0
   Target Milestone|--- |9.2
Summary|Incorrect "invalid use of   |[9/10 Regression] Incorrect
   |non-lvalue array" error in  |"invalid use of non-lvalue
   |conditional assignment with |array" error in conditional
   |throw   |assignment with throw
  Known to fail||9.1.0

[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Martin Liška  ---
(In reply to Ren Kimura from comment #3)
> Hi. Sorry for late. I've just attached more simple one.
> 
> PoC file for this bug can be created easily, just generating ELF file and
> edit e_shstrndx in ELF header file to 0.
> 
> Attached one is built from simple Hello World program.
> 
> #include 
> int main() {
>   printf("Hello World\n");
> };
> 
> gcc -o memcorrupt_nm-2.30_gcc-9.1.0_gold_simple hello_world.c
> 
> Edit e_shtrndx (offset 0x3E) to 0.

What sense does it make to create a valid ELF container and then corrupt it?
It's expected that various tools will crash then.

[Bug tree-optimization/91026] switch expansion produces a jump table with trivial entries

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Switch conversion bails out because it knowns that a jump table (or a bit test
can) be used for this snippet. Then we prefer to use a jump table then a bit
test. With -fno-jump-tables we generate the same code.
That said, I confirm it's a small limitation.

[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 #2 from Jonathan Wakely  ---
But "or" would be wrong because there is only one server and only one account.
You can't have an account on sourceware.org and not on gcc.gnu.org, or vice
versa.

And you certainly can't have an account on http://sourceware.org/gcc.gnu.org
because you have an account on the server, not some URL. What were you
expecting that "link" to go to? Your account?

It might be better to use mailto: for the email address, but I'm not convinced
your suggestion would be an improvement.

[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 #3 from Jonathan Wakely  ---
Or in other words...

(In reply to Roland Illig from comment #0)
> Therefore I pasted sourceware.org/gcc.gnu.org to the URL bar of my browser
> and got redirected to https://sourceware.org/gcc.gnu.org, which says 404.

So don't do that then :-)

[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

--- Comment #3 from Jonathan Wakely  ---
It doesn't look fixed to me.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
So two things:
1) sourceware.org/gcc.gnu.org is a standard way of saying the machines are the
exact same machine.  This is NOT an URL.  It is like writing "glass/mug you
have is nice looking".  

https://www.grammarly.com/blog/slash/

2) The no link for the email address is to reduce the spam to that email
address.

[Bug libstdc++/81806] Split in pbds works in O(n) instead of O(log n)

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Do you actually use these containers?

Feedback on https://gcc.gnu.org/ml/libstdc++/2019-05/msg00107.html would be
useful.

[Bug libstdc++/81670] include/ext/pb_ds/detail/splay_tree_/splay_fn_imps.hpp:253: suspicious assignment ?

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Right, see https://gcc.gnu.org/ml/libstdc++/2019-05/msg00107.html

[Bug middle-end/91042] New: ICE in convert_move, at expr.c:218

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

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

Bug ID: 91042
   Summary: ICE in convert_move, at expr.c:218
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: armv7l-*-*

Created attachment 46538
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46538&action=edit
Test case

$ g++ -w -O2 -c skcms.ii
during RTL pass: expand
In file included from
../../3rdparty/chromium/third_party/skia/third_party/skcms/skcms.cc:1867:
../../3rdparty/chromium/third_party/skia/third_party/skcms/src/Transform_inl.h:
In function 'void baseline::exec_ops(const Op*, const void**, const char*,
char*, int)':
../../3rdparty/chromium/third_party/skia/third_party/skcms/src/Transform_inl.h:640:13:
internal compiler error: in convert_move, at expr.c:218
  640 | static void exec_ops(const Op* ops, const void** args,
  | ^~~~
$ g++ --version
g++ (SUSE Linux) 9.1.1 20190611 [gcc-9-branch revision 272147]

[Bug lto/91028] [10 Regression] g++.dg/lto/alias-2 FAILs with -fno-use-linker-plugin

[hubicka at gcc dot gnu.org]

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

--- Comment #1 from Jan Hubicka  ---
Author: hubicka
Date: Mon Jul  1 09:05:07 2019
New Revision: 272852

URL: https://gcc.gnu.org/viewcvs?rev=272852&root=gcc&view=rev
Log:

PR lto/91028
PR lto/90720
* g++.dg/lto/alias-1_0.C: Add loop to make inlining happen with
-fno-use-linker-plugin
* g++.dg/lto/alias-2_0.C: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/alias-1_0.C
trunk/gcc/testsuite/g++.dg/lto/alias-2_0.C

[Bug ipa/90720] g++.dg/lto/alias-1 FAILs

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  ---
Author: hubicka
Date: Mon Jul  1 09:05:07 2019
New Revision: 272852

URL: https://gcc.gnu.org/viewcvs?rev=272852&root=gcc&view=rev
Log:

PR lto/91028
PR lto/90720
* g++.dg/lto/alias-1_0.C: Add loop to make inlining happen with
-fno-use-linker-plugin
* g++.dg/lto/alias-2_0.C: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/lto/alias-1_0.C
trunk/gcc/testsuite/g++.dg/lto/alias-2_0.C

[Bug middle-end/91042] 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
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-01
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||9.1.0

--- Comment #1 from Martin Liška  ---
I can confirm that with GCC 9.1 cross compiler, I'm reducing that.

[Bug lto/89884] g++.dg/lto/pr89335 FAILs

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #2 from Jan Hubicka  ---
The problem here is that -fno-use-linker-plugin implies fat LTO. So we compile
the code twice - once at compile time and once at link-time and therefore also
output the warning twice.

I do not see how to prevent this from hapenning - this is behaviour of all late
warnings with -ffat-lto-objects.

Is there a way to make testcase tolerate duplicated warnings or limit to plugin
enabled only?

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||ktkachov at gcc dot gnu.org
  Known to work||10.0
  Known to fail|9.1.0   |7.4.1, 8.3.1, 9.1.1

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed on the branches. May need -mfloat-abi=soft depending on your
configuration. Doesn't ICE on trunk though.

[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 #8 from Andrew Roberts  ---
Build of 9.1.0 using system gmp worked fine. 
Rebuild of 9.1.0 with in tree gmp-6.1.2 using that version of gcc
also worked fine.

Thus probably a host gcc compiler problem,
I'll report to Raspbian.

[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
(In reply to David Binderman from comment #3)
> --language=c++ seems to be required for C++ code.

That works for me, thank you!

> 
> --force helps cppcheck to avoid a too-early finish.
> 
> I use the current development cppcheck code, although it's fair to say that
> new features rarely work 100% perfectly first time and usually take a week
> or two before they mature on real code. 

Yep, I've just bumped openSUSE package to the latest release that was released
few days ago.

> 
> But that's development code for you ;->

[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);
}
}

[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

[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

[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

[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 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 #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 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 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 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 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 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 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] 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 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 #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 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 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

[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 #9 from Hanoch Haim  ---
Attached. I hope this is what you are looking for.

[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

[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 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

[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/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 #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

[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

[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

[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 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 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

[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 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 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 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 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 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 #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 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 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 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 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/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 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

John David Anglin  changed:

   What|Removed |Added

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

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

[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/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 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 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 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 #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 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 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 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 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] 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 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/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 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.