[Bug ada/86916] New: 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 Bug ID: 86916 Summary: 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rogermc at iinet dot net.au Target Milestone: --- Created attachment 44525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44525&action=edit Requested files Command (via GPS): gprbuild -d -P/Ada_Source/OglAda_Examples/ogl_dev/22_loading_test/loader_test.gpr -XMode=debug -XLibrary_Type=static -XAuto_Exceptions=enabled -XWindowing_System=quartz -XGLFW_Version=3 -s --config=/Ada_Source/default.cgpr compilation abandoned gprbuild: *** compilation phase failed [2018-08-11 17:27:28] process exited with status 4, 93% (117/125), elapsed time: 28.32s +===GNAT BUG DETECTED==+ | 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access | | Error detected at animation.adb:61:16| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ List of files compilation abandoned gprbuild: *** compilation phase failed [2018-08-11 17:27:28] process exited with status 4, 93% (117/125), elapsed time: 28.32s
[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 --- Comment #4 from Steffen Schuemann --- I just realised, if I'm all wrong, and not handling this as an error is the way to go, as described in LWG-defect-#2935, create_directory() would violate the new behaviour described in 2935, as it passes my unit tests so it throws an exception if a file with that name exists. One way or the other, something doesn't match (also verified on g++ 8.1.0 on macOS and by looking into the code).
[Bug tree-optimization/86858] [9 Regression] GCC ICE at -O3 in as_a, at is-a.h:197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86858 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed. Thanks for the bug report.
[Bug c++/86728] [7/8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86728 --- Comment #3 from Jason Merrill --- Author: jason Date: Sat Aug 11 10:47:03 2018 New Revision: 263484 URL: https://gcc.gnu.org/viewcvs?rev=263484&root=gcc&view=rev Log: PR c++/86728 - C variadic generic lambda. * parser.c (cp_parser_parameter_declaration): Don't turn 'auto' into a pack if it's followed by a declarator-id. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug tree-optimization/86884] aggressive loop optimization and effective type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86884
Martin Uecker changed:
What|Removed |Added
CC||uecker at eecs dot berkeley.edu
--- Comment #1 from Martin Uecker ---
Here are some additional comments, which may help to analyze this (or not).
The optimization also works without struct Y, the initialization, and the
memcpy in which case the example is not undefined by itself (see case 1 below).
From a C language point of view (I can't comment about GIMPLE), the
optimization seems legal as from the access p->c one can infer the effective
type. In case 3, one cannot infer the effective type and gcc also does not
optimize this case. Case 2 is interesting. I think using p->c to construct a
pointer to c implies that the storage at p must have correct effective type,
but I am not entirely sure. For strlen, case 1 and case 2 are optimized, but
not case 3. (tested with gcc from recent git).
#include
#include
#include
struct X { int i; char c[4]; int j;};
void f(struct X *p)
{
int n = 0;
#if 1
// case 1
while (p->c[n]) // uncond. abort
++n;
#else
#if 1
// case 2
char* pc = p->c; // no uncond. abort
#else
// case 3
char* pc = (char*)p + offsetof(struct X, c); // no uncond. abort
#endif
while (pc[n])
++n;
#endif
if (n < 7)
abort();
}
void g(struct X *p)
{
int n = 0;
#if 1
// case 1
n = strlen(p->c); // uncond. abort
#else
#if 1
// case 2
char* pc = p->c; // uncond. abort
#else
// case 3
char* pc = (char*)p + offsetof(struct X, c); // no uncond. abort
#endif
n = strlen(pc);
#endif
if (n < 7)
abort();
}
[Bug c++/86728] [7/8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86728 --- Comment #4 from Jason Merrill --- Author: jason Date: Sat Aug 11 11:01:49 2018 New Revision: 263485 URL: https://gcc.gnu.org/viewcvs?rev=263485&root=gcc&view=rev Log: PR c++/86728 - C variadic generic lambda. * parser.c (cp_parser_parameter_declaration): Don't turn 'auto' into a pack if it's followed by a declarator-id. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic19.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/parser.c
[Bug c++/86728] [7/8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86728 --- Comment #5 from Jason Merrill --- Author: jason Date: Sat Aug 11 11:02:22 2018 New Revision: 263486 URL: https://gcc.gnu.org/viewcvs?rev=263486&root=gcc&view=rev Log: PR c++/86728 - C variadic generic lambda. * parser.c (cp_parser_parameter_declaration): Don't turn 'auto' into a pack if it's followed by a declarator-id. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic19.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c
[Bug c++/86728] [7/8/9 Regression] unexpected error: conversion from ', ...)>' to non-scalar type 'std::function' requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86728 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Aug 11 11:29:12 2018 New Revision: 263487 URL: https://gcc.gnu.org/viewcvs?rev=263487&root=gcc&view=rev Log: PR tree-optimization/86835 * tree-ssa-math-opts.c (insert_reciprocals): Even when inserting new_stmt after def_gsi, make sure to insert new_square_stmt after that stmt, not 2 stmts before it. * gcc.dg/pr86835.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr86835.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/86914] gcc 8.1 -O2 generates wrong code with strlen() of pointers within one-element arrays of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914 --- Comment #1 from Even Rouault --- Interstingly with gcc 8.2, char c[0] doesn't generate the appropriate code. The only way of making it work is to use char c[] syntax
[Bug ada/86916] 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 --- Comment #1 from Roger Mc Murtrie --- I am also getting this problem with gcc 6.1.0 +===GNAT BUG DETECTED==+ | 6.1.0 (x86_64-apple-darwin15) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:3011 | | Error detected at assimp_texture.ads:65:34 As I have used gcc 6.1.0 with getting this error in the past I'm wondering if it has something to do with OSX. Mac mini (Mid 2011) OSX 10.13.6 Xcode 9.4.1
[Bug ada/86916] 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 --- Comment #2 from Roger Mc Murtrie --- Correction "As I have used gcc 6.1.0 with getting this error" should have been: "As I have used gcc 6.1.0 WITHOUT getting this error"
[Bug c++/86917] New: ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917
Bug ID: 86917
Summary: ICE in verify_ctor_sanity, at cp/constexpr.c:2798
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hans.buchmann at fhnw dot ch
Target Milestone: ---
Created attachment 44526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44526&action=edit
The Bug
Compiling the (wrong) code
--8<--8<--8<--8<--8<--8<--8<--
struct Byte
{
constexpr Byte():c(0){}
static const Byte Zero;
unsigned c;
};
struct Word
{
typedef Byte W[4];
constexpr Word():w({Byte::Zero,Byte::Zero,Byte::Zero,Byte::Zero}){}
W w;
};
struct AES256
{
AES256();
Word w[60];
};
AES256::AES256()
{
}
--8<--8<--8<--8<--8<--8<--8<--
with
g++ -c -o bug.o bug.cc
results in:
--8<--8<--8<--8<--8<--8<--8<--
bug.cc: In constructor \u2018AES256::AES256()\u2019:
bug.cc:21:16: in \u2018constexpr\u2019 expansion of \u2018Word()\u2019
bug.cc:21:16: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2798
AES256::AES256()
^
Please submit a full bug report,
with preprocessed source if appropriate.
--8<--8<--8<--8<--8<--8<--8<--
g++ -v
--8<--8<--8<--8<--8<--8<--8<--
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/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 --enable-multilib --disable-werror \
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.0 (GCC)
--8<--8<--8<--8<--8<--8<--8<--
Sincerely
Hans Buchmann
[Bug c++/86917] [6/7/8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-11 CC||mpolacek at gcc dot gnu.org Summary|ICE in verify_ctor_sanity, |[6/7/8/9 Regression] ICE |at cp/constexpr.c:2798 |in verify_ctor_sanity, at ||cp/constexpr.c:2798 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, thanks for reporting. G++ 5 works.
[Bug c++/86917] [6/7/8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 --- Comment #2 from Marek Polacek --- Started with Merge C++ delayed folding branch., r230365.
[Bug bootstrap/81033] [8/9 Regression] there are cases where ld64 is not able to determine correct atom boundaries from the output GCC currently produces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81033 Elliot Saba changed: What|Removed |Added CC||staticfloat at gmail dot com --- Comment #41 from Elliot Saba --- Has there been any progress on this? We are running into this while trying to cross-compile GCC for Darwin. Has this been fixed in 8.3.0?
[Bug c++/86915] Segmentation fault for an array of auto in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86915 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-11 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, doesn't seem like a regression.
[Bug c++/86915] Segmentation fault for an array of auto in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86915 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug tree-optimization/86835] [8 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] Bogus "is |[8 Regression] Bogus "is |used uninitialized" warning |used uninitialized" warning |with -ffast-math|with -ffast-math --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/86914] [8/9 Regression] -O2 generates wrong code with strlen() of pointers within one-element arrays of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-11 CC||law at redhat dot com, ||msebor at gcc dot gnu.org Summary|gcc 8.1 -O2 generates wrong |[8/9 Regression] -O2 |code with strlen() of |generates wrong code with |pointers within one-element |strlen() of pointers within |arrays of structures|one-element arrays of ||structures Ever confirmed|0 |1 Known to fail||8.2.0, 9.0 --- Comment #2 from Martin Sebor --- Confirmed. Most likely caused by r255790. The strlen pass sees: _1 = &MEM[(void *)p_3(D) + 5B]; _2 = __builtin_strlen (_1); The code in maybe_set_strlen_range() tries to avoid using the size of the last member array (GCC treats all such arrays as flexible array members) by checking the result of array_at_struct_end_p() but the function doesn't handle MEM_REF and returns false. The optimization is disabled if the array is a bona fide C11 flexible array member because the size of such an array is unknown. Enhancing array_at_struct_end_p() to deal with MEM_REF or adding an array_not_at_struct_end_p() that returns a conservative result would fix this but the strlen range optimization will likely be disabled regardless.
[Bug tree-optimization/86914] [8/9 Regression] -O2 generates wrong code with strlen() of pointers within one-element arrays of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Martin Sebor --- Let me handle this.
[Bug middle-end/78917] missing -Wnonnull passing null to a nonnull function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78917
--- Comment #2 from Martin Sebor ---
Another test case:
$ cat f.c && gcc -O2 -S -Wall -Wextra f.c
int f (int i)
{
const char * p = __builtin_strchr (i ? "123" : "456", '2');
return __builtin_strlen (p);
}
The strlen argument is a phi with a null operand so that should make it easy to
detect:
# prephitmp_11 = PHI <_10(3), 0B(2)>
_1 = __builtin_strlen (prephitmp_11);
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 --- Comment #1 from Jonathan Wakely --- Does hppa64 really not have native atomic ops for sizeof(void*) ? I guess we need to use a mutex here, as I don't want libstdc++ to depend on libatomic.
[Bug tree-optimization/80334] [5 Regression] Segfault when taking address of copy of unaligned struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #11 from Alexandre Oliva ---
FWIW, this testcase still fails with unaligned accesses in the trunk:
#ifndef T
# define T long
#endif
#ifndef R
# define R "r"
#endif
typedef T A; // #define T to long or __int128
struct B { char d; A c; } __attribute__((packed));
B b[50]; // many elements to avoid loop unrolling
int main () {
for (int i = 0; i < sizeof(b) / sizeof(*b); i++) {
asm ("" : "+" R (b[i].unpacked)); // #define R to "r" on ppc or "x" on
x86_64
}
}
[Bug tree-optimization/80334] [5 Regression] Segfault when taking address of copy of unaligned struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334 --- Comment #12 from Alexandre Oliva --- Created attachment 44527 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44527&action=edit candidate patch to fix the error noted in comment 11 This patch fixes the unaligned accesses in the testcase in comment 11. I haven't yet tested it otherwise.
[Bug c/85704] [8/9 Regression] cc1 run out of memory when it compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85704 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed.
[Bug middle-end/86627] [6/7 Regression] Signed 128-bit division by 2 no longer expanded to RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86627 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8/9 Regression] Signed |[6/7 Regression] Signed |128-bit division by 2 no|128-bit division by 2 no |longer expanded to RTL |longer expanded to RTL --- Comment #10 from Jakub Jelinek --- Fixed for 8.3+.
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0
[Bug c++/86738] [8 Regression] gcc 8.2: Internal compiler error memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86738 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] gcc 8.2: |[8 Regression] gcc 8.2: |Internal compiler error |Internal compiler error |memcpy |memcpy --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/86569] [6/7/8 Regression] -Wnonnull-compare affects code generation since r233684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8/9 Regression]|[6/7/8 Regression] |-Wnonnull-compare affects |-Wnonnull-compare affects |code generation since |code generation since |r233684 |r233684 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/86918] New: internal compiler error: unexpected expression 'v' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86918
Bug ID: 86918
Summary: internal compiler error: unexpected expression 'v' of
kind template_parm_index
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/** BEGIN SOURCE **/
template
struct S {
template
struct X;
};
template<>
template
struct S::X {
static constexpr bool value = v;
};
static_assert(S::X::value);
/*** END SOURCE ***/
: In instantiation of 'struct S::X':
:13:30: required from here
:9:18: internal compiler error: unexpected expression 'v' of kind
template_parm_index
9 | struct S::X {
| ^
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 --- Comment #2 from dave.anglin at bell dot net --- On 2018-08-11 3:31 PM, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 > > --- Comment #1 from Jonathan Wakely --- > Does hppa64 really not have native atomic ops for sizeof(void*) ? Sadly, it lacks an atomic compare and exchange operation. The mutex support might have some form of kernel support but I don't know what it is. I've been working on atomic load and store support. > > I guess we need to use a mutex here, as I don't want libstdc++ to depend on > libatomic. > Yes. Dave
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 --- Comment #3 from Jonathan Wakely --- N.B. this doesn't need compare and exchange, just exchange. I'll fix this early next week.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #9 from John David Anglin --- I don't have a 11.31 system, so you will probably have to work out and test the fix. The hpux_long_double hack does two things. It comments out the _LONG_DOUBLE define and changes "long_double" to "long double". Steve Ellcey disabled it for 11.31 and added the hpux_long_double_2 hack for 11.31. >From the build error, it looks like 11.31 needs a hack to change "long_double" to "long double". It would help to see the uses of long_double in stdlib.h.
[Bug tree-optimization/86919] New: strlen of a multidimensional array element with non-constant offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86919
Bug ID: 86919
Summary: strlen of a multidimensional array element with
non-constant offset not folded
Product: gcc
Version: 9.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: ---
GCC 9 folds the first of the strlen() calls below where the first index into
the array is a literal constant into an efficient expression but it misses the
same opportunity in the second call where the index is a variable with a known
value. (GCC 8folds neither.)
$ cat f.c && gcc -O2 -S -Wall -Wextra -Wnull-dereference
-fdump-tree-optimized=/dev/stdout f.c
const char b[][5] = { "123", "1234" };
int f (int j)
{
return __builtin_strlen (&b[0][j]); // folded to 3 - i
}
int g (int j)
{
int i = 0;
return __builtin_strlen (&b[i][j]); // not folded
}
;; Function f (f, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=1)
Removing basic block 5
f (int j)
{
unsigned int j.1_1;
unsigned int _2;
int iftmp.0_3;
int iftmp.0_5;
[local count: 1073741825]:
if (j_4(D) <= 3)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
j.1_1 = (unsigned int) j_4(D);
_2 = 3 - j.1_1;
iftmp.0_5 = (int) _2;
[local count: 1073741825]:
# iftmp.0_3 = PHI
return iftmp.0_3;
}
;; Function g (g, funcdef_no=1, decl_uid=1909, cgraph_uid=2, symbol_order=2)
g (int j)
{
const char * _1;
long unsigned int _2;
int _5;
sizetype _6;
[local count: 1073741825]:
_6 = (sizetype) j_3(D);
_1 = &b + _6;
_2 = __builtin_strlen (_1);
_5 = (int) _2;
return _5;
}
[Bug c++/86920] New: A matching template specialization is not selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86920
Bug ID: 86920
Summary: A matching template specialization is not selected
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.reshetnikov at gmail dot com
Target Milestone: ---
/** BEGIN SOURCE **/
template
struct S {
template
struct X {
static constexpr bool value = false;
};
};
template<>
template
struct S::X {
static constexpr bool value = true;
};
static_assert(S::X::value);
/*** END SOURCE ***/
EXPECTED: no errors
ACTUAL:
:15:15: error: static assertion failed
15 | static_assert(S::X::value);
| ^~
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #10 from The Written Word
---
(In reply to John David Anglin from comment #9)
> It would help to see the uses of long_double in stdlib.h.
/usr/include/stdlib.h has:
# ifndef _LONG_DOUBLE
#define _LONG_DOUBLE
# if !defined(__ia64) || !defined(_PROTOTYPES) || defined(_LONG_DOUBLE_STRUCT)
typedef struct {
uint32_t word1, word2, word3, word4;
} long_double;
extern long_double strtold __((const char * __restrict, char ** __restrict));
# else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
#ifdef _INCLUDE_HPUX_SOURCE
typedef long double long_double;
#endif /* _INCLUDE_HPUX_SOURCE */
extern long double strtold __((const char * __restrict, char ** __restrict));
# endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
#endif /* _LONG_DOUBLE */
[Bug libstdc++/86910] std::filesystem::create_directories doesn't set error code or throw while violating postcondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86910 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Jonathan Wakely --- (In reply to Steffen Schuemann from comment #3) > gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu > 8-20180414-1ubuntu2) Why are you using a pre-release snapshot from 4 months ago when the 8.1 and 8.2 releases have been made since then? > I see, that LWG defect 2935 addresses this question. But first, my > understanding is a defect in WP status is still not part of the standard, so > it might become part of some C++20 or some TC, but it currently doesn't seem > to be part of C++17 (selected by -std=c++17). I might be wrong with that. It's a defect in C++17. We implement the fixes, not implement a standard that is known to be defective. Why would you want a pedantic adherence to a defective standard? Do you also want compiler bugs to go unfixed, because they were present in past releases? :-) Anyway, the manual says what -std=c++17 means: "The 2017 ISO C++ standard plus amendments." https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html > And second, I still I don't really see how this is expected to be used by > the developers usinf std::fs. Without that postcondition you have to do a > check for the directory before using that it, so the "spared" call was > simply moved to the user code. Not testing could lead to harder to track > down bugs later on in a different domain of the software. Yes, I agree. I don't think pushing the is_directory check onto users is helpful, but that's what the Defect Report resolution says. I was discussing it recently with the developer of libc++'s std::filesystem implementation and I think we both fail to meet the spec for create_directory (as you noted in comment 4). I'm not sure what libc++ does for create_directories. I haven't changed create_directory, because I like its current behaviour. I haven't changed create_directories because it was accidentally already doing what 2935 wants, and intentionally changing to disagree with the spec seems wrong. i.e. inertia has won. > And third, as testing for existence and type can be done with one call, That's true for my implementation of create_directories, but not for create_directory, where you don't need to test for existence. You call mkdir and if it returns EEXIST you know it already exists. To see if it's a directory requires another system call (which I currently do). I've now asked the standard committee to reconsider whether we made the right call on 2935. I'll confirm this, because whatever happens create_directory and create_directories should be consistent, so I'll need to change one of them.
[Bug tree-optimization/86829] Missing sin(atan(x)) and cos(atan(x)) optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86829 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez --- (In reply to Giuliano Belinassi from comment #3) > (In reply to Marc Glisse from comment #1) > > > > Do you have a copyright assignment (https://gcc.gnu.org/contribute.html) ? > > No. Sorry, but I think I may need help getting this right. Are there any > tips? https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #11 from The Written Word --- Created attachment 44528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44528&action=edit stdlib.h long_double patch
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599 --- Comment #12 from The Written Word --- (In reply to The Written Word from comment #11) > Created attachment 44528 [details] > stdlib.h long_double patch My first attempt but it didn't work.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #13 from The Written Word
---
(In reply to The Written Word from comment #10)
> (In reply to John David Anglin from comment #9)
> > It would help to see the uses of long_double in stdlib.h.
>
> /usr/include/stdlib.h has:
>
> # ifndef _LONG_DOUBLE
> #define _LONG_DOUBLE
> # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> defined(_LONG_DOUBLE_STRUCT)
> typedef struct {
> uint32_t word1, word2, word3, word4;
> } long_double;
> extern long_double strtold __((const char * __restrict, char ** __restrict));
> # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> #ifdef _INCLUDE_HPUX_SOURCE
> typedef long double long_double;
> #endif /* _INCLUDE_HPUX_SOURCE */
> extern long double strtold __((const char * __restrict, char ** __restrict));
> # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> #endif /* _LONG_DOUBLE */
I think the problem on 11.31 is that the strtold() definition is in the above.
We can't simply remove it all and change long_double->long double in the
remainder of the file to get the function definition changed.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #14 from The Written Word
---
(In reply to The Written Word from comment #13)
> (In reply to The Written Word from comment #10)
> > (In reply to John David Anglin from comment #9)
> > > It would help to see the uses of long_double in stdlib.h.
> >
> > /usr/include/stdlib.h has:
> >
> > # ifndef _LONG_DOUBLE
> > #define _LONG_DOUBLE
> > # if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > defined(_LONG_DOUBLE_STRUCT)
> > typedef struct {
> > uint32_t word1, word2, word3, word4;
> > } long_double;
> > extern long_double strtold __((const char * __restrict, char **
> > __restrict));
> > # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> > #ifdef _INCLUDE_HPUX_SOURCE
> > typedef long double long_double;
> > #endif /* _INCLUDE_HPUX_SOURCE */
> > extern long double strtold __((const char * __restrict, char **
> > __restrict));
> > # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> > #endif /* _LONG_DOUBLE */
>
> I think the problem on 11.31 is that the strtold() definition is in the
> above. We can't simply remove it all and change long_double->long double in
> the remainder of the file to get the function definition changed.
Hmm, maybe two new rules, the first to remove everything before "extern long
double strtold" and change long_double->long double and the second to remove
the two lines after "extern long double strtold". Let me try to come up with
something.
[Bug target/86599] Problems building libgfortran from 7.2.0 on HP-UX 11.31/PA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
--- Comment #15 from dave.anglin at bell dot net ---
On 2018-08-11 5:51 PM, bugzilla-gcc at thewrittenword dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86599
>
> --- Comment #13 from The Written Word com> ---
> (In reply to The Written Word from comment #10)
>> (In reply to John David Anglin from comment #9)
>>> It would help to see the uses of long_double in stdlib.h.
>> /usr/include/stdlib.h has:
>>
>> # ifndef _LONG_DOUBLE
>> #define _LONG_DOUBLE
>> # if !defined(__ia64) || !defined(_PROTOTYPES) ||
>> defined(_LONG_DOUBLE_STRUCT)
>> typedef struct {
>> uint32_t word1, word2, word3, word4;
>> } long_double;
>> extern long_double strtold __((const char * __restrict, char ** __restrict));
>> # else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
>> #ifdef _INCLUDE_HPUX_SOURCE
>> typedef long double long_double;
>> #endif /* _INCLUDE_HPUX_SOURCE */
>> extern long double strtold __((const char * __restrict, char ** __restrict));
>> # endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
>> #endif /* _LONG_DOUBLE */
> I think the problem on 11.31 is that the strtold() definition is in the above.
> We can't simply remove it all and change long_double->long double in the
> remainder of the file to get the function definition changed.
You could replace the above with prototype for strtold().
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 --- Comment #4 from dave.anglin at bell dot net --- On 2018-08-11 4:08 PM, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 > > --- Comment #3 from Jonathan Wakely --- > N.B. this doesn't need compare and exchange, just exchange. There also isn't exchange operation. :-(
[Bug c++/86920] A matching template specialization is not selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86920 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. Not a regression as far as I can tell.
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846
--- Comment #5 from Jonathan Wakely ---
This should do it:
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
namespace std _GLIBCXX_VISIBILITY(default)
{
@@ -81,7 +82,31 @@ namespace pmr
constant_init newdel_res{};
constant_init null_res{};
+#if ATOMIC_POINTER_LOCK_FREE == 2
constant_init> default_res{&newdel_res.obj};
+#else
+struct locking_atomic
+{
+ constexpr locking_atomic(memory_resource* r) : val(r) { }
+ mutex mx;
+ memory_resource* val;
+
+ memory_resource* load()
+ {
+ lock_guard lock(mx);
+ return val;
+ }
+
+ memory_resource* exchange(memory_resource* r)
+ {
+ lock_guard lock(mx);
+ auto prev = val;
+ val = r;
+ return prev;
+ }
+};
+constant_init default_res{&newdel_res.obj};
+#endif
} // namespace
memory_resource*
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 --- Comment #6 from dave.anglin at bell dot net --- On 2018-08-11 8:04 PM, redi at gcc dot gnu.org wrote: > This should do it: I'll give it a test on my next build. Thanks, Dave
[Bug ada/86916] 8.1.0 (x86_64-apple-darwin15) Constraint_Error erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86916 --- Comment #3 from Roger Mc Murtrie --- This problem doesn't occur for compile only. It occurs when I Build All from GPS
