[Bug tree-optimization/38497] PRE missing a load PRE which causes a loop to have two BBs

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Richard Biener from comment #5)
> now what is left is hoisting *a_2(D) to after the call.  But that's not PRE.

Yes I agree with this but hoisting was added to PRE and we still don't optimize
it ...

[Bug tree-optimization/80617] [missed optimization] Storing constant in two possibly-aliased locations

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Richard Biener from comment #6)
> C testcase:

I have seen that testcase before in a bug report but I can't find the bug
report  :(.

[Bug fortran/80164] ICE in gfc_format_decoder at gcc/fortran/error.c:933

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #7 from Jerry DeLisle  ---
I will take this over, test the proposed patch, and see where we get soon.

[Bug tree-optimization/80726] [7/8 Regression] Destructor not inlined anymore (regression)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-06-26
   Target Milestone|--- |7.2
Summary|Destructor not inlined  |[7/8 Regression] Destructor
   |anymore (regression)|not inlined anymore
   ||(regression)
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Considering inline candidate Foo::~Foo().
  not inlinable: void f()/4 -> Foo::~Foo()/3, callee refers to comdat-local
symbols
Iterations: 0


If I use:
bool shouldThrow = false;

template  inline void ff() {
   if (shouldThrow) throw "hmm";
}

void f() {
ff<1>();
}

 CUT 
It works.  I don't see any difference between the two really.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[angelo70 at gmail dot com]

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

--- Comment #17 from angelo  ---
Hi Carlos,

maybe you can try one of these 2 toolchains i prepared years ago:

http://sysam.it/toolchains.html

Regads,
Angelo

On 25/06/2017 20:40, csotoalonso at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
>
> Carlos Soto  changed:
>
> What|Removed |Added
> 
>   CC||csotoalonso at gmail dot com
>
> --- Comment #16 from Carlos Soto  ---
> Any news on this bug?
>
> Currently I'm trying to get a 5485 board working with linux and I'm facing the
> fact that there's no working toolchain available anymore.
>
> It would be great to have this old boards up and running again
>

[Bug fortran/52473] CSHIFT slow - inline it?

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #15 from Thomas Koenig  ---
What was done so far was an improvement for cshifts of large
arrays.

The code in the original program has quite small arrays, so
inlining would actually make sense there.

I don't think I will start this any time soon; unassigning.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[csotoalonso at gmail dot com]

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

Carlos Soto  changed:

   What|Removed |Added

 CC||csotoalonso at gmail dot com

--- Comment #16 from Carlos Soto  ---
Any news on this bug?

Currently I'm trying to get a 5485 board working with linux and I'm facing the
fact that there's no working toolchain available anymore.

It would be great to have this old boards up and running again

[Bug target/81201] The final asm code doesn't check if a function changes the value of ebx, resulting in segmentation fault.

[arget at autistici dot org]

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

--- Comment #2 from arget at autistici dot org ---
Well... this is embarrasing, ok... XD
I though the problem was in the ebx, because returning from chacha(), ebx =
0... but now I looked carefully the chacha() asm code and there isn't any
operation on ebx register, so I don't know why ebx was 0.
Well, the code now runs on 32 bits and in raspbian.
Sorry, and thanks a lot.

[Bug target/81201] The final asm code doesn't check if a function changes the value of ebx, resulting in segmentation fault.

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
memcpy([4], chachaKey, 64) writes past the array bounds.

[Bug c++/81202] New: Concept parsing error for default template arguments

[kmp53 at sina dot com]

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

Bug ID: 81202
   Summary: Concept parsing error for default template arguments
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kmp53 at sina dot com
  Target Milestone: ---

I found an parsing error for the default template parameter for Concept, and
the same syntax is correct in constexpr.

template constexpr bool
IsPtrC=std::is_pointer_v&&(std::is_same_v
||std::is_same_v);
template concept bool IsPtrC2=IsPtrC;
tple using TEST=int;
int main(int argc,char*argv[]){
  TEST i;//OK
  TEST j;//error: parse error in template argument list
  TEST> k;//OK
  TEST<(IsPtrC2)> l;//OK
}

[Bug c/81201] New: The final asm code doesn't check if a function changes the value of ebx, resulting in segmentation fault.

[arget at autistici dot org]

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

Bug ID: 81201
   Summary: The final asm code doesn't check if a function changes
the value of ebx, resulting in segmentation fault.
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arget at autistici dot org
  Target Milestone: ---

Created attachment 41628
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41628=edit
GCC preprocessed code of the source code described above on raspbian.

Hi, compiling with gcc version 6.3.0:
arget@plata:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18) 
arget@plata:~$ uname -a
Linux plata 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u1 (2017-06-18) x86_64
GNU/Linux

There is problem with the following code. It's just my own implementation of
the ChaCha20 stream cipher like CSPRNG (Cryptographically Secure Pseudo-Random
Number Generator, something like random() but safer):

#include 
#include 
#include 

#define NONCE "\x00\x00\x00\x09\x00\x00\x00\x4a\x00\x00\x00\x00"

#define RtoL(x, n) \
((x << n) | (x >> (32 - n)))

#define QR(a, b, c, d) \
estado[a] += estado[b]; estado[d] ^= estado[a]; estado[d] = RtoL(estado[d],
16); \
estado[c] += estado[d]; estado[b] ^= estado[c]; estado[b] = RtoL(estado[b],
12); \
estado[a] += estado[b]; estado[d] ^= estado[a]; estado[d] = RtoL(estado[d],
8); \
estado[c] += estado[d]; estado[b] ^= estado[c]; estado[b] = RtoL(estado[b],
7);

// "expand 32-byte k"
static const uint32_t chachaConst[4] = {0x61707865,
0x3320646e,
0x79622d32,
0x6b206574};
static uint32_t chachaKey[8],
chachaCount = 0,
chachaNonce[3];
static uint8_t quedanPorLeer = 0,
   chachaRandomOutput[64];

static void chacha()
{
uint32_t estado[16];
uint32_t i;
memcpy(estado, chachaConst, 16);
memcpy([4], chachaKey, 64);
chachaCount++;
estado[12] = chachaCount;
memcpy([13], chachaNonce, 12);
memcpy(chachaRandomOutput, estado, 64);

for(i = 0; i < 10; i++)
{
QR(0, 4,  8, 12)
QR(1, 5,  9, 13)
QR(2, 6, 10, 14)
QR(3, 7, 11, 15)
QR(0, 5, 10, 15)
QR(1, 6, 11, 12)
QR(2, 7,  8, 13)
QR(3, 4,  9, 14)
}

uint32_t *q = (uint32_t*)chachaRandomOutput;
for(i = 0; i < 64; i++)
q[i] += estado[i];
}

void chachaSeed(const uint8_t s[32])
{
memcpy(chachaKey, s, 32);
memcpy(chachaNonce, NONCE, 12);
chachaCount = 0;
quedanPorLeer = 0;
}

uint8_t chachaGet()
{
if(!quedanPorLeer)
{
chacha();
quedanPorLeer = 64;
}
return chachaRandomOutput[64 - (quedanPorLeer--)];
}

int main()
{
chachaSeed((const
uint8_t*)"\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f");
int i;
for(i = 0; i < 64; i++)
printf("%c", chachaGet());
}

The ChaCha20-CSPRNG works similar to random() and srandom(), with chachaSeed()
you can set a 32 byte seed and chachaGet() will return the random values in
several calls to this function.
The values of the nonce and seed are the inputs used in the test vector of the
RFC-7539 (https://tools.ietf.org/html/rfc7539#section-2.3.2).
The program works great compiled for 64 bits:

arget@plata:~$ gcc a.c -o a

[Bug libgcc/81199] fallback definition of count_leading_zeros references hidden symbol

[coypu at sdf dot org]

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

--- Comment #2 from coypu  ---
To relay a comment on the netbsd bug,
"I don't think (the proposed idea) is correct and the real problem is that we
are linking libgcc first (again)."

[Bug libstdc++/81200] New: regex classatomcollatingelement

[hstong at ca dot ibm.com]

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

Bug ID: 81200
   Summary: regex classatomcollatingelement
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

The source below attempts to compile "_[[.left-square-bracket.]]_" as a egrep
regex pattern.
The collating symbol, [.left-square-bracket.], is only valid if
"left-square-bracket" is a multi-character collating element in the locale.
"left-square-bracket" is most assuredly not a multi-character collating element
in the "POSIX" locale.

Note: WG 21 document N1429 advocates the behaviour exhibited by the
implementation; however, it appears from N1623 (relevant portion quoted below)
that the committee made corrections:
"that is a bunch of portable names for characters, which are not the same as
collating elements within the meaning of POSIX locales"

The  implementation accepts the pattern (not expected), and the string
"_[_" matches (not expected).
grep -E seems to work as expected.

Online compiler: https://wandbox.org/permlink/VdEOUrcdcBqnbjLB

### SOURCE (llregex3.cc):
#include 

int main(void) {
  std::regex regex;
  regex.imbue(std::locale("POSIX"));

  try {
regex.assign("_[[.left-square-bracket.]]_", std::regex_constants::egrep);
printf("No error.\n");

bool b;
b = regex_match("_[_", regex);
printf("%s _[_.\n", b ? "Matched" : "Did not match");
  }
  catch (const std::regex_error ) {
if (e.code() == std::regex_constants::error_collate) {
  printf("Got error_collate.\n");
}
else {
  printf("Got other error.\n");
}
  }
}

### COMPILER INVOCATION:
g++ -std=c++11 llregex3.cc -o llregex3

### PROGRAM INVOCATION AND OUTPUT:
> ./llregex3
No error.
Matched _[_.
Return:  0x00:0

### EXPECTED PROGRAM OUTPUT:
Got error_collate.

### REFERENCE BEHAVIOUR (POSIX locale; grep -E):
> ( export LANG=POSIX; locale && grep -E '_[[.left-square-bracket.]]_' )
LANG=POSIX
LANGUAGE=en_US:en
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
grep: Invalid collation character
Return:  0x02:2

### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170623 (experimental) (GCC)

### grep --version:
grep (GNU grep) 2.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others, see
.

[Bug libfortran/81195] SPEC CPU2017 621.wrf_s failure with 40+ openmp threads

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
(In reply to Jim Wilson from comment #7)
> I have reproduced the same problem from the gcc-7 branch.

I fully expect this bug to be in all active branches
of gfortran.  We should commit a fix to all of them.

[Bug tree-optimization/79483] [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[dcb314 at hotmail dot com]

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

--- Comment #14 from David Binderman  ---
(In reply to Richard Biener from comment #13)
> Fixed on trunk sofar.

Odd. Looks broken to me in 20170622. Did the patch go in ?

[Bug middle-end/80775] [8 Regression] -O3 produces ice in group_case_labels_stmt

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 Status|CLOSED  |REOPENED
 Resolution|FIXED   |---

--- Comment #13 from David Binderman  ---
Same code now crashes in a different way:

bug355
during RTL pass: expand
XmL.c: In function ‘XmLDrawnBDrawCB’:
XmL.c:733:4: internal compiler error: in gimple_switch_label, at gimple.h:4525
0x56ad39 gimple_switch_label
../../trunk/gcc/gimple.h:4525
0xc3954d gimple_switch_label
../../trunk/gcc/tree.h:3083
0xc3954d gimple_switch_default_label
../../trunk/gcc/gimple.h:4545
0xc3954d expand_case(gswitch*)
../../trunk/gcc/stmt.c:1151

Flag -O3 required.

[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
Still seems to be broken, over a month later.

[Bug ada/62235] segmentation fault on Ada 2012 code

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Botcazou  ---
Please do *not* open the same bug report twice, this really doesn't help.

[Bug ada/62235] segmentation fault on Ada 2012 code

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
I'll have a look.

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

  Attachment #41605|0   |1
is obsolete||

--- Comment #54 from Daniel Santos  ---
Created attachment 41627
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41627=edit
darwin fixup (on top of v6) -- second attempt

So I've learned that some_symbol@GOTPCREL(%%rip) resolves to the the address of
the GOT *entry* for that symbol, which has to be dereferenced to get the
address of the object its self.  I was able to test this on my machine by
changing #ifdef __MACH__ to #ifndef and this patch is working using the GOT.

I've re-written do_test_body and added a macro LOAD_TEST_DATA_ADDR(dest) in
hopes to make both the sources fairly readable and the resulting assembly also
readable.  To simplify the routine, I changed mem_to_regs/regs_to_mem to use
r10 instead of rax so that I don't have to save and restore it.

Of course this is sub-optimal code, but the execution of the test program is by
no means the bottleneck -- I'm trying to keep it as simple and maintainable as
possible!

The macro has only two uses, so if you prefer, I can remove it and just replace
it with inline #if blocks, e.g.,

#ifdef __MACH__
"   mov " ASMNAME(test_data) "@GOTPCREL(%%rip), %%rax\n"
#else
"   lea " ASMNAME(test_data) "(%%rip), %%rax\n"
#endif

Thanks!
Daniel