[Bug other/82708] libmpx fails to compile due to PATH_MAX

[keno at juliacomputing dot com]

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

Keno Fischer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Keno Fischer  ---
I have unsuccessfully tried to make that option work. I am able to build glibc
with the bootstrap compiler, but the second stage build invariably fails. I ran
into a bunch of problems.

First, the build process looking for the headers in /sys-include rather
than /include where glibc installs them. Leads to the same symptoms as
reported in this issue.

Then, I tried using --with-sysroot which I wasn't using before, but then I got
confusion between /usr/include and /include (most parts of
the build system looking in usr/include, but others such as when building
libgcc seem to be looking in /include/). If I symlink those paths
together things progress farther but eventually fail to link. I also tried
replicating the glibc script you pointed to, without much luck (some mixture of
the above symptoms).

Given that I get a well functioning cross compiler, using the original recipe
with a simple patch to mpxrt-utils.c to bypass the broken limits.h file, I'm
tempted to move on and leave this be. I'll note at this point that e.g.
http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass2.html
also suggests patching the limits.h file manually, so at least I'm not the only
one.
I guess I had hoped that there was something that could be done in the gcc
build system to make this experience less frustrating for the next person.

If not that, a modern guide on how to do this by somebody who knows how it's
supposed to be would be great, since all the guides out there seem to have some
step of "and this is where we hack around gcc/glibc's broken build systems". It
sounds like things have improved since those guides were written, which is
great, but I have no idea what the right commands are.

I am grateful you took the time to answer my questions here.

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #34 from Markus Trippelsdorf  ---
Fixed.

[Bug c++/79092] template: type ignored if value already instantiated

[rivorus at gmail dot com]

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

--- Comment #3 from Matt Calabrese  ---
This bug is fairly nasty and I think should be higher priority. I suspect that
many people who use template auto will encounter it in very subtle ways. I
observed it deep in expression-template code by way of incorrect results and it
took a while to diagnose.

Even if people happen to not directly observe the issue, this bug can very
easily lead to ODR violations if different translation units happen to include
files that instantiate the template, but do so in different orders.

[Bug c++/79092] template: type ignored if value already instantiated

[rivorus at gmail dot com]

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

Matt Calabrese  changed:

   What|Removed |Added

 CC||rivorus at gmail dot com

--- Comment #2 from Matt Calabrese  ---
template struct val {};

struct type : val<0>, val<0u> {};

[Bug libstdc++/82684] std::complex template specializations require C99 Complex

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Closing then.

[Bug libstdc++/79283] read_symlink fails with /proc symlinks

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/82684] std::complex template specializations require C99 Complex

[web at cjhanks dot name]

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

--- Comment #2 from Christopher J. Hanks  ---
> > Putting the specializations and forward declarations in an `#if
> > _GLIBCXX_USE_C99_COMPLEX` block appears to allow code to compile as 
> > expected.
> 
> What code? What doesn't compile without those changes?

Apologies, I have conflated the C99 complex type operations with the GNU
extensions.

[Bug libstdc++/82706] 27_io/filesystem/operations/permissions.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Wed Oct 25 00:27:10 2017
New Revision: 254067

URL: https://gcc.gnu.org/viewcvs?rev=254067=gcc=rev
Log:
PR libstdc++/82706 fix test for case where operations succeed

PR libstdc++/82706
* testsuite/27_io/filesystem/operations/permissions.cc: Fix test.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/permissions.cc

[Bug libstdc++/82706] 27_io/filesystem/operations/permissions.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Should be fixed now.

[Bug libstdc++/70694] 50 experimental/filesystem/* failures on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
> Does the patch work?

Indeed!

[Bug libstdc++/70694] 50 experimental/filesystem/* failures on x86_64-apple-darwin10

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Jonathan Wakely  ---
Does the patch work?

[Bug libstdc++/71322] [DR 2720] std::filesystem::permissions always follows symlinks

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed for GCC 6.3 by r243554 and GCC 5.5 by r243557

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

[daniel at linux dot vnet.ibm.com]

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

--- Comment #33 from Daniel Black  ---
Works for me.

$ toolchain/bin/gcc -O1 -Wno-attributes -Wno-implicit-int  -c /tmp/x.c
$ toolchain/bin/gcc --version
gcc (GCC) 8.0.0 20171024 (experimental)

Thanks Markus, Martin, Honza.

[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||john.harper at vuw dot ac.nz

--- Comment #7 from Dominique d'Humieres  ---
*** Bug 82709 has been marked as a duplicate of this bug. ***

[Bug fortran/82709] f2008 complex%re and %im not yet implemented

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Dominique d'Humieres  ---
Dup.

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

[Bug libstdc++/82706] 27_io/filesystem/operations/permissions.cc FAILs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug other/82708] libmpx fails to compile due to PATH_MAX

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The expectation for bootstrapping such a cross toolchain is that GCC is 
configured and built twice.  The first build is static-only, C-only, 
inhibit-libc, disables lots of libraries such as libmpx.  That is used to 
build and install glibc.  The second build of GCC, configured with glibc 
present, is fully functional with all required languages.  See what 
glibc's build-many-glibcs.py script does for details of the modern 
approach for bootstrapping cross toolchains with glibc.

[Bug other/82708] libmpx fails to compile due to PATH_MAX

[keno at juliacomputing dot com]

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

--- Comment #4 from Keno Fischer  ---
Ah, ok sorry I was confused. I probably should have mentioned that I'm doing a
cross compile to a glibc based system, so I'm building the compiler, then
building glibc,
and then going back and building the runtime libraries. The exact script I'm
using is here:
https://github.com/staticfloat/julia-docker/blob/master/workerbase/lib/build_crosscompiler.sh

So at the compiler build stage, the limits.h header indeed does not exist, but
it does exist once we go back to build the rest of the runtime libraries
(because we built glibc in the meantime). Is there something I should be
running to regenerate these files before building the runtime libraries?

[Bug fortran/82709] New: f2008 complex%re and %im not yet implemented

[john.harper at vuw dot ac.nz]

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

Bug ID: 82709
   Summary: f2008 complex%re and %im not yet implemented
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

IMHO This program is valid f2008 but gfortran won't compile it. Evidence:

cayley[~/Jfh] % cat cplx.f90
! Works with ifort -stand f95 but not gfortran -std=f2008 
  implicit none
  complex:: z = (1,2)
  print *,z%re
  print *,z%im
end program
cayley[~/Jfh] % /usr/bin/gfortran -std=f2008 cplx.f90 
cplx.f90:4:12:

   print *,z%re
1
Error: Unexpected ‘%’ for nonderived-type variable ‘z’ at (1)
cplx.f90:5:12:

   print *,z%im
1
Error: Unexpected ‘%’ for nonderived-type variable ‘z’ at (1)
cayley[~/Jfh] % /usr/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.3.1 20170109 (GCC) 
cayley[~/Jfh] %

[Bug middle-end/80295] [7 Regression] ICE in __builtin_update_setjmp_buf expander

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #15 from Paolo Carlini  ---
Fixed in the branch too.

[Bug middle-end/80295] [7 Regression] ICE in __builtin_update_setjmp_buf expander

[paolo at gcc dot gnu.org]

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

--- Comment #14 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Oct 24 22:46:19 2017
New Revision: 254063

URL: https://gcc.gnu.org/viewcvs?rev=254063=gcc=rev
Log:
gcc/ChangeLog

2017-10-24  Qing Zhao 
Wilco Dijkstra 

* builtins.c (expand_builtin_update_setjmp_buf): Add a
converstion to Pmode from the buf_addr.

gcc/testsuite/ChangeLog

2017-10-24  Qing Zhao 
Wilco Dijkstra 

PR middle-end/80295
* gcc.target/aarch64/pr80295.c: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr80295.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/builtins.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict

[erenon2 at gmail dot com]

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

Benedek  changed:

   What|Removed |Added

 CC||erenon2 at gmail dot com

--- Comment #6 from Benedek  ---
The following code reproduces this, or a very similar issue:

#define STORE(SECTION, STRING) \
  __attribute__((section(SECTION), used)) \
  static constexpr const char* s[] = { STRING }

void f()
{
  STORE(".custom", "normal_foobar");
}

inline void g()
{
  STORE(".custom", "inline_foobar");
}

template 
void h()
{
  STORE(".custom", "template_foobar");
}

int main()
{
  f(); g(); h();
  return 0;
}

$ g++ -std=c++11 section.cpp
section.cpp: error: 's' causes a section type conflict with 's'

GCC 4.8, 5.2, 7.2, and trunk are affected (x86-64, checked on godbolt).
Depending on the compiler version, either the normal and the inline, or the
normal and the function template clashes.

I suppose because of how comdat is handled, they might have slightly different
needs, but it would be really nice to make it easier for the user.

(Clang compiles it fine)

[Bug other/82708] libmpx fails to compile due to PATH_MAX

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
That's not the test I'm talking about.  The relevant one is 
gcc/Makefile.in's LIMITS_H_TEST, run during a build stage rather than a 
configure stage, so you need to look at the setting of 
BUILD_SYSTEM_HEADER_DIR and how it got that value.

[Bug other/82708] libmpx fails to compile due to PATH_MAX

[keno at juliacomputing dot com]

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

--- Comment #2 from Keno Fischer  ---
It looks like different parts of the build system may be disagreeing on that. I
see

checking limits.h usability... yes

in the log in one place and then

checking limits.h usability... no

later in the same log. Are there different usability checks for this header?

[Bug other/82708] libmpx fails to compile due to PATH_MAX

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
If you have correctly configured GCC so that it can find the system 
headers at configure time, include-fixed/limits.h should be constructed as 
a concatentation of limitx.h, glimits.h and limity.h and thus include 
libc's limits.h indirectly.  If $(LIMITS_H_TEST) failed to find the system 
headers, that's what you should be debugging.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[joseph at codesourcery dot com]

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

--- Comment #28 from joseph at codesourcery dot com  ---
Well, I also think the existing choice is the more natural choice for the 
value of __LINE__ in this case (#line is mainly for use by code 
generators, which can always count lines and specify the desired number 
when changing the filename).  And the note on the patch "Note that this 
solution is not robust; hiding the __LINE__ reference inside another macro 
will bypass this special case test." indicates changing the choice is not 
so simple after all (having a choice of line number that depends on 
whether __LINE__ is inside another macro seems even less natural).

[Bug libstdc++/82706] 27_io/filesystem/operations/permissions.cc FAILs

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|*-*-solaris2.11 |*-*-solaris2.11
   ||x86_64-apple-darwin16
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-24
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Same thing on  x86_64-apple-darwin16.

[Bug other/82708] New: libmpx fails to compile due to PATH_MAX

[keno at juliacomputing dot com]

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

Bug ID: 82708
   Summary: libmpx fails to compile due to PATH_MAX
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keno at juliacomputing dot com
  Target Milestone: ---

In trying to build gcc on musl-based Alpine linux, I encountered the following
error:
```
/src/gcc-7.2.0/libmpx/mpxrt/mpxrt-utils.c:72:23: error: ‘PATH_MAX’ undeclared
here (not in a function); did you mean ‘INT8_MAX’?
 #define MAX_FILE_NAME PATH_MAX
   ^
/src/gcc-7.2.0/libmpx/mpxrt/mpxrt-utils.c:95:22: note: in expansion of macro
‘MAX_FILE_NAME’
 static char out_name[MAX_FILE_NAME];
  ^
```
I was confused by this at first because musl defines PATH_MAX in limits.h which
appears to be included from that file, but looking at the `-E` output it turns
out that it uses `include-fixed/limits.h` instead, which doesn't have that
definition. I don't know enough about GCC's build system to determine what's at
fault here (maybe it shouldn't be using that limits.h?)

In searching the internet, there are a number of reports of this error from
various other system configurations as well, so this like a fairly common
problem when building gcc.

[Bug tree-optimization/82707] ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug tree-optimization/82707] New: ICE in verify_gimple_in_cfg at tree-cfg.c:5395

[ro at gcc dot gnu.org]

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

Bug ID: 82707
   Summary: ICE in verify_gimple_in_cfg at tree-cfg.c:5395
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Since r253779 enabled a couple of additional libgomp testcases, one of them
causes an ICE everywere:

+FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/declare-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (internal compiler error)
+FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/declare-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  (test for excess errors)
+WARNING: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/declare-1.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1  -O2  compilation failed to produce
executable

output is:
/vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/declare-1.c:
In function 'int main(int, char**)':
/vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/declare-1.c:120:1:
error: incorrect sharing of tree nodes
map(delete:e)
#pragma omp target oacc_declare map(delete:e)
during GIMPLE pass: cfg
/vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.oacc-c++/../libgomp.oacc-c-c++-common/declare-1.c:120:1:
internal compiler error: verify_gimple failed
0x90d8070 verify_gimple_in_cfg(function*, bool)
/vol/gcc/src/hg/trunk/local/gcc/tree-cfg.c:5395
0x8fadfdf execute_function_todo
/vol/gcc/src/hg/trunk/local/gcc/passes.c:1994
0x8faecf2 do_per_function
/vol/gcc/src/hg/trunk/local/gcc/passes.c:1659
0x8faedf1 execute_todo
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2048

It still happens even after the fixes for PR tree-optimization/82672 went
in.

  Rainer

[Bug middle-end/78809] Inline strcmp with small constant strings

[wdijkstr at arm dot com]

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

--- Comment #18 from Wilco  ---
(In reply to Qing Zhao from comment #17)
> (In reply to Wilco from comment #16)
> 
> >> const char s[8] = “abcd\0abc”;  // null byte in the middle of the string
> >> int f2(void) { return __builtin_strcmp(s, "abc") != 0; }
> >> int f3(void) { return __builtin_strcmp(s, “abc”); }
> >> 
> >> can either of the above f2 or f3 been optimized to memcmp? seems not.
> > 
> > You never get that to the null byte as the memcmp only compares 
> > strlen("abc"+1)
> > characters.
> 
> Yes, this is correct for memcmp, but not for strcmp.  strcmp will get to the
> null byte. 
> as a result,  
> 
> const char s[8] = “abcd\0abc”;
> strcmp (s, “abc”) != 0.   // s = “abcd", which is != “abc"
> strncmp (s, “abc”, 3) == 0
> memcmp(s, “abc”, 3) == 0
> 
> So, strcmp cannot optimized to memcmp 

No that should be:

strcmp (s, “abc”) != 0
strncmp (s, “abc”, 4) != 0
memcmp(s, “abc”, 4) != 0

You need to compare the null terminator as well.

> > However do you mean an input string which is shorter than the
> > constant string? That's fine as this will compare not-equal in the memcmp.
> 
> for the input string is shorter than the constant string, for example: 
> 
> const char s[8] = “ab\0\0abcd”;
> strcmp (s, “abc”) != 0
> strncmp (s, “abc”, 3) != 0
> memcmp (s, “abc”,3) != 0
> 
> In a summary, since it’s NOT easy for the compiler to know where is the
> “Null_terminator” 
> in the string, strcmp is NOT reasonable to be optimized to memcmp whenever
> its result is 
> used to compare with zero or not.

The compiler knows where the null terminator is in the constant string so it
can easily figure out when it is legal as well as faster than doing a byte by
byte expansion of strcmp.

strcmp (s, STR) -> memcmp (s, strlen (STR) + 1) iff max(sizeof_array(s),
alignment(s)) > strlen (STR).

> But for strncmp, if the result is to compare with zero, it might be
> reasonable to optimized it
> to the corresponding memcmp, i.e
> 
> strncmp (s, “abc”, 3) != 0
> 
> could be optimized to
> 
> memcmp (s, “abc”, 3) != 0

If the strncmp size is smaller than the strlen of the constant string (and
alignment is right), yes. But strncmp (s, "abc", C) is equivalent to strcmp (s,
"abc") if C >= 4.

[Bug libstdc++/82706] 27_io/filesystem/operations/permissions.cc FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug libstdc++/82706] New: 27_io/filesystem/operations/permissions.cc FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 82706
   Summary: 27_io/filesystem/operations/permissions.cc FAILs
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

The new 27_io/filesystem/operations/permissions.cc test FAILs on Solaris 11:

FAIL: 27_io/filesystem/operations/permissions.cc execution test

both 32 and 64-bit, sparc and x86 (and FreeBSD according to gcc-testresults).

/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/27_io/filesystem/operations/permissions.cc:103:
void test03(): Assertion 'ec == ec2' failed.

After the first permissions() call, ec is changed from ENOENT to 0, which
happens
after the ::lstat call in fs::symlink_status has succeded.

  Rainer

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
So should combine use targetm.cc_modes_compatible here?

[Bug rtl-optimization/47253] Conditional jump to tail function is not generated

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||peter at cordes dot ca

--- Comment #5 from H.J. Lu  ---
*** Bug 69576 has been marked as a duplicate of this bug. ***

[Bug target/69576] tailcall could use a conditional branch on x86, but doesn't

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from H.J. Lu  ---
Dup.

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

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #17 from Qing Zhao  ---
(In reply to Wilco from comment #16)

>> const char s[8] = “abcd\0abc”;  // null byte in the middle of the string
>> int f2(void) { return __builtin_strcmp(s, "abc") != 0; }
>> int f3(void) { return __builtin_strcmp(s, “abc”); }
>> 
>> can either of the above f2 or f3 been optimized to memcmp? seems not.
> 
> You never get that to the null byte as the memcmp only compares 
> strlen("abc"+1)
> characters.

Yes, this is correct for memcmp, but not for strcmp.  strcmp will get to the
null byte. 
as a result,  

const char s[8] = “abcd\0abc”;
strcmp (s, “abc”) != 0.   // s = “abcd", which is != “abc"
strncmp (s, “abc”, 3) == 0
memcmp(s, “abc”, 3) == 0

So, strcmp cannot optimized to memcmp 

> However do you mean an input string which is shorter than the
> constant string? That's fine as this will compare not-equal in the memcmp.

for the input string is shorter than the constant string, for example: 

const char s[8] = “ab\0\0abcd”;
strcmp (s, “abc”) != 0
strncmp (s, “abc”, 3) != 0
memcmp (s, “abc”,3) != 0

In a summary, since it’s NOT easy for the compiler to know where is the
“Null_terminator” 
in the string, strcmp is NOT reasonable to be optimized to memcmp whenever its
result is 
used to compare with zero or not.

But for strncmp, if the result is to compare with zero, it might be reasonable
to optimized it
to the corresponding memcmp, i.e

strncmp (s, “abc”, 3) != 0

could be optimized to

memcmp (s, “abc”, 3) != 0

[Bug middle-end/82705] New: Missing tail calls for large structs

[jmuizelaar at mozilla dot com]

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

Bug ID: 82705
   Summary: Missing tail calls for large structs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmuizelaar at mozilla dot com
  Target Milestone: ---

The following code:

struct Foo {
   int o[16];
};

__attribute__((noinline))
Foo moo()
{
return {0};
}

Foo goo()
{
return moo();
}

with -O3 -fno-exceptions -fomit-frame-pointer compiles to:
moo():
  pxor xmm0, xmm0
  mov rax, rdi
  movups XMMWORD PTR [rdi], xmm0
  movups XMMWORD PTR [rdi+16], xmm0
  movups XMMWORD PTR [rdi+32], xmm0
  movups XMMWORD PTR [rdi+48], xmm0
  ret
goo():
  sub rsp, 8
  call moo()
  add rsp, 8
  mov rax, rdi
  ret

goo could just be:

goo():
  jmp moo

Also it seems like the "sub rsp, 8" and "add rsp, 8" are extraneous

[Bug c/58884] OPTIONAL warning when a temprary value is created and not used.

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury  changed:

   What|Removed |Added

  Component|tree-optimization   |c

--- Comment #1 from Max TenEyck Woodbury  ---
I found the relevant code in the "gimplify" modules.  I could submit patches
for this now but it adds messages that will need translation and I am not
certain on the way that should be handled.

It turns out the problem described gets fixed very early and never gets to the
optimizer, but could have an impact when certain c++ features are abused...

[Bug middle-end/78809] Inline strcmp with small constant strings

[wdijkstr at arm dot com]

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

--- Comment #16 from Wilco  ---
(In reply to Qing Zhao from comment #15)
> (In reply to Wilco from comment 14)
> > The only reason we have to do a character by character comparison is 
> > because we
> > cannot read beyond the end of a string. However when we know the size or
> > alignment we can safely process a string one word at a time.
> 
> is it possible that “NULL_terminator” is in the middle of the string even
> though we 
> know the size or alignment? for example:
> 
> const char s[8] = “abcd\0abc”;  // null byte in the middle of the string
> int f2(void) { return __builtin_strcmp(s, "abc") != 0; }
> int f3(void) { return __builtin_strcmp(s, “abc”); }
> 
> can either of the above f2 or f3 been optimized to memcmp? seems not.

You never get that to the null byte as the memcmp only compares strlen("abc"+1)
characters. However do you mean an input string which is shorter than the
constant string? That's fine as this will compare not-equal in the memcmp.

[Bug target/82460] AVX512: choose between vpermi2d and vpermt2d to save mov instructions. Also, fails to optimize away shifts before shuffle

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Tue Oct 24 19:35:37 2017
New Revision: 254059

URL: https://gcc.gnu.org/viewcvs?rev=254059=gcc=rev
Log:
PR target/82460
* config/i386/sse.md (UNSPEC_VPERMI2, UNSPEC_VPERMI2_MASK): Remove.
(VPERMI2, VPERMI2I): New mode iterators.
(_vpermi2var3_maskz): Remove 3 define_expand patterns.
(_vpermi2var3): Remove 3 define_insn
patterns.
(_vpermi2var3_mask): New define_expand using VPERMI2
mode iterator.  Remove 3 old define_insn patterns.
(*_vpermi2var3_mask): 2 new define_insn patterns.
(_vpermt2var3_maskz): Adjust 1 define_expand to use
VPERMI2 mode iterator, remove the other two expanders.
(_vpermt2var3): Adjust 1 define_insn
to use VPERMI2 mode iterator, add another alternative for vpermi2*
instructions, remove the other two patterns.
(_vpermt2var3_mask): Adjust 1 define_insn to use VPERMI2
mode iterator, remove the other two patterns.
* config/i386/i386.c (ix86_expand_vec_perm_vpermi2): Renamed to ...
(ix86_expand_vec_perm_vpermt2): ... this.  Swap mask and op0
arguments, use gen_*vpermt2* expanders instead of gen_*vpermi2*
and adjust argument order accordingly.
(ix86_expand_vec_perm): Adjust caller.
(expand_vec_perm_1): Likewise.
(expand_vec_perm_vpermi2_vpshub2): Rename to ...
(expand_vec_perm_vpermt2_vpshub2): ... this.
(ix86_expand_vec_perm_const_1): Adjust caller.
(ix86_vectorize_vec_perm_const_ok): Adjust comments.

* gcc.target/i386/pr82460-1.c: New test.
* gcc.target/i386/pr82460-2.c: New test.
* gcc.target/i386/avx512f-vpermt2pd-1.c: Adjust scan-assembler*
regexps to allow vpermt2* to vpermi2* replacement or vice versa
where possible.
* gcc.target/i386/avx512vl-vpermt2pd-1.c: Likewise.
* gcc.target/i386/avx512f-vpermt2d-1.c: Likewise.
* gcc.target/i386/vect-pack-trunc-2.c: Likewise.
* gcc.target/i386/avx512vl-vpermt2ps-1.c: Likewise.
* gcc.target/i386/avx512vl-vpermt2q-1.c: Likewise.
* gcc.target/i386/avx512f-vpermt2ps-1.c: Likewise.
* gcc.target/i386/avx512vl-vpermt2d-1.c: Likewise.
* gcc.target/i386/avx512bw-vpermt2w-1.c: Likewise.
* gcc.target/i386/avx512vbmi-vpermt2b-1.c: Likewise.
* gcc.target/i386/avx512f-vpermt2q-1.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82460-1.c
trunk/gcc/testsuite/gcc.target/i386/pr82460-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/avx512bw-vpermt2w-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vpermt2d-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vpermt2pd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vpermt2ps-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-vpermt2q-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vbmi-vpermt2b-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-vpermt2d-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-vpermt2pd-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-vpermt2ps-1.c
trunk/gcc/testsuite/gcc.target/i386/avx512vl-vpermt2q-1.c
trunk/gcc/testsuite/gcc.target/i386/vect-pack-trunc-2.c

[Bug target/82370] AVX512 can use a memory operand for immediate-count vpsrlw, but gcc doesn't.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Oct 24 19:34:06 2017
New Revision: 254058

URL: https://gcc.gnu.org/viewcvs?rev=254058=gcc=rev
Log:
PR target/82370
* config/i386/sse.md (VIMAX_AVX2): Remove V4TImode.
(VIMAX_AVX2_AVX512BW, VIMAX_AVX512VL): New mode iterators.
(vec_shl_): Remove unused expander.
(avx512bw_3): New define_insn.
(_ashl3, _lshr3): Replaced by ...
(_3): ... this.  New define_insn.

* gcc.target/i386/pr82370.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr82370.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #8)
> Maybe you can handle this in can_change_dest_mode?  That will catch
> the similar cases, too.

No, because we only have to prevent CCmode changes that apply to FP operands.
can_change_dest_mode only looks at mode changes, but CCFPmode and CCFPUmode are
x86 specific.

I have looked at other SELECT_CC_MODE changes, and they deal with propagation
of compares into arithmetic operations. This is the only place that can change
CCmode of FP compares.

[Bug preprocessor/58687] "#line __LINE__ ..." changes subsequent line numbers

[mtewoodbury at gmail dot com]

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

Max TenEyck Woodbury  changed:

   What|Removed |Added

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

--- Comment #27 from Max TenEyck Woodbury  ---
The existence of examples in older programming literature indicates that the
proposed interpretation where #line __LINE__ did not change subsequent line
numbers was considered useful.  I have found this very useful myself.

The conclusion that this is not a "BUG" is correct, but it it is a useful
feature and it would make GCC easier to use.  GCC specifies the unspecified in
many places and it could do so here.  It is actually fairly easy to implement
as the patch I submitted to patches-gcc shows.

[Bug c++/82466] Missing warning for re-declaration of built-in function as variable

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #8 from Paolo Carlini  ---
Done.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #15 from Qing Zhao  ---
(In reply to Wilco from comment 14)
> The only reason we have to do a character by character comparison is because 
> we
> cannot read beyond the end of a string. However when we know the size or
> alignment we can safely process a string one word at a time.

is it possible that “NULL_terminator” is in the middle of the string even
though we 
know the size or alignment? for example:

const char s[8] = “abcd\0abc”;  // null byte in the middle of the string
int f2(void) { return __builtin_strcmp(s, "abc") != 0; }
int f3(void) { return __builtin_strcmp(s, “abc”); }

can either of the above f2 or f3 been optimized to memcmp? seems not.

[Bug c++/82466] Missing warning for re-declaration of built-in function as variable

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Oct 24 19:01:03 2017
New Revision: 254057

URL: https://gcc.gnu.org/viewcvs?rev=254057=gcc=rev
Log:
2017-10-24  Paolo Carlini  

PR c++/82466
* doc/invoke.texi ([Wbuiltin-declaration-mismatch]): Extend
description.

/cp
2017-10-24  Paolo Carlini  

PR c++/82466
* decl.c (duplicate_decls): Warn for built-in functions declared as
non-function, use OPT_Wbuiltin_declaration_mismatch.

* decl.c (duplicate_decls): Avoid redundant '+' in warning_at.

/c
2017-10-24  Paolo Carlini  

PR c++/82466
* c-decl.c (diagnose_mismatched_decls): Use
OPT_Wbuiltin_declaration_mismatch.

/testsuite
2017-10-24  Paolo Carlini  

PR c++/82466
* c-c++-common/Wbuiltin-declaration-mismatch-1.c: New.
* c-c++-common/Wno-builtin-declaration-mismatch-1.c: Likewise.
* g++.dg/warn/Wbuiltin_declaration_mismatch-1.C: Likewise.
* g++.dg/parse/builtin2.C: Adjust.
* g++.old-deja/g++.mike/p811.C: Likewise.

Added:
trunk/gcc/testsuite/c-c++-common/Wbuiltin-declaration-mismatch-1.c
trunk/gcc/testsuite/c-c++-common/Wno-builtin-declaration-mismatch-1.c
trunk/gcc/testsuite/g++.dg/warn/Wbuiltin_declaration_mismatch-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/builtin2.C
trunk/gcc/testsuite/g++.old-deja/g++.mike/p811.C

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Maybe you can handle this in can_change_dest_mode?  That will catch
the similar cases, too.

[Bug other/82704] New: GCC fails to download prerequisites on busybox distro (unrecognized sha512sum --check)

[keno at juliacomputing dot com]

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

Bug ID: 82704
   Summary: GCC fails to download prerequisites on busybox distro
(unrecognized sha512sum --check)
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keno at juliacomputing dot com
  Target Milestone: ---

The contrib/download_prerequisites script uses `sha512sum --check` to verify
the integrity
of the downloaded prerequisites. This is an alias for `-c` in coreutils, but
busybox does not recognize this alias, leading to the below failure (on an
Alpine Linux
based system). The solution is simply to replace `--check`, by `-c` which
should work on both coreutils and busybox. I have verified that with that
change, everything else goes through as usual.

```
Connecting to gcc.gnu.org (209.132.180.131:21)
gmp-6.1.0.tar.bz2  0% |   | 12132   0:03:15 ETA
gmp-6.1.0.tar.bz2 23% |***|   544k  0:00:06 ETA
gmp-6.1.0.tar.bz2 77% |***|  1795k  0:00:00 ETA
gmp-6.1.0.tar.bz2100% |***|  2327k  0:00:00 ETA

Connecting to gcc.gnu.org (209.132.180.131:21)
mpfr-3.1.4.tar.bz2 6% |*  | 82228   0:00:14 ETA
mpfr-3.1.4.tar.bz255% |*  |   693k  0:00:01 ETA
mpfr-3.1.4.tar.bz2   100% |***|  1249k  0:00:00 ETA

Connecting to gcc.gnu.org (209.132.180.131:21)
mpc-1.0.3.tar.gz  26% |   |   172k  0:00:02 ETA
mpc-1.0.3.tar.gz 100% |***|   654k  0:00:00 ETA

Connecting to gcc.gnu.org (209.132.180.131:21)
isl-0.16.1.tar.bz2 4% |*  | 70096   0:00:22 ETA
isl-0.16.1.tar.bz235% |** |   559k  0:00:03 ETA
isl-0.16.1.tar.bz295% |*  |  1517k  0:00:00 ETA
isl-0.16.1.tar.bz2   100% |***|  1588k  0:00:00 ETA

sha512sum: unrecognized option: check
BusyBox v1.26.2 (2017-06-11 06:38:32 GMT) multi-call binary.

Usage: sha512sum [-c[sw]] [FILE]...

Print or check SHA512 checksums

-c  Check sums against list in FILEs
-s  Don't output anything, status code shows success
-w  Warn about improperly formatted checksum lines
error: Cannot verify integrity of possibly corrupted file gmp-6.1.0.tar.bz2
```

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
To illustrate the problem, following patch fixes the failure:

--cut here--
Index: combine.c
===
--- combine.c   (revision 254011)
+++ combine.c   (working copy)
@@ -6784,7 +6784,7 @@ simplify_set (rtx x)
   && op0 == XEXP (inner_compare, 0)
   && op1 == XEXP (inner_compare, 1))
compare_mode = GET_MODE (inner_compare);
-  else
+  else if (!FLOAT_MODE_P (GET_MODE (op0)))
compare_mode = SELECT_CC_MODE (new_code, op0, op1);

   /* If the mode changed, we have to change SET_DEST, the mode in the
--cut here--

The patch avoids mode changes for floating-point operands.

(It will work for x86, since it has all comparisons trapping and non-trapping).

[Bug libstdc++/82685] basic_string_view operator""sv(const char*, size_t) should be noexcept

[pavel.kryukov at phystech dot edu]

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

--- Comment #9 from Pavel I. Kryukov  ---
Ok, no problem.

> N.B. the compiler already gives the right answer when asked:
>
> #include 
> using namespace std::literals::string_view_literals;
> static_assert(noexcept(""sv"));

JFYI, Clang gives a wrong answer to that
(https://bugs.llvm.org/show_bug.cgi?id=15481).

[Bug tree-optimization/82700] ICE in printf-return-value with -fexec-charset=EBCDIC-US: converting to execution character set: Invalid or incomplete multibyte or wide character

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
(In reply to Martin Sebor from comment #1)
> The ICE is caused by the EBCDIC-US character set in Fedora 25 apparently not
> including the equivalent of the backslash character.

Actually, I was off by one: the character the conversion fails for is '[' (the
error is EILSEQ, Illegal byte sequence).

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

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

--- Comment #6 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #5)
> The combination 8 -> 9 (where the GE is introduced) does not call
> SELECT_CC_MODE at all.

The problematic conversion is 7 -> 9, *after* 8 -> 9 is performed.

Please see this gdb session:

(gdb) b ix86_cc_mode

Breakpoint 1, ix86_cc_mode (code=GE, op0=0x7fffeff09ab0, op1=0x7fffeff09960) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:21718
21718   {
(gdb) bt
#0  ix86_cc_mode (code=GE, op0=0x7fffeff09ab0, op1=0x7fffeff09960) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:21718
#1  0x012eb45d in simplify_set (x=x@entry=0x7fffeff09c60) at
/home/uros/gcc-svn/trunk/gcc/combine.c:6788
#2  0x012ecb48 in combine_simplify_rtx(rtx_def*, machine_mode, int,
int) () at /home/uros/gcc-svn/trunk/gcc/combine.c:6293
#3  0x012eee32 in subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) ()
at /home/uros/gcc-svn/trunk/gcc/combine.c:5573
#4  0x012f1e42 in try_combine(rtx_insn*, rtx_insn*, rtx_insn*,
rtx_insn*, int*, rtx_insn*) () at /home/uros/gcc-svn/trunk/gcc/combine.c:3332
#5  0x012f7d91 in combine_instructions (nregs=,
f=) at /home/uros/gcc-svn/trunk/gcc/combine.c:1301

(gdb) f4
#4  0x012f1e42 in try_combine(rtx_insn*, rtx_insn*, rtx_insn*,
rtx_insn*, int*, rtx_insn*) () at /home/uros/gcc-svn/trunk/gcc/combine.c:3332
3332  newpat = subst (PATTERN (i3), i2dest, i2src, 0, 0,

(gdb) p debug_rtx (i3)
(insn 9 8 10 2 (set (reg:CCFPU 17 flags)
(compare:CCFPU (reg:DF 95)
(reg/v:DF 91 [ x ]))) "pr82692.c":9 2147483647 {NOOP_MOVE}
 (nil))

(gdb) b combine.c:
Breakpoint 2 at 0x12f1dfb: file /home/uros/gcc-svn/trunk/gcc/combine.c, line
.

(gdb) c
Continuing.

Breakpoint 2, try_combine(rtx_insn*, rtx_insn*, rtx_insn*, rtx_insn*, int*,
rtx_insn*) () at /home/uros/gcc-svn/trunk/gcc/combine.c:3334
3334  || ((i0_feeds_i2_n || (i0_feeds_i1_n &&
i1_feeds_i2_n))

(gdb) p debug_rtx (newpat)
(set (reg:CCFP 17 flags)
(compare:CCFP (reg:DF 95)
(reg/v:DF 91 [ x ])))

And also changes mode of the conditional jump.

[Bug tree-optimization/82700] ICE in printf-return-value with -fexec-charset=EBCDIC-US: converting to execution character set: Invalid or incomplete multibyte or wide character

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The ICE is caused by the EBCDIC-US character set in Fedora 25 apparently not
including the equivalent of the backslash character.  That makes the charset
invalid, since C requires both the basic source and basic character sets to
include it.  From the comment in the file:

  /* The subset of the source character set used by printf conversion
 specifications (strictly speaking, not all letters are used but
 they are included here for the sake of simplicity).  The dollar
 sign must be included even though it's not in the basic source
 character set.  */
  const char srcset[] = " 0123456789!\"#%&'()*+,-./:;<=>?[\\]^_{|}~$"
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

The sprintf pass calls lang_hooks.to_target_charset () to convert each of these
characters from the source set to the execution set and the function aborts
when it can't do the conversion.  That seems unfriendly -- it should instead
return some failure code and let the caller decide how to deal with it.

[Bug middle-end/82062] [8 regression] simple conditional expressions no longer folded

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  ---
> Looks like you have sth in mind, care to post a candidate patch?

The candidate patch would just be Marek's initial fix in comment #8:

--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -3401,14 +3401,14 @@ operand_equal_for_comparison_p (tree arg0, tree arg1,
tree other)

   primarg1 = get_narrower (arg1, );
   primother = get_narrower (other, );
+  tree type = TREE_TYPE (arg0);

   correct_width = TYPE_PRECISION (TREE_TYPE (arg1));
   if (unsignedp1 == unsignedpo
+  && TYPE_PRECISION (TREE_TYPE (primarg1)) == TYPE_PRECISION (type)
   && TYPE_PRECISION (TREE_TYPE (primarg1)) < correct_width
   && TYPE_PRECISION (TREE_TYPE (primother)) < correct_width)
 {
-  tree type = TREE_TYPE (arg0);
-
   /* Make sure shorter operand is extended the right way
 to match the longer operand.  */
   primarg1 = fold_convert (signed_or_unsigned_type_for

[Bug fortran/82622] [PDT] ICE in structure_alloc_comps, at fortran/trans-array.c:8963

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> This one is an interesting case ...
> (... and the last PR derived from this search)
> 
> 
> $ cat z1.f90
> program p
>type t(a)
>   integer, len :: a
>end type
>type t2(b)
>   integer, len :: b
>   type(t(1)) :: r(b)
>end type
>type(t2(:)), allocatable :: x
>allocate (t2(3) :: x)
> end

BTW, I don't know the semantics of PDT's.  Is this
valid code and should compile.  Is so, this patch
"fixes" the problem.

%--- cut here ---

Index: trans-array.c
===
--- trans-array.c   (revision 254051)
+++ trans-array.c   (working copy)
@@ -8960,7 +8960,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree dec
  gfc_actual_arglist *param = pdt_param_list;
  gfc_init_se (, NULL);
  for (; param; param = param->next)
-   if (!strcmp (c->name, param->name))
+   if (!param->name || !strcmp (c->name, param->name))
  c_expr = param->expr;

  if (!c_expr)

%--- cut here ---

(gdb) b trans-array.c:8963
Breakpoint 1 at 0x76f388: file ../../gcc/gcc/fortran/trans-array.c, line 8963.
(gdb) run a.f90
Starting program:
/mnt/sgk/work/libexec/gcc/x86_64-unknown-freebsd12.0/8.0.0/f951 a.f90
 p
Breakpoint 1, structure_alloc_comps (der_type=, 
decl=, dest=, dest@entry=0x0, rank=0, 
purpose=purpose@entry=6, caf_mode=caf_mode@entry=0)
at ../../gcc/gcc/fortran/trans-array.c:8963
8963if (!param->name || !strcmp (c->name, param->name))
(gdb) p c->name
$1 = 0x203c2d068 "b"
(gdb) p param->name
$2 = 0x203c2d068 "b"
(gdb) c
Continuing.

Breakpoint 1, structure_alloc_comps (der_type=der_type@entry=0x201da2f00, 
decl=, decl@entry=0x203a95428, dest=, 
dest@entry=0x0, rank=rank@entry=1, purpose=purpose@entry=6, 
caf_mode=caf_mode@entry=0) at ../../gcc/gcc/fortran/trans-array.c:8963
8963if (!param->name || !strcmp (c->name, param->name))
(gdb) p c->name
$3 = 0x203c2d040 "a"
(gdb) p param->name
$4 = 0x0

Paul, should param->name = NULL be caught somewhere in resolve.c?

[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

[wilco at gcc dot gnu.org]

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

--- Comment #14 from Wilco  ---
Author: wilco
Date: Tue Oct 24 17:21:19 2017
New Revision: 254056

URL: https://gcc.gnu.org/viewcvs?rev=254056=gcc=rev
Log:
Cleanup autopref scheduling

r253236 broke AArch64 bootstrap. Earlier revision r253071 changed scheduling
behaviour on AArch64 as autopref scheduling no longer checks the base.

This patch fixes the bootstrap failure and cleans up autopref scheduling.
The code is greatly simplified.  Sort accesses on the offset first, and
only if the offsets are the same fall back to other comparisons in
rank_for_schedule.  This doesn't at all restore the original behaviour
since we no longer compare the base address, but it now defines a total
sorting order.  More work will be required to improve the sorting so
that only loads/stores with the same base are affected.

gcc/
PR rtl-optimization/82396
* gcc/haifa-sched.c (ready_sort_real): Remove qsort workaround.
(autopref_multipass_init): Simplify initialization.
(autopref_rank_data): Simplify sort order.
* gcc/sched-int.h (autopref_multipass_data_): Remove
multi_mem_insn_p, min_offset and max_offset.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/sched-int.h

[Bug middle-end/69976] Zero the local stack on function exit

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm  ---
Did this patch ever get posted to gcc-patc...@gcc.gnu.org?  That's probably the
best way to get some traction on this.  Note that feature-freeze for GCC 8 is
coming in the next few weeks, AIUI.

[Bug fortran/82622] [PDT] ICE in structure_alloc_comps, at fortran/trans-array.c:8963

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #0)
> This one is an interesting case ...
> (... and the last PR derived from this search)
> 
> 
> $ cat z1.f90
> program p
>type t(a)
>   integer, len :: a
>end type
>type t2(b)
>   integer, len :: b
>   type(t(1)) :: r(b)
>end type
>type(t2(:)), allocatable :: x
>allocate (t2(3) :: x)
> end
> 
> 
> $ gfortran-8-20171015 -c z1.f90
> z1.f90:10:0:
> 
> allocate (t2(3) :: x)
> 
> internal compiler error: Segmentation fault
> 0xb5a08f crash_signal
> ../../gcc/toplev.c:326
> 0x73cc83 structure_alloc_comps
> ../../gcc/fortran/trans-array.c:8963
> 0x73ba67 structure_alloc_comps
> ../../gcc/fortran/trans-array.c:8371
> 0x73df30 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
> gfc_actual_arglist*)
> ../../gcc/fortran/trans-array.c:9301
> 0x73c083 structure_alloc_comps
> ../../gcc/fortran/trans-array.c:9099
> 0x73df30 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
> gfc_actual_arglist*)
> ../../gcc/fortran/trans-array.c:9301
> 0x79b84a gfc_trans_allocate(gfc_code*)
> ../../gcc/fortran/trans-stmt.c:6407
> 0x72d2f7 trans_code
> ../../gcc/fortran/trans.c:1976
> 0x753f6c gfc_generate_function_code(gfc_namespace*)
> ../../gcc/fortran/trans-decl.c:6420
> 0x6e6580 translate_all_program_units
> ../../gcc/fortran/parse.c:6088
> 0x6e6580 gfc_parse_file()
> ../../gcc/fortran/parse.c:6291
> 0x72a6bf gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:204

My backtrace for this code starts with

(gdb) bt
#0  strcmp () at /usr/src/lib/libc/amd64/string/strcmp.S:48
#1  0x0078ec53 in structure_alloc_comps(gfc_symbol*, tree_node*,
tree_node*, int, int, int) () at ../../gcc/gcc/fortran/trans-array.c:8963
#2  0x0078ea3a in structure_alloc_comps(gfc_symbol*, tree_node*,
tree_node*, int, int, int) () at ../../gcc/gcc/fortran/trans-array.c:8371
#3  0x00790481 in gfc_allocate_pdt_comp (der_type=, 
decl=, rank=, param_list=)
at ../../gcc/gcc/fortran/trans-array.c:9300
#4  0x0078e602 in structure_alloc_comps(gfc_symbol*, tree_node*,
tree_no

which suggested that there is an invalid pointer to some string.

[Bug middle-end/60580] aarch64 generates wrong code for __attribute__ ((optimize("no-omit-frame-pointer")))

[wilco at gcc dot gnu.org]

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

--- Comment #9 from Wilco  ---
Author: wilco
Date: Tue Oct 24 16:58:02 2017
New Revision: 254052

URL: https://gcc.gnu.org/viewcvs?rev=254052=gcc=rev
Log:
PR60580: Fix frame pointer option magic

To fix PR60580 simplify the logic in aarch64_override_options_after_change_1
(). 
If the frame pointer is enabled, set it to a special value that behaves similar
to frame pointer omission.  If we don't do this all leaf functions will get a
frame pointer even if flag_omit_leaf_frame_pointer is set.

If flag_omit_frame_pointer has this special value, we must force the frame
pointer if not in a leaf function.  We also need to force it in a leaf function
if flag_omit_frame_pointer is not set or if LR is used.

Doing this allows both -fomit-frame-pointer and -fomit-leaf-frame-pointer to be
independently set and changed in each function with the expected behaviour.

gcc/
PR middle-end/60580
* config/aarch64/aarch64.c (aarch64_frame_pointer_required)
Check special value of flag_omit_frame_pointer.
(aarch64_can_eliminate): Likewise.
(aarch64_override_options_after_change_1): Simplify handling of
-fomit-frame-pointer and -fomit-leaf-frame-pointer.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c

[Bug middle-end/78809] Inline strcmp with small constant strings

[wilco at gcc dot gnu.org]

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

--- Comment #14 from Wilco  ---
(In reply to Qing Zhao from comment #11)
> (In reply to Wilco from comment #9)
> 
> > str(n)cmp with a constant string can be changed into memcmp if the string 
> > has a
> > known alignment or is an array of known size. We should check the common 
> > cases
> > are implemented.
> 
> Please provide an example in which a str(n)cmp with a constant string can be
> changed into
> memcmp. 
> 
> (From my understanding, for the strcmp (p, “fish”),  since we don’t know
> what will be in the string
> pointed by “p”, and there might be NULL_terminator in any of the place of p,
> we have to compare
> each char in “p” one by one, do I miss anything here?)

The only reason we have to do a character by character comparison is because we
cannot read beyond the end of a string. However when we know the size or
alignment we can safely process a string one word at a time.

I would expect all these to optimize into memcmp - but none do:

#include 

char s[100];
typedef struct { int x; char s[8]; } S;

int f1(S *s) { return __builtin_strcmp(s->s, "abc") != 0; }
int f2(void) { return __builtin_strcmp(s, "abc") != 0; }
int f3(char *s) { s = __builtin_assume_aligned (s, 8); return
__builtin_strcmp(s, "abc") != 0; }
int f4(void) { char *s = (char*)malloc(100); return __builtin_strcmp(s, "abc")
!= 0; }

[Bug tree-optimization/82703] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[frederic.bron at m4x dot org]

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

--- Comment #2 from Frédéric Bron  ---
Created attachment 42465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42465=edit
save-temps for g++ 7.2.0

[Bug tree-optimization/82703] Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[frederic.bron at m4x dot org]

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

--- Comment #1 from Frédéric Bron  ---
Created attachment 42464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42464=edit
save-temps for g++ 7.2.1

[Bug tree-optimization/82703] New: Wrong addition of std::array components with -O2 -ftree-loop-vectorize -ftree-slp-vectorize (works fine with -O2)

[frederic.bron at m4x dot org]

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

Bug ID: 82703
   Summary: Wrong addition of std::array components with -O2
-ftree-loop-vectorize -ftree-slp-vectorize (works fine
with -O2)
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederic.bron at m4x dot org
  Target Milestone: ---

Created attachment 42463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42463=edit
Minimal example to reproduce the bug

The small program attached to this message should always pass, i.e. not print
any error. This is the case with -O2. This is also the case with clang++ 4.0.1
with -O3.

However with g++ and "-O2 -ftree-loop-vectorize -ftree-slp-vectorize", v3[1] is
2.0 instead of 4.0.

Note that if I change double to int, long, long long, float or long double, I
have no error.
Also if I do not construct Array from int[3] but from double[3], it works and
if I remove a useless line, it works...

Tested on linux Fedora 26 x86_64 with g++ 7.2.0 and 7.2.1 on westmere,
broadwell, skylake.

To reproduce failure:
g++ -O2 -g -std=c++14 bug.cpp -ftree-loop-vectorize -ftree-slp-vectorize &&
./a.out

g++ 7.2.0 that shows the bug:
Using built-in specs.
COLLECT_GCC=g++-7.2.0
COLLECT_LTO_WRAPPER=/softs/gcc-7.2.0/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /softs/build/gcc-7.2.0/configure --prefix=/softs/gcc-7.2.0
--program-suffix=-7.2.0 --with-gmp-include=/softs/gmp-6.1.2/include
--with-gmp-lib=/softs/gmp-6.1.2/lib
--with-mpfr-include=/softs/mpfr-3.1.5/include
--with-mpfr-lib=/softs/mpfr-3.1.5/lib
--with-mpc-include=/softs/mpc-1.0.3/include --with-mpc-lib=/softs/mpc-1.0.3/lib
--with-isl-include=/softs/isl-0.16.1/include
--with-isl-lib=/softs/isl-0.16.1/lib --disable-isl-version-check --enable-lto
--enable-nls --disable-multilib
Thread model: posix
gcc version 7.2.0 (GCC) 


g++ 7.2.1 that shows the bug:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-libmpx
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)

[Bug c++/80991] ICE with __is_trivially_constructible in template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #4 from Paolo Carlini  ---
Fixed.

[Bug c++/80991] ICE with __is_trivially_constructible in template

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Oct 24 16:41:05 2017
New Revision: 254051

URL: https://gcc.gnu.org/viewcvs?rev=254051=gcc=rev
Log:
/cp
2017-10-24  Paolo Carlini  

PR c++/80991
* pt.c (value_dependent_expression_p, [TRAIT_EXPR]): Handle
a TREE_LIST as TRAIT_EXPR_TYPE2.

/testsuite
2017-10-24  Paolo Carlini  

PR c++/80991
* g++.dg/ext/is_trivially_constructible5.C: New.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug gcov-profile/82614] GCOV crashes while parsing gcda file

[mcastelluccio at mozilla dot com]

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

--- Comment #8 from Marco Castelluccio  ---
Created attachment 42462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42462=edit
Archive with GCNO and GCDA file generated with GCC 6

This is an archive containing the GCNO and GCDA files generated with GCC 6.

We are going to test 7 next.

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
The combination 8 -> 9 (where the GE is introduced) does not call
SELECT_CC_MODE at all.

[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings

[mark at gcc dot gnu.org]

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

--- Comment #7 from Mark Wielaard  ---
The workaround is to use gcc -C --save-temps ... to pass-through all comments
to the temp files. Maybe -C should be the default with --save-temps?

[Bug inline-asm/82701] RFE: x86: double word operands in inline assembly

[hpa at zytor dot com]

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

--- Comment #2 from H. Peter Anvin  ---
(continued)

: "+rm,r" (aa.l[0]), "+rm,r" (aa.l[1])
: "ri,m" (bb.l[0]), "ri,m" (bb.l));

a = aa.q;
b = bb.q;

If this is something that works by intent and not by accident I'm perfectly
happy with this solution as it appears to generate good code.

[Bug gcov-profile/82702] New: gcov intermediate format is creating multiple 'gcov' files, it was creating a single file up to GCC 6

[mcastelluccio at mozilla dot com]

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

Bug ID: 82702
   Summary: gcov intermediate format is creating multiple 'gcov'
files, it was creating a single file up to GCC 6
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mcastelluccio at mozilla dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Running "gcov -i file.gcno" was generating a single file ("file.gcno.gcov")
with info about all the files included in file.cpp.
Now, it is creating multiple "gcov" files, one for each included file.

[Bug inline-asm/82701] RFE: x86: double word operands in inline assembly

[hpa at zytor dot com]

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

--- Comment #1 from H. Peter Anvin  ---
I just stumbled onto this technique somewhat by accident:

union dw {
uint64_t q;
uint32_t l[2];
};

union dw aa, bb;

aa.q = a;
bb.q = b;

asm("add %2,%0; adc %3,%1"

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #13 from Qing Zhao  ---
(In reply to Richard Earnshaw from comment 12)
> That's not entirely correct.  Notionally memcmp needs to return a value
> representing the relative difference of the first different byte in the
> compared areas of memory; any later bytes are irrelevant.  Yes the compiler 
> can
> compare multiple bytes at the same time and it does not have to worry about
> page faulting, but it does have to keep track of where the first difference
> occurs.
> 
> Of course, the compiler can see how the result is used to optimize things
> further; a simple equality test will allow the compiler to generate a simpler
> sequence that could access all bytes and accumulate the overall result.

Yes.  this should be the reason why currently in GCC, only when the result of 
memcpy is compared to zero, it is optimized by “strlen” pass and “expand” pass.

[Bug preprocessor/78497] compiling with -save-temps adds -Wimplicit-fallthrough warnings

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #6 from Mark Wielaard  ---
Confirmed, this confused me a bit.

Take t.c:

int main (int argc, char **argv)
{
  int a;
  switch (argc)
{
case 1:
  a = 1;
  break;
case 2:
  a = 2;
  /* FALLTHROUGH */
case 3:
  a = 3;
  break;
}

  return a;
}

$ gcc -Werror -Wimplicit-fallthrough t.c

is fine, but...

$ gcc --save-temps -Werror -Wimplicit-fallthrough t.c
t.c: In function ‘main’:
t.c:10:9: error: this statement may fall through
[-Werror=implicit-fallthrough=]
   a = 2;
   ~~^~~
t.c:12:5: note: here
 case 3:
 ^~~~
cc1: all warnings being treated as errors

[Bug target/82699] ENDBR isn't generated at function entrance

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-10-24
   Target Milestone|--- |8.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01725.html

[Bug inline-asm/82701] New: RFE: x86: double word operands in inline assembly

[hpa at zytor dot com]

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

Bug ID: 82701
   Summary: RFE: x86: double word operands in inline assembly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hpa at zytor dot com
  Target Milestone: ---

x86 inline assembly currently has no sensible way to use doubleword operands
(long long on x86-32, __int128 on x86-64) without restricting them to the d:a
register pair via the "A" constraint, and hard-coding the register names.  It
would be highly desirable to have a clean way to emit into the assembly code
the upper half of a doublewidth operand (register or memory) without
artificially constraining code generation.

In some ways, this is similar to the "H" modifier, except it would be +4 for
memory operands on 32 bits.  I'm calling it U below.

For an artificial example:

uint64_t a, b;

/* a += b; */
asm("add %1,%0; adc %U1,%U0" : "+rm,r" (a) : "ri,m" (b) : "cc");

For a register: print the high register of the pair.
For a memory operand: print the address + the word size
For an immediate: print the value >> (word size*8)

[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations

[infinity0 at pwned dot gg]

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

--- Comment #9 from infinity0 at pwned dot gg ---
(In reply to rguent...@suse.de from comment #7)
> [..]
> 
> You still have to mark stmts with side-effects as volatile.
> 
> Conditional side-effects are tricky to get correct of course.

I think with the current asm() syntax and semantics, the only way to get this
correct in the C source code, is by using __volatile__. It is not possible to
even *express* "conditional side-effects" using the current syntax. To
demonstrate:

The "explicit zero check" that I mentioned in the first post does not actually
work, see the newer udiv.c test that I just attached. I think that is correct
behaviour from GCC as well.

AIUI, asm() without volatile, says to GCC: "this code will *never* cause side
effects under *any circumstance*, it depends only on its declared
inputs/outputs/clobbers". Under this assumption, it is correct to optimise

|   if(d) { asm(d); ... } ...

into

|   asm(d); if(d) { ... }

as long as the outputs to asm(d) don't clobber the inputs to if(d) or any
else-branches - I assume other parts of the optimiser will already check that.

However, it is *not* correct to perform the above, when the asm(d) has
conditional side-effects depending on d, that the if(d) checks for. But there
is no way to express this conditional-side-effect using the current asm()
syntax. So GCC will happily go ahead and perform the optimisation, since it
believes asm(d) will never have any side effects.

So, the pre-optimised code "looks correct", it's explicitly checking d, but
will in fact cause the types of unintended optimisations that we're looking at
here. The only way to avoid this is to use "volatile".

In conclusion: whilst making the optimiser more strict for this case as you
suggested, would fix this specific instance, I believe that it is not "the
proper fix" for GCC. A proper fix would have to involve changing the
*semantics* of a asm(div) call so that GCC understands that it has "side
effects depending on the divisor and n1[1]". Otherwise, more sophisticated
optimisations added to GCC in the future might make this issue come back.

If that is not done, then it would be necessary to fix these 20 projects's C
source code to properly express __volatile__. Actually this is probably
necessary regardless of any GCC fixes - from some quick searches it seems that
asm() semantics is not standardised, and also these projects might want to
support older GCC that has the existing semantics.

[1] it can also raise DE when n1 >= divisor.

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #3)
> --enable-objc-gc requires you to provide boehm-gc yourself now.  Quoting the
> installation instructions:
> 
> @item --enable-objc-gc
> Specify that an additional variant of the GNU Objective-C runtime library
> is built, using an external build of the Boehm-Demers-Weiser garbage
> collector (@uref{http://www.hboehm.info/gc/}).  This library needs to be
> available for each multilib variant,
^

Did you do that?

[Bug tree-optimization/57359] wrong code for union access at -O3 on x86_64-linux

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #12 from Alexander Cherepanov  ---
Still reproducible if the number of iterations is changed to 3.

I've also converted the testcase to allocated memory:

--
#include 
#include 

__attribute__((__noinline__,__noclone__))
void test(int *pi, long *pl, int k, int *pa)
{
  for (int i = 0; i < 3; i++) {
pl[k] = // something that doesn't change but have to be calculated
*pa; // something that potentially can be changed by assignment to *pi
*pi = 0;
  }
}

int main(void)
{
  int *pi = malloc(10);
  int a = 1;

  test(pi, (void *)pi, 0, );

  printf("%d\n", *pi);
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
0
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
1
--

gcc version: gcc (GCC) 8.0.0 20171024 (experimental)

[Bug middle-end/82569] [8 regression] failure in 177.mesa cpu2000 test case after r253530

[seurer at gcc dot gnu.org]

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

--- Comment #14 from seurer at gcc dot gnu.org ---
I tried the original full 177.mesa benchmark and it works fine after your
patch.  Thanks!

[Bug rtl-optimization/82677] Many projects (linux, coreutils, GMP, gcrypt, openSSL, etc) are misusing asm(divq/divl) etc, potentially resulting in faulty/unintended optimisations

[infinity0 at pwned dot gg]

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

infinity0 at pwned dot gg changed:

   What|Removed |Added

  Attachment #42439|0   |1
is obsolete||
  Attachment #42440|0   |1
is obsolete||

--- Comment #8 from infinity0 at pwned dot gg ---
Created attachment 42461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42461=edit
More specific and thorough test case

[Bug ipa/82698] Spurious warning __builtin_memset at O3

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Sebor  ---
I believe this is a dupe of bug 80641.  The invalid memset is introduced by the
loop distribution pass.  I would expect it to be possible to detect these cases
and either avoid inserting such invalid calls or replace them with
__builtin_unreachable.  That should not only eliminate these false positives
but also improve the quality of the generated code.

foo (struct vector & bar)
{
  int * __first;
  long unsigned int _1;
  int * _5;
  int * _6;
  long int _7;
  long int _8;
  long int _9;
  long int _10;
  long unsigned int _11;
  long unsigned int _20;
  int * _21;
  long int __pos.12_22;
  int * _23;
  long int _24;
  long int _27;

   [100.00%] [count: INV]:
  _5 = MEM[(int * *)bar_3(D)];
  _6 = MEM[(int * *)bar_3(D) + 8B];
  _7 = (long int) _6;
  _8 = (long int) _5;
  _9 = _7 - _8;
  _10 = _9 /[ex] 4;
  _11 = (long unsigned int) _10;
  _1 = _11 + 18446744073709551615;
  if (_1 > _11)
goto ; [33.00%]
  else
goto ; [67.00%]

   [16.50%] [count: INV]:
  _23 = bar_3(D)->D.15765._M_impl._M_end_of_storage;
  _24 = (long int) _23;
  _27 = _24 - _7;
  if (_27 == -4)
goto ; [67.00%]
  else
goto ; [33.00%]

   [11.06%] [count: INV]:
  __builtin_memset (_6, 0, 18446744073709551612);
  __first_28 = _6 + 18446744073709551612;
  bar_3(D)->D.15765._M_impl._M_finish = __first_28;
  goto ; [100.00%]

   [5.45%] [count: INV]:
  std::__throw_length_error ("vector::_M_default_append");

   [33.50%] [count: INV]:
  _20 = _1 * 4;
  _21 = _5 + _20;
  __pos.12_22 = (long int) _21;
  if (_7 != __pos.12_22)
goto ; [66.00%]
  else
goto ; [34.00%]

   [22.11%] [count: INV]:
  MEM[(int * *)bar_3(D) + 8B] = _21;

   [100.00%] [count: INV]:
  return;

}

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

[Bug tree-optimization/80641] [7/8 Regression] Warning with std::vector resize in loop

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||paulg at chiark dot 
greenend.org.u
   ||k

--- Comment #4 from Martin Sebor  ---
*** Bug 82698 has been marked as a duplicate of this bug. ***

[Bug middle-end/78809] Inline strcmp with small constant strings

[rearnsha at gcc dot gnu.org]

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

--- Comment #12 from Richard Earnshaw  ---
(In reply to Qing Zhao from comment #7)
> on the other hand, memcmp will NOT early stop, it will compare exactly N
> bytes of both buffers. As a result, the compiler can compare multiple bytes
> at one time.  
> 

That's not entirely correct.  Notionally memcmp needs to return a value
representing the relative difference of the first different byte in the
compared areas of memory; any later bytes are irrelevant.  Yes the compiler can
compare multiple bytes at the same time and it does not have to worry about
page faulting, but it does have to keep track of where the first difference
occurs.

Of course, the compiler can see how the result is used to optimize things
further; a simple equality test will allow the compiler to generate a simpler
sequence that could access all bytes and accumulate the overall result.

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[yyc1992 at gmail dot com]

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

--- Comment #3 from Yichao Yu  ---
> ARMv8-a is the only architecture variant where the CRC extension is optional

Not really. There's also armv8-r and armv8-m. Also, I believe code compiled for
armv7-a can run on armv8-a hardware and can also optionally enable armv8
features including CRC extension. I was hoping that GCC can be smart enough to
enable the correct armv8 variant automatically.

Test case is just

```
#include 

#pragma GCC push_options
#pragma GCC target("armv8-a+crc")
__attribute__((target("armv8-a+crc"))) uint32_t crc32cw(uint32_t crc, uint32_t
val)
{
uint32_t res;
/* asm(".arch armv8-a"); */
/* asm(".arch_extension crc"); */
asm("crc32cw %0, %1, %2" : "=r"(res) : "r"(crc), "r"(val));
/* asm(".arch armv7-a"); */
return res;
}
#pragma GCC pop_options
```

Compiled with either armv7-a or armv8-a march.

[Bug web/82686] Debian sid powerpc64-unknown-linux-gnu 4.13.0-1-powerpc64 bootstrap breaks in stage3 with unexpected requirement for bdw-gc

[dclarke at blastwave dot org]

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

--- Comment #4 from Dennis Clarke  ---
So this is not at all clear about how to continue. I did install the
new requirement or at least the "undocumented" dependency from the 
Debian pkg tree :

nix:~# apt-get install libgc-dev
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  libgc1c2
The following NEW packages will be installed:
  libgc-dev libgc1c2
0 upgraded, 2 newly installed, 0 to remove and 14 not upgraded.
Need to get 569 kB of archives.
After this operation, 1,553 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
.
.
.


However the bootstrap still fails in the stage3 phase : 

.
.
.
checking whether the target supports thread-local storage... yes
checking if the type of bitfields matters... yes
checking for bdw garbage collector... checking for system boehm-gc...
configure: error: system bdw-gc required but not found
gmake[1]: *** [Makefile:22695: configure-target-libobjc] Error 1
gmake[1]: Leaving directory
'/usr/local/build/gcc-7.2.0_linux_4.13.0-1-powerpc64.003'
gmake: *** [Makefile:941: all] Error 2
Command exited with non-zero status 2
nix_$ 

nix_$ cat stage_current 
stage3

So what exactly is needed in order to get past this?  Documented or otherwise?

[Bug target/82641] Unable to enable crc32 for a certain function with target attribute on ARM (aarch32)

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw  ---
ARMv8-a is the only architecture variant where the CRC extension is optional. 
In later variants it is enabled by default; in earlier versions of the
architecture it doesn't exist.

Your report lacks a testcase we can use to examine this more fully.

[Bug target/82674] ICE with -fstack-clash-protection

[law at redhat dot com]

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

--- Comment #2 from Jeffrey A. Law  ---
Right, but it's the expander to allocate dynamic space that's creating the
bogus RTL.  It's a trivial fix that I just need to run through some testing.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #11 from Qing Zhao  ---
(In reply to Wilco from comment #9)

> str(n)cmp with a constant string can be changed into memcmp if the string has 
> a
> known alignment or is an array of known size. We should check the common cases
> are implemented.

Please provide an example in which a str(n)cmp with a constant string can be
changed into
memcmp. 

(From my understanding, for the strcmp (p, “fish”),  since we don’t know what
will be in the string
pointed by “p”, and there might be NULL_terminator in any of the place of p, we
have to compare
each char in “p” one by one, do I miss anything here?)

[Bug tree-optimization/82700] New: ICE in printf-return-value with -fexec-charset=EBCDIC-US: converting to execution character set: Invalid or incomplete multibyte or wide character

[msebor at gcc dot gnu.org]

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

Bug ID: 82700
   Summary: ICE in printf-return-value with
-fexec-charset=EBCDIC-US: converting to execution
character set: Invalid or incomplete multibyte or wide
character
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following ICE came up in a discussion Re: [RFC] New pragma exec_charset
(https://gcc.gnu.org/ml/gcc-patches/2017-10/msg01672.html).  The program is
expected to compile with the same output as with -fexec-charset=IBM1047.

$ cat c.c && gcc  -Wall -O2 -fexec-charset=EBCDIC-US c.c
int main (void)
{
   char d[5];

   int n = __builtin_sprintf (d, "i=%i", 12345);

   if (n != 7)
 __builtin_abort ();
}

c.c: In function ‘main’:
c.c:5:34: warning: too many arguments for format [-Wformat-extra-args]
int n = __builtin_sprintf (d, "i=%i", 12345);
  ^~
during GIMPLE pass: printf-return-value
c.c:10:0: internal compiler error: converting to execution character set:
Invalid or incomplete multibyte or wide character


0x82fe9f c_cpp_error(cpp_reader*, int, int, rich_location*, char const*,
__va_list_tag (*) [1])
/ssd/src/gcc/svn/gcc/c-family/c-common.c:6075
0x1905da0 cpp_diagnostic_at
/ssd/src/gcc/svn/libcpp/errors.c:60
0x1905e72 cpp_diagnostic
/ssd/src/gcc/svn/libcpp/errors.c:91
0x1905f27 cpp_error(cpp_reader*, int, char const*, ...)
/ssd/src/gcc/svn/libcpp/errors.c:104
0x19067c0 cpp_errno(cpp_reader*, int, char const*)
/ssd/src/gcc/svn/libcpp/errors.c:300
0x18fa3c6 cpp_host_to_exec_charset(cpp_reader*, unsigned int)
/ssd/src/gcc/svn/libcpp/charset.c:798
0x82feeb c_common_to_target_charset(long)
/ssd/src/gcc/svn/gcc/c-family/c-common.c:6093
0x17de7a9 init_target_to_host_charmap
/ssd/src/gcc/svn/gcc/gimple-ssa-sprintf.c:319
0x17e68a8 execute
/ssd/src/gcc/svn/gcc/gimple-ssa-sprintf.c:3990
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/78809] Inline strcmp with small constant strings

[qing.zhao at oracle dot com]

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

--- Comment #10 from Qing Zhao  ---
>> From the data, we can see the inlined version of strcmp (by glibc) is much
>> slower than the direct call to strcmp.  (this is for size 2)
>> I am using GCC farm machine gcc116:
> 
> This result doesn't make sense - it looks like GCC is moving the strcmp call 
> in
> the 2nd case as a loop invariant, so you're just measuring a loop with just a
> subtract and orr instruction…

Yes, Wilco is right here.  -ftree-loop-im moves the call to strcmp out of the
loop.
in order to avoid this issue, I changed the options to

-O -fno-tree-loop-im

and checked the assembly of the routine “cmp2” for the INLINED and Non-INLINED
version.

Inlined version:
cmp2:
mov x4, x0
mov w2, 51712
movkw2, 0x3b9a, lsl 16
mov w0, 0
mov w3, 102
b   .L3
.L2:
neg w1, w1
orr w0, w0, w1
subsw2, w2, #1
beq .L5
.L3:
ldrbw1, [x4]
subsw1, w3, w1
bne .L2
ldrbw1, [x4, 1]
neg w1, w1
b   .L2
.L5:
ret

Non-inlined version:
cmp2:
stp x29, x30, [sp, -48]!
add x29, sp, 0
stp x19, x20, [sp, 16]
stp x21, x22, [sp, 32]
mov x22, x0
mov w19, 51712
movkw19, 0x3b9a, lsl 16
mov w20, 0
adrpx21, .LC0
add x21, x21, :lo12:.LC0
.L2:
mov x1, x21
mov x0, x22
bl  strcmp
orr w20, w20, w0
subsw19, w19, #1
bne .L2
mov w0, w20
ldp x19, x20, [sp, 16]
ldp x21, x22, [sp, 32]
ldp x29, x30, [sp], 48
ret

Then, the run-time performance data is:

qinzhao@gcc116:~/Bugs/78809/const_cmp/perf$ sh t_p
/home/qinzhao/Install/latest/bin/gcc -O -fno-tree-loop-im t_p_1.c t_p.c
-DINLINED
inlined version
34.73user 0.00system 0:34.73elapsed 99%CPU (0avgtext+0avgdata 360maxresident)k
0inputs+0outputs (0major+135minor)pagefaults 0swaps
/home/qinzhao/Install/latest/bin/gcc -O -fno-tree-loop-im t_p_1.c t_p.c
non-inlined version
138.79user 0.00system 2:18.77elapsed 100%CPU (0avgtext+0avgdata
356maxresident)k
0inputs+0outputs (0major+135minor)pagefaults 0swaps

Yes, looks like that the inlined version is much faster than the non-inlined
version on aarch64 platform.

[Bug target/82651] After r253879 GCC 8.0 can't build cross compiler for mingw32

[nico at josuttis dot de]

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

Nicolai Josuttis  changed:

   What|Removed |Added

 CC||nico at josuttis dot de

--- Comment #2 from Nicolai Josuttis  ---
same problem when trying to build gcc-8-20171022.tar.xz on CygWin with Win64.

[Bug rtl-optimization/82683] Combine: GCC generates bad code with -tune=thunderx2t99

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
The "failed to match" messages are hugely important (in fact, I want it
to print more: _why_ did combination fail, in all the cases where it is
not because of recog).

The "deferring deletion" messages are not from combine (from df, instead).
Yes they are annoying, much more so in other passes.

[Bug c++/82307] unscoped enum-base incorrect cast

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|mukesh.kapoor at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |8.0

--- Comment #8 from Paolo Carlini  ---
Fixed.

[Bug tree-optimization/82697] [6/7 Regression] Wrong optimization with aliasing and "if"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
Summary|[6/7/8 Regression] Wrong|[6/7 Regression] Wrong
   |optimization with aliasing  |optimization with aliasing
   |and "if"|and "if"

--- Comment #4 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/82697] [6/7 Regression] Wrong optimization with aliasing and "if"

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 24 13:51:45 2017
New Revision: 254047

URL: https://gcc.gnu.org/viewcvs?rev=254047=gcc=rev
Log:
2017-10-24  Richard Biener  

PR tree-optimization/82697
* tree-ssa-phiopt.c (cond_store_replacement): Use alias-set
zero for conditional load and unconditional store.

* gcc.dg/torture/pr82697.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr82697.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c

[Bug c++/82307] unscoped enum-base incorrect cast

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Tue Oct 24 13:49:13 2017
New Revision: 254046

URL: https://gcc.gnu.org/viewcvs?rev=254046=gcc=rev
Log:
/cp
2017-10-24  Mukesh Kapoor  
Paolo Carlini  

PR c++/82307
* cvt.c (type_promotes_to): Implement C++17, 7.6/4, about unscoped
enumeration type whose underlying type is fixed.

/testsuite
2017-10-24  Mukesh Kapoor  
Paolo Carlini  

PR c++/82307
* g++.dg/cpp0x/enum35.C: New.
* g++.dg/cpp0x/enum36.C: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/enum35.C
trunk/gcc/testsuite/g++.dg/cpp0x/enum36.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/82692] [8 Regression] Ordered comparisons used for unordered built-ins

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Segher Boessenkool from comment #3)
> The combine output you showed is _not_ succeeding though?  "matched"
> just means the rtx was recog()'ed; not that it was actually replaced.

FAOD, this is the sequence before combine:

--cut here--
(insn 7 6 8 2 (set (reg:CCFPU 17 flags)
(compare:CCFPU (reg:DF 95)
(reg/v:DF 91 [ x ]))) "pr82692.c":9 52 {*cmpiudf}
 (expr_list:REG_DEAD (reg:DF 95)
(expr_list:REG_EQUAL (compare:CCFPU (const_double:DF 0.0 [0x0.0p+0])
(reg/v:DF 91 [ x ]))
(nil
(insn 8 7 9 2 (set (reg:QI 94)
(unlt:QI (reg:CCFPU 17 flags)
(const_int 0 [0]))) "pr82692.c":9 664 {*setcc_qi}
 (expr_list:REG_DEAD (reg:CCFPU 17 flags)
(nil)))
(insn 9 8 10 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 94)
(const_int 0 [0]))) "pr82692.c":9 1 {*cmpqi_ccno_1}
 (expr_list:REG_DEAD (reg:QI 94)
(nil)))
(jump_insn 10 9 32 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "pr82692.c":9 668 {*jcc}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 182536112 (nil)))
 -> 34)
--cut here--

which is converted by combine pass to:

--cut here--
(note 7 6 8 2 NOTE_INSN_DELETED)
(note 8 7 9 2 NOTE_INSN_DELETED)
(insn 9 8 10 2 (set (reg:CCFP 17 flags)
(compare:CCFP (reg:DF 95)
(reg/v:DF 91 [ x ]))) "pr82692.c":9 50 {*cmpidf}
 (expr_list:REG_DEAD (reg:DF 95)
(nil)))
(jump_insn 10 9 32 2 (set (pc)
(if_then_else (ge (reg:CCFP 17 flags)
(const_int 0 [0]))
(label_ref:DI 34)
(pc))) "pr82692.c":9 668 {*jcc}
 (expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 182536112 (nil)))
 -> 34)
--cut here--

UNLT compare (CCFPUmode) has been converted to GE compare (CCFPmode). This is
not correct as far as traps are concerned, since UNLT doesn't trap on qNaN,
while GE does.

[Bug target/82674] ICE with -fstack-clash-protection

[bergner at gcc dot gnu.org]

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

--- Comment #1 from Peter Bergner  ---
That offset is too large to fit in the stdu immed field, so it really shouldn't
have been accepted by the rs6000_legitim*_ functions.

[Bug ada/82639] Legal program rejected

[porton at narod dot ru]

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

Victor Porton  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Victor Porton  ---
They say it is NOT an error in the compiler:

https://groups.google.com/d/msg/comp.lang.ada/IFjnioG1a28/Qcw5sIyUAgAJ