[Bug c/86584] New: Incorrect -Wsequence-point warning on structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584
Bug ID: 86584
Summary: Incorrect -Wsequence-point warning on structure member
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rusty at rustcorp dot com.au
Target Milestone: ---
gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0, x86-64. Also in gcc-8 (Ubuntu
8.1.0-1ubuntu1) 8.1.0.
I have a macro which does an assignment, and also hands the address of the same
var to the function. The reduced version is below: it gives a spurious warning
when the var involved is a struct member:
struct s {
int f;
};
void func(int *f, int);
int main(void)
{
struct s s;
int f;
/* bad-warning-gcc.c:13:17: warning: operation on ‘s.f’ may be
undefined [-Wsequence-point] */
func(&s.f, s.f = 1);
/* No warning for this */
func(&f, f = 1);
return 0;
}
[Bug bootstrap/37704] RFE: Need specific version of --disable-multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37704 Eric Gallager changed: What|Removed |Added Keywords||build Severity|normal |minor
[Bug target/69179] undocumented darwin attributes "apple_kext_compatibility" and "weak_import"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69179 --- Comment #4 from Eric Gallager --- (In reply to Iain Sandoe from comment #3) > (In reply to sandra from comment #0) > > config/darwin.c defines attributes "apple_kext_compatibility" and > > "weak_import" which have no documentation in the GCC manual. > > > > "apple_kext_compatibility" seems related to the also-undocumented > > -fapple-kext command-line option (see PR 62273). Reading the code, I'm > > wondering if a feature intended to provide backwards compatibility with GCC > > 2.95 is even relevant to modern versions of Darwin, or whether this might be > > a candidate for deletion as obsolete. > > The purpose of the attribute is to allow the VTABLE for c++ (in kernel > modules) to be altered to be compatible with GCC2.95 layouts for use with > Darwin <= 8. There is an outside possibility it might be relevant to m32 > Darwin9 (this needs checking). > > This option is recognised but not implemented - it looks like the > APPLE_LOCAL changes in 4.2.1 were never upstreamed (or never accepted, or > subsequently removed). > > I think, documentation-wise, we could (now) note the facts (i.e. that it's > recognised in sources but unimplemented). > > For the future; > 1. I doubt that there's any serious appetite for introducing intrusive > changes to c++ to support an EOL platform (if we do it at all I'd say save > it for a "Vendor Branch"). ISTM that folks who need to support such kernel > modules are not looking for up-to-date c++11 features and could just use > apple g++-4.2. > > 2. We should introduce at least a warning in the current source that the > option is not enacted. > > 3. Unless anyone disagrees with (1) and has the time/enthusiasm to implement > and push the implementation though, I think we should note that this > attribute is deprecated > I have the time/enthusiasm but neither the know-how nor confidence nor attention span > 4. It's likely that we should review whether the -fapple-kext stuff has any > function/meaning [to the ppc port] as things stand.
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #4 from Eric Gallager ---
(In reply to Martin Liška from comment #3)
> Thanks for CC. Patches are currently under review.
> About this PR: as 'b' is undeclared, the whole statement with the expression
> is ignored and we have:
>
> (gdb) p debug_function(cfun->decl, 0)
> f (int a)
> {
>[0.00%] [count: INV]:
> return;
>
> }
>
> That's why we then warn, it's reasonable in my opinion. However I'm not a FE
> maintainer, maybe it's doable.
Which FE maintainer would be the right one to ask?
[Bug other/36994] gcc/makefile contains one very long line (over 2k)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36994 Eric Gallager changed: What|Removed |Added Keywords||build Severity|normal |enhancement --- Comment #3 from Eric Gallager --- (In reply to Jay from comment #0) > gcc-4.3.1/gcc/makefile contains one very long line, via substitution of > gtfiles. > This is "inconvenient" and "annoying" but works. Reprioritizing as an enhancement
[Bug tree-optimization/86552] missing warning for reading past the end of non-string arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86552 --- Comment #2 from Martin Sebor --- Created attachment 44407 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44407&action=edit Preliminary patch. Lightly tested patch to apply on top of the one for bug 86532.
[Bug c++/86583] New: exception specification of explicitly defaulted destructor does not match the calculated one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86583
Bug ID: 86583
Summary: exception specification of explicitly defaulted
destructor does not match the calculated one
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
struct T {
T() noexcept(false) { }
~T() noexcept(false) { }
};
struct A
{
A() noexcept = default;
~A() noexcept = default;
T t;
};
g++ accepts the code, but I think it shouldn't be.
In fact, g++4.9.0 rejects the code:
ex.cc:8:5: error: function 'A::A()' defaulted on its first declaration with an
exception-specification that differs from the implicit declaration 'A::A()'
A() noexcept = default;
^
ex.cc:9:5: error: function 'A::~A()' defaulted on its first declaration with an
exception-specification that differs from the implicit declaration 'A::~A()'
~A() noexcept = default;
I tried clang++. It also rejects the code:
ex.cc:8:2: error: exception specification of explicitly defaulted default
constructor does not match the calculated one
A() noexcept = default;
^
ex.cc:9:2: error: exception specification of explicitly defaulted
destructor does not match the calculated one
~A() noexcept = default;
^
2 errors generated.
[Bug c++/86578] requested alignment is dependent but declaration is not dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86578 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- This is an excplict extension which GCC supports. Clang might not want to support this extension but GCC does.
[Bug debug/86582] New: [debug] vla size reported as 0 at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582
Bug ID: 86582
Summary: [debug] vla size reported as 0 at Og
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this test-case, minimized from vla-1.c:
...
/* { dg-do run } */
/* { dg-options "-g" } */
int __attribute__((noinline, noclone))
f1 (int i)
{
char a[i + 1];
a[0] = 5;
return a[0]; /* { dg-final { gdb-test . "sizeof (a)" "6" } } */
}
int
main ()
{
volatile int j;
int i = 5;
asm volatile ("" : "=r" (i) : "0" (i));
j = f1 (i);
return 0;
}
...
This fails at Og:
...
FAIL: gcc.dg/guality/vla-1.c -Og -DPREVENT_OPTIMIZATION line . sizeof (a) ==
6
...
The size is reported as 0 by gdb:
...
$ gdb vla-1.exe -batch -ex "b 10" -ex "r" -ex "p sizeof(a)"
Breakpoint 1 at 0x40049b: file vla-1.c, line 10.
Breakpoint 1, f1 (i=) at vla-1.c:10
10return a[0]; /* { dg-final { gdb-test . "sizeof (a)" "6" } }
*/
$1 = 0
...
We should be able to report the correct size, because the vla is not optimized
away.
AFAIU from debugging gdb, the evaluation of this location expression:
...
.value 0xe # Location expression size
.byte 0xf3# DW_OP_GNU_entry_value
.uleb128 0x1
.byte 0x55# DW_OP_reg5
.byte 0x23# DW_OP_plus_uconst
.uleb128 0x1
.byte 0x8 # DW_OP_const1u
.byte 0x20
.byte 0x24# DW_OP_shl
.byte 0x8 # DW_OP_const1u
.byte 0x20
.byte 0x26# DW_OP_shra
.byte 0x31# DW_OP_lit1
.byte 0x1c# DW_OP_minus
.byte 0x9f# DW_OP_stack_value
...
fails on the DW_OP_GNU_entry_value.
It fails due to this throw in dwarf_expr_reg_to_entry_parameter in gdb:
...
/* DW_TAG_call_site_parameter will be missing just if GCC could not
determine its value. */
throw_error (NO_ENTRY_VALUE_ERROR, _("Cannot find matching parameter "
"at DW_TAG_call_site %s at %s"),
paddress (gdbarch, caller_pc),
msym == NULL ? "???" : MSYMBOL_PRINT_NAME (msym));
...
I see in main though:
...
callf1
.LVL9:
...
and
...
.uleb128 0x6# (DIE (0x6a) DW_TAG_call_site)
.quad .LVL9 # DW_AT_call_return_pc
.long 0x84# DW_AT_call_origin
...
By modifying main to return i, I get in addition:
...
.uleb128 0x7# (DIE (0x77) DW_TAG_call_site_parameter)
.uleb128 0x1# DW_AT_location
.byte 0x55# DW_OP_reg5
.uleb128 0x2# DW_AT_call_value
.byte 0x73# DW_OP_breg3
.sleb128 0
...
and then gdb prints sizeof(a) as expected.
This seems to be cause DW_TAG_call_site_parameter is generated based on
REG_CALL_ARG_LOCATION, and in the case without call_site_parameter we have:
...
(call_insn 15 39 44 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("f1") [flags 0x3] ) \
[0 f1 S1 A8])
(const_int 0 [0]))) "vla-1.c":19 722 {*call_value}
(expr_list:REG_CALL_ARG_LOCATION (nil)
(expr_list:REG_DEAD (reg:SI 5 di)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil
(expr_list:SI (use (reg:SI 5 di))
(nil)))
...
and in the case with call_site_parameter we have:
...
(call_insn 15 14 17 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("f1") [flags 0x3] ) \
[0 f1 S1 A8])
(const_int 0 [0]))) "vla-1.c":19 722 {*call_value}
(expr_list:REG_CALL_ARG_LOCATION (expr_list:REG_DEP_TRUE (concat:SI
(reg:SI 5 di)
(reg:SI 3 bx [orig:89 i ] [89]))
(nil))
(expr_list:REG_DEAD (reg:SI 5 di)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil
(expr_list:SI (use (reg:SI 5 di))
(nil)))
...
So, why doesn't var-tracking generate the REG_CALL_ARG_LOCATION that we need?
[Bug c++/86578] requested alignment is dependent but declaration is not dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86578 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743 GCC 4.3.x and above support this feature.
[Bug c++/86581] New: constexpr variable is not checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86581
Bug ID: 86581
Summary: constexpr variable is not checked
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
template struct V {
union { int n; struct { int x,y; }; };
constexpr V() : x(0) {}
};
constexpr V v;
g++ does not check whether v is initialized. Instead, clang++ does that:
code0.cpp:6:18: error: constexpr variable 'v' must be initialized by a
constant expression
constexpr V v;
^
code0.cpp:6:18: note: subobject of type 'int' is not initialized
1 error generated.
[Bug c++/86580] New: No warning for default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86580
Bug ID: 86580
Summary: No warning for default arguments
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
struct S { S(const S&, int); S(int); }; S::S(const S& = S(0), int = 0) {}
g++ accepts without any warning messages. Instead, clang++ reports:
code0.cpp:1:55: error: addition of default argument on redeclaration makes
this constructor a default constructor
struct S { S(const S&, int); S(int); }; S::S(const S& = S(0), int = 0) {}
^
code0.cpp:1:12: note: previous declaration is here
struct S { S(const S&, int); S(int); }; S::S(const S& = S(0), int = 0) {}
^
1 error generated.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #12 from Jonathan Wakely --- Both. It's been low priority because I noticed it by observation, but it's never been reported by users or caused any problems that I'm aware of (until now, maybe).
[Bug c++/86579] New: invalid operands to binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86579
Bug ID: 86579
Summary: invalid operands to binary expression
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
template
bool greater()
{
T p = nullptr;
return p > nullptr;
}
int main ()
{
greater();
}
g++ accepts it, but clang++ reports a error message:
code0.cpp:5:11: error: invalid operands to binary expression ('void *' and
'nullptr_t')
return p > nullptr;
~ ^ ~~~
code0.cpp:10:2: note: in instantiation of function template specialization
'greater' requested here
greater();
^
1 error generated.
[Bug c++/86578] New: requested alignment is dependent but declaration is not dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86578
Bug ID: 86578
Summary: requested alignment is dependent but declaration is
not dependent
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
template void Fun(T A) {
typedef int __attribute__((__aligned__(A))) T1;
int k1[__alignof__(T1)];
}
g++ accepts it, but clang++ rejects it:
code0.cpp:2:29: error: requested alignment is dependent but declaration is not
dependent
typedef int __attribute__((__aligned__(A))) T1;
^ ~
1 error generated.
[Bug c++/86577] New: non-ADL name lookup for operator<< at instantiation time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86577
Bug ID: 86577
Summary: non-ADL name lookup for operator<< at instantiation
time?
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhonghao at pku dot org.cn
Target Milestone: ---
The code is as follow:
#include
namespace N {
struct X { };
}
using namespace N;
template
void log(const T& t) {
std::clog << t;
}
std::ostream &operator<<(std::ostream&, const X& x);
template void log(const X&);
g++ accepts the code, but clang++ rejects it:
code0.cpp:10:12: error: call to function 'operator<<' that is neither visible
in the template definition nor found by argument-dependent lookup
std::clog << t;
^
code0.cpp:15:16: note: in instantiation of function template specialization
'log' requested here
template void log(const X&);
^
code0.cpp:13:16: note: 'operator<<' should be declared prior to the call site
or in namespace 'N'
std::ostream &operator<<(std::ostream&, const X& x);
^
1 error generated.
Does g++ perform non-ADL name lookup for operator<< at instantiation time? This
sounds incorrect.
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Carl Love --- Issue resolved, closing.
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 Carl Love changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Carl Love --- Patches to fix test cases committed to mainline and GCC 8.
[Bug target/86414] AIX generates wrong for divide and multiply for KC mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414 --- Comment #2 from Carl Love --- Author: carll Date: Wed Jul 18 22:12:20 2018 New Revision: 262865 URL: https://gcc.gnu.org/viewcvs?rev=262865&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2018-07-18 Carl Love Backport from mainline 2018-07-16 Carl Love PR target/86414 * gcc.target/powerpc/divkc3-2.c: Add dg-require-effective-target longdouble128. * gcc.target/powerpc/divkc3-3.c: Ditto. * gcc.target/powerpc/mulkc3-2.c: Ditto. * gcc.target/powerpc/mulkc3-3.c: Ditto. * gcc.target/powerpc/fold-vec-mergehl-double.c: Update counts. * gcc.target/powerpc/pr85456.c: Make check Linux and AIX specific. Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/divkc3-2.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/divkc3-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/fold-vec-mergehl-double.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/mulkc3-2.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/mulkc3-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr85456.c
[Bug tree-optimization/86544] Popcount detection generates different code on C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544 --- Comment #4 from kugan at gcc dot gnu.org --- Author: kugan Date: Wed Jul 18 22:11:24 2018 New Revision: 262864 URL: https://gcc.gnu.org/viewcvs?rev=262864&root=gcc&view=rev Log: gcc/ChangeLog: 2018-07-18 Kugan Vivekanandarajah PR middle-end/86544 * tree-ssa-phiopt.c (cond_removal_in_popcount_pattern): Handle comparision with EQ_EXPR in last stmt. gcc/testsuite/ChangeLog: 2018-07-18 Kugan Vivekanandarajah PR middle-end/86544 * g++.dg/tree-ssa/pr86544.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr86544.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug fortran/86576] New: [F03][OOP] Sourced allocation of object array fails with SEGFAULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86576 Bug ID: 86576 Summary: [F03][OOP] Sourced allocation of object array fails with SEGFAULT Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: c...@mnet-mail.de Target Milestone: --- The following Fortran 2003 test code, that makes extensive use of sourced allocation, should build and allocate an array of objects, and then simply terminate gracefully. It indeed does so when compiled with flang 6.0, pgfortran 18.4, and ifort 19 Beta. However, it leads to a segmentation fault when compiled with gfortran, as follows: $ cat test.F90 module build implicit none private public :: Builder, Otype type :: Ftype procedure(proc), pointer :: ptr => null() end type Ftype abstract interface subroutine proc( self,arr1,arr2 ) import :: Ftype class(Ftype), intent(in) :: self real(8), dimension(:,:), intent(in) :: arr1 real(8), dimension(:,:), intent(out) :: arr2 end subroutine proc end interface type :: Gtype type(Ftype) :: ff end type Gtype type :: Otype class(Gtype), allocatable :: og end type Otype type :: Builder class(Otype), dimension(:), allocatable :: outarr contains procedure :: init procedure :: get_result end type Builder interface Builder procedure constructor end interface Builder contains function constructor( nd ) ! ! Constructor for Builder objects. ! type(Builder) :: constructor integer(4), intent(in) :: nd call constructor%init( nd ) end function constructor subroutine init( self,nd ) ! ! Initializes the Builder. Constructs an array of output objects. ! class(Builder), intent(inout) :: self integer(4), intent(in) :: nd integer(4) :: i class(Ftype), allocatable :: ff ! allocate space for output array allocate( self%outarr(nd) ) ! fill it with some values allocate( ff, source = Ftype() ) do i = 1, nd allocate( self%outarr(i)%og, source = Gtype( ff ) ) end do end subroutine init function get_result( self ) result( outarr ) ! ! Returns a copy of the array of output objects. ! class(Builder), intent(in) :: self class(Otype), dimension(:), allocatable :: outarr allocate( outarr, source = self%outarr ) end function get_result end module build program test use build, only: Builder, Otype implicit none integer(4), parameter :: nd = 2 class(Builder), allocatable :: bld class(Otype), dimension(:), allocatable :: outarr ! get a builder object allocate( bld, source = Builder(nd) ) ! return a copy of the array of output objects allocate( outarr, source = bld%get_result() ) end program test $ gfortran-8 test.F90 -o test; ./test Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x2b08a615441a #1 0x2b08a6153603 #2 0x2b08a65e74af #3 0x40224f #4 0x402438 #5 0x2b08a65d282f #6 0x400768 #7 0x Segmentation fault Gfortran version output is: $ gfortran-8 -v Using built-in specs. COLLECT_GCC=gfortran-8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.1.0-5ubuntu1~16.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.1.0 (Ubuntu 8.1.0-5ubuntu1~16.04)
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 --- Comment #10 from janus at gcc dot gnu.org --- (In reply to janus from comment #9) > As noted already somewhere in the discussion of PR85599 on the mailing list, > this breaks actual_pointer_function_1.f90 in the testsuite ... but apart from that the patch in comment #9 regtests cleanly.
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #15 from Jonny Grant --- Hi Richard I cannot reproduce DWARF errors without undefined references (by removing the implementation of a function). It is taking me a long time to reduce and still keep the error Which has different numbers /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Could not find abbrev number 2082833. Is a test case useful for this spurious error?
[Bug c++/86550] Lambda parsing allows arbitrary types in decl-specifier-seq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86550 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Jul 18 21:01:54 2018 New Revision: 262862 URL: https://gcc.gnu.org/viewcvs?rev=262862&root=gcc&view=rev Log: PR c++/86550 * parser.c (cp_parser_decl_specifier_seq): Diagnose invalid type specifier if CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR. * g++.dg/cpp0x/lambda/lambda-86550.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-86550.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57160] short-circuit IF only with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #9 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #6) > The problem there is what we should consider for a warning. I think getting the warnings right for all possible cases is pretty tough. OTOH, following Joost's original suggestion to do short-circuiting only with -ffrontend-optimize is almost trivial, so I'd vote to go with that. Here's the patch: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(revision 262859) +++ gcc/fortran/trans-expr.c(working copy) @@ -3348,12 +3348,18 @@ gfc_conv_expr_op (gfc_se * se, gfc_expr * expr) return; case INTRINSIC_AND: - code = TRUTH_ANDIF_EXPR; + if (flag_frontend_optimize) + code = TRUTH_ANDIF_EXPR; + else + code = TRUTH_AND_EXPR; lop = 1; break; case INTRINSIC_OR: - code = TRUTH_ORIF_EXPR; + if (flag_frontend_optimize) + code = TRUTH_ORIF_EXPR; + else + code = TRUTH_OR_EXPR; lop = 1; break; As noted already somewhere in the discussion of PR85599 on the mailing list, this breaks actual_pointer_function_1.f90 in the testsuite, which is very similar to comment 0 (and apparently also contributed by Joost). Both are invalid code. The former is fixed by: Index: gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 === --- gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 (revision 262859) +++ gcc/testsuite/gfortran.dg/actual_pointer_function_1.f90 (working copy) @@ -17,7 +17,11 @@ CONTAINS logical function cp_logger_log(logger) TYPE(cp_logger_type), POINTER ::logger -cp_logger_log = associated (logger) .and. (logger%a .eq. 42) +if (associated (logger)) then + cp_logger_log = (logger%a .eq. 42) +else + cp_logger_log = .false. +end if END function FUNCTION cp_get_default_logger(v) RESULT(res)
[Bug fortran/85599] warn about short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #38 from janus at gcc dot gnu.org --- Fixed on 9-trunk with r262860. Closing. (The related PR57160 is still open.)
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #11 from Ian Lance Taylor --- Sorry, you're right, it's -fdump-go-spec.
[Bug c++/86574] ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-07-18 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- fatal error: range/v3/view/transform.hpp: No such file or directory Please provide a preprocessed source file so that we can reproduce.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #10 from Curtis Hamilton --- Is it -fgo-dump-spec or -fdump-go-spec? Below is an extract of my build log: checking for hypotf... /usr/ports/lang/gcc7/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc7/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd11.2/bin/ -B/usr/local/powerpc64-portbld-freebsd11.2/lib/ -isystem /usr/local/powerpc64-portbld-freebsd11.2/include -isystem /usr/local/powerpc64-portbld-freebsd11.2/sys-include-DHAVE_CONFIG_H -I. -I/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo -I /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/runtime -I/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/../libffi/include -I../libffi/include -pthread -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -fdump-go-spec=tmp-gen-sysinfo.go -std=gnu99 -S -o sysinfo.s /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/sysinfo.c yes checking for hypot... rm -f sysinfo.s /bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mvifdiff.sh tmp-gen-sysinfo.go gen-sysinfo.go echo timestamp > s-gen-sysinfo rm -f libcalls.go.tmp /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/../install-sh -c -d runtime/internal; dir=`echo runtime/internal/sys.lo.dep | sed -e 's/.lo.dep$//'`; files=`/bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/match.sh --goarch=ppc64 --goos=freebsd --srcdir=/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/$dir --extrafiles="version.go" `; /bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/godeps.sh `echo runtime/internal/sys.lo.dep | sed -e 's/.dep$//'` $files > runtime/internal/sys.lo.dep.tmp; if ! cmp runtime/internal/sys.lo.dep.tmp runtime/internal/sys.lo.dep >/dev/null 2>/dev/null; then rm -f `echo runtime/internal/sys.lo.dep | sed -e 's/\.dep$//'`; fi; mv -f runtime/internal/sys.lo.dep.tmp runtime/internal/sys.lo.dep /usr/bin/awk -f /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/syscall/mksyscall.awk `cat libcalls-list` > libcalls.go.tmp /bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mksysinfo.sh /bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mvifdiff.sh libcalls.go.tmp libcalls.go echo timestamp > s-libcalls /bin/sh /usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/mkrsysinfo.sh
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #11 from The Written Word --- (In reply to Jonathan Wakely from comment #7) > As I suspected, something is doing: > > #define fabsl(X) fabs((double) (X)) > #define acosl(X) acos((double) (X)) > etc. > > This would probably be solved by any fix for PR 79700, which would have to > add this to : > > #undef fabsl > > But I'm not sure when PR 79700 will get fixed. Is it just a matter of someone finding the time to fix 79700 or is it just too low a priority?
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #9 from Ian Lance Taylor --- I haven't tried to recreate the problem on FreeBSD. I've just tried various inputs to GCC 7 -fgo-dump-spec.
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #9 from Alexander Monakov --- One more: -Wimplicit-fallthrough issue uncovered by the testsuite: PR 86575. So far all issues appeared in gcc-6 or more recent.
[Bug c/69558] [6/7/8/9 Regression] glib2 warning pragmas stopped working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558 --- Comment #25 from Bernd Edlinger --- Author: edlinger Date: Wed Jul 18 19:36:01 2018 New Revision: 262861 URL: https://gcc.gnu.org/viewcvs?rev=262861&root=gcc&view=rev Log: libcpp: 2018-07-18 Bernd Edlinger PR 69558 * macro.c (enter_macro_context): Change the location info for builtin macros and _Pragma from location of the closing parenthesis to location of the macro expansion point. testsuite: 2018-07-18 Bernd Edlinger PR 69558 * c-c++-common/cpp/diagnostic-pragma-2.c: New test. * c-c++-common/pr69558.c: Remove xfail. * gcc.dg/cpp/builtin-macro-1.c: Adjust test expectations. * gcc.dg/pr61817-1.c: Likewise. * gcc.dg/pr61817-2.c: Likewise. * g++.dg/plugin/pragma_plugin.c: Warn at expansion_point_location. Added: trunk/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr69558.c trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c trunk/gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c trunk/gcc/testsuite/gcc.dg/pr61817-1.c trunk/gcc/testsuite/gcc.dg/pr61817-2.c trunk/libcpp/ChangeLog trunk/libcpp/macro.c
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #8 from Curtis Hamilton --- Based on you last comment, I attempted a build using FreeBSD 11.2 RC1 on the same hardware (PowerMac G5 Quad) and got the same results. Are you using native hardware or emulation?
[Bug tree-optimization/86570] Conditional statement doesn't trigger sincos transform (with -ffast-math)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86570 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-18 Summary|Conditional statement |Conditional statement |doesn't trigger sincos |doesn't trigger sincos |transform |transform (with ||-ffast-math) Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- -0.0 == 0.0 so definitely -ffast-math is required. Basically many floating point replacement like this is not done.
[Bug tree-optimization/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED Component|c++ |tree-optimization Version|tree-ssa|7.0 Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Using f instead of main allows it be optimized so closing as invalid. NOTE GCC has a heuristic around main function being done as ever called once so it does less inlining into it.
[Bug middle-end/86575] New: -Wimplicit-fallthrough affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
Bug ID: 86575
Summary: -Wimplicit-fallthrough affects code generation
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
void
f2 (int a, int b, int c, int d)
{
switch (b)
{
default:
for (int e = 0; e < c; ++e)
if (e == d)
break;
}
}
ICEs as both C and C++ using 'gcc -fcompare-debug=-Wimplicit-fallthrough'. This
is minimized from pr81275-1.C in the testsuite (the -2 and -3 variants of the
original test also fail).
[Bug c++/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #2 from Marc Glisse --- When passing by copy, gcc seems to manage with default flags, but your -std=c++2a -fno-exceptions hinder it somehow.
[Bug c++/86574] New: ICE on std::prev with ranges::view::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574
Bug ID: 86574
Summary: ICE on std::prev with ranges::view::transform
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tower120 at gmail dot com
Target Milestone: ---
The following code cause ICE on gcc 9. And have malfunction build on all
previous versions (program compiles, but hangs); clang compiles with error
about bidirectional iterator.
https://wandbox.org/permlink/bPT0llOGPqouv3CM
#include
#include
#include
struct Data{
int x,y;
};
int main() {
std::vector datas = { Data{0,1}, Data{1,2}, Data{1,3} };
const auto xs = datas
| ranges::view::transform([](const Data& data) -> int{
return data.x; });
// no compiler errors / ICEs, but assembled executable - malfunction -
// program hungs, as soon as reach std::prev
//auto j = std::prev(xs.end());
auto j = std::prev(xs.end(), 1);
std::cout << "Done" << std::endl;
return 0;
}
Error message:
In file included from
/opt/wandbox/range-v3/include/range/v3/view/transform.hpp:26,
from prog.cc:3:
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp: In instantiation of
'constexpr ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor
>::adaptor_cursor(Args&& ...) [with Args = {__gnu_cxx::__normal_iterator > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor};
typename
meta::v1::detail::_if_::type::value ...>, std::integer_sequence::type::value) || true ...> >, int>,
std::integral_constant >::type = 0][inherited from
ranges::v3::compressed_tuple_detail::compressed_tuple_ > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >,
std::integer_sequence >]':
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp:183:16: required from
'constexpr ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor
>::adaptor_cursor(Args&& ...) [with Args = {__gnu_cxx::__normal_iterator > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor};
typename
meta::v1::detail::_if_::type::value ...>, std::integer_sequence::type::value) || true ...> >, int>,
std::integral_constant >::type = 0][inherited from
ranges::v3::compressed_tuple_detail::compressed_tuple_ > >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >,
std::integer_sequence >]'
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp:405:63: required from
'static constexpr ranges::v3::adaptor_cursor_t
ranges::v3::view_adaptor::begin_cursor_(D&) [with D =
const
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; Derived =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; BaseRng =
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >;
ranges::v3::cardinality Cardinality = (ranges::v3::cardinality)-1;
ranges::v3::adaptor_cursor_t =
ranges::v3::adaptor_cursor<__gnu_cxx::__normal_iterator >,
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor >;
typename std::decay(), 42))>::type =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >::adaptor;
typename std::decay(),
42))>::type>().begin(declval()))>::type =
__gnu_cxx::__normal_iterator >]'
/opt/wandbox/range-v3/include/range/v3/view_adaptor.hpp:423:13: required by
substitution of 'template > >, __gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::models > >, __gnu_cxx::__normal_iterator > > > >())), void>::type* >
constexpr decltype
(ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >,
(ranges::v3::cardinality)-1>::begin_cursor_(declval()))
ranges::v3::view_adaptor >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >,
ranges::v3::iterator_range<__gnu_cxx::__normal_iterator >, __gnu_cxx::__normal_iterator > >,
(ranges::v3::cardinality)-1>::begin_cursor >() const [with D =
ranges::v3::iter_transform_view >, __gnu_cxx::__normal_iterator > >,
ranges::v3::indirected > >; bool
_concept_requires_421 = false; typename std::enable_if<(_concept_requires_421
|| (typename ranges::v3::concepts::Same::same > >, __gnu_cxx::__normal_iterator > > >,
ranges::v3::indirected > > >::type() &&
ranges::v3::concepts::model
[Bug c++/86573] Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573 --- Comment #1 from Marc Glisse --- Try renaming 'main' to any other name and gcc does optimize...
[Bug bootstrap/81397] mistakes in .opt files not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81397 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Martin Liška from comment #1) > You are right, various checking can be done with option handling. Let me > take it, can be subject for GCC 9. Changing status to ASSIGNED since you put yourself as the assignee
[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532 --- Comment #28 from Bernd Edlinger --- Yes, agreed. Should I send a patch to take out the statement in comment #17, or will you do that in your follow-up patch?
[Bug c++/86573] New: Failure to optimise passing simple values to inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
Bug ID: 86573
Summary: Failure to optimise passing simple values to inlined
function
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s_gccbugzilla at nedprod dot com
Target Milestone: ---
#include
inline size_t calc(std::string a, std::string b)
{
return a.size() + b.size();
}
int main()
{
std::string a = "Hello world", b = "Goodbye world";
return calc(std::move(a), std::move(b));
}
This should generate:
main: # @main
mov eax, 24
ret
Like clang does. See https://godbolt.org/g/EAggKH.
But it instead generates this spew with gcc trunk:
https://godbolt.org/g/3LmfTc
Also it should generate the above return of 24 if passing by value. clang
currently fails that, I have reported a bug to them about it.
[Bug c++/86569] -Wnonnull-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-18
CC||msebor at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=86567
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed. See also bug 86567.
$ cat t.C && gcc -S -fcompare-debug=-Wnonnull-compare t.C
bool b;
int main ()
{
return ((!b) != 0);
}
xg++: error: t.C: -fcompare-debug failure (length)
[Bug tree-optimization/86571] AIX NaNQ and NaNS output format conflicts with __builtin_sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- The test below fails because of this discrepancy: FAIL: gcc.dg/torture/builtin-sprintf.c -O0 execution test GCC should relax the upper bound on the amount of output for NaN. The standard specifies two forms of output "nan" or "nan(n-char-sequence)" The latter doesn't seem to be output by any known implementations (plus the length of the n-char-sequence is unspecified, making it useless for portability) and there have been voices to deprecate or remove it from the C standard. I plan to propose one of the two for C2X. Until then, bumping up the upper bound either for all targets, or just for AIX (under some sort of a target hook) is probably the best solution.
[Bug fortran/85599] warn about short-circuiting of logical expressions for non-pure functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599 --- Comment #37 from janus at gcc dot gnu.org --- Author: janus Date: Wed Jul 18 18:31:59 2018 New Revision: 262860 URL: https://gcc.gnu.org/viewcvs?rev=262860&root=gcc&view=rev Log: 2018-07-18 Janus Weil Thomas Koenig PR fortran/85599 * dump-parse-tree.c (show_attr): Add handling of implicit_pure. * frontend-passes.c (do_warn_function_elimination): Do not warn for pure functions. * gfortran.h: Add prototypes for gfc_pure_function and gfc_implicit_pure_function. * gfortran.texi: Add chapter on evaluation of logical expressions. * invoke.texi: Mention that -Wfunction-elimination is implied by -Wextra. * lang.opt: Make -Wextra imply -Wfunction-elimination. * resolve.c (pure_function): Rename to gfc_pure_function. (gfc_implicit_pure_function): New function. (check_pure_function): Use it here. (impure_function_callback): New function. (resolve_operator): Call it via gfc_expr_walker. 2018-07-18 Janus Weil PR fortran/85599 * gfortran.dg/function_optimize_5.f90: Add option '-faggressive-function-elimination' and update dg-warning clauses. * gfortran.dg/short_circuiting.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/short_circuiting.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/function_optimize_5.f90
[Bug tree-optimization/86532] [9 Regression] Wrong code due to a wrong strlen folding starting with r262522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532 --- Comment #27 from Martin Sebor --- I don't think it would be appropriate to introduce dependencies on the sanitizer for the same reason we can't do that for warnings. But as I mentioned in comment 16, I think performing these sorts of simplifications this early (this one it happens during parsing) prevents subsequent analysis from making use of the information that can be derived from in the original code. Deferring this non-constant folding until later (see bug 86434) would make it possible not only to detect some of these bugs but also transform them into traps/unreachable without any runtime overhead (when we know the non-constant offset's range is out-of-bounds). I did the comparison in signed because that's what the function returns but I do agree that folding to zero rather than arbitrary value. I opened bug 86572 for this idea. Let me propose making the change separately (here I just want to fix the wrong code without preventing existing optimizations). I would also be open to emitting __builtin_unreachable(). The chartype loop needs to change to avoid assuming the element type is necessarily an integer type. I can reproduce the problem on my local machine but I don't know why the full regression test run that I run on my team's server didn't expose this or the previous ICE. I'll look into it. I very much appreciate your testing and feedback. I would just ask you to comment on the patch on the list so we don't clutter with details that are not important to the record of the bug.
[Bug c++/86469] Dwarf Error: Offset (1678049557) greater than or equal to .debug_str size (5846).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469 --- Comment #14 from Jonny Grant --- Hello Richard My archive of the original problem didn't show it. But when I tried to re-create I got the following. I'll try also make a small test case for this one while I have it. /usr/bin/x86_64-linux-gnu-ld: Dwarf Error: Could not find abbrev number 120.
[Bug tree-optimization/86572] unsafe strlen folding of const arguments with non-const offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86572
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=86434
--- Comment #1 from Martin Sebor ---
See also bug 86434 which discusses another couple of problems with this
transformation. The solution in this case isn't necessarily to defer the
folding until later but do it in a way that avoids these excessive results for
undefined input. For example, returning zero would be safer and in line with
what GCC does in other cases, such as in some instances of out-of-bounds array
accesses:
$ cat c.c && gcc -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout c.c
const char a[4] = { 1, 2, 3 };
int f (void)
{
return a[8]; // missing -Warray-bounds, folded to zero
}
;; Function f (f, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1)
f ()
{
[local count: 1073741825]:
return 0;
}
[Bug tree-optimization/86572] New: unsafe strlen folding of const arguments with non-const offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86572
Bug ID: 86572
Summary: unsafe strlen folding of const arguments with
non-const offset
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: ---
This came up in a conversation of a change in this area (bug 86532). The
following test case has undefined behavior so anything can happen, but the
result in GCC is unnecessarily and arbitrarily "hostile" in that the value
computed by the strlen expression is excessive large, so large in fact as to be
meaningless (no object can be as large as 18446744073709551615 or SIZE_MAX
bytes).
$ cat c.c && gcc -Wall -fdump-tree-gimple=/dev/stdout c.c && ./a.out
const char a[] = "123";
__attribute__ ((noipa))
__SIZE_TYPE__ f (int i)
{
return __builtin_strlen (a + i);
}
int main (void)
{
__SIZE_TYPE__ n = f (4);
__builtin_printf ("%zu\n", n);
}
__attribute__((noipa, noinline, noclone, no_icf))
f (int i)
{
long unsigned int D.1964;
_1 = (ssizetype) i;
_2 = 3 - _1; // strlen folded into this
D.1964 = (long unsigned int) _2;
return D.1964;
}
main ()
{
int D.1966;
{
long unsigned int n;
n = f (4);
__builtin_printf ("%zu\n", n);
}
D.1966 = 0;
return D.1966;
}
18446744073709551615
[Bug tree-optimization/86571] AIX NaNQ and NaNS output format conflicts with __builtin_sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-18 Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug tree-optimization/86571] New: AIX NaNQ and NaNS output format conflicts with __builtin_sprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571 Bug ID: 86571 Summary: AIX NaNQ and NaNS output format conflicts with __builtin_sprintf Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* AIX sprintf generates NaNQ and NaNS, probably as extensions defined by IBM XL Fortran. The recent __builtin_sprintf optimization assumes a 3 character output of "nan" or "NAN". NAN(S) and NAN(Q) optionally may be allowed. IBM libc is unlikely to change because customers depend on the current extension.
[Bug tree-optimization/86570] New: Conditional statement doesn't trigger sincos transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86570
Bug ID: 86570
Summary: Conditional statement doesn't trigger sincos transform
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
For the following test-case:
double f2(double x, double a, double b)
{
if (a == b)
return __builtin_sin (a * x) + __builtin_cos (b * x);
return 0;
}
Optimized dump with -O2 -ffast-math -funsafe-math-optimizations yields:
f2 (double x, double a, double b)
{
double _1;
double _2;
double _3;
double _4;
double _5;
double _9;
[local count: 1073741825]:
if (a_6(D) == b_7(D))
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 365072220]:
_1 = a_6(D) * x_8(D);
_2 = __builtin_sin (_1);
_3 = b_7(D) * x_8(D);
_4 = __builtin_cos (_3);
_9 = _2 + _4;
[local count: 1073741825]:
# _5 = PHI <_9(3), 0.0(2)>
return _5;
}
I assume the sincos transform would have been valid in the above case ?
Similarly missed for the divmod transform.
Thanks,
Prathamesh
[Bug middle-end/85602] -Wsizeof-pointer-memaccess for strncat with size of source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602 --- Comment #14 from Martin Sebor --- Author: msebor Date: Wed Jul 18 17:20:05 2018 New Revision: 262859 URL: https://gcc.gnu.org/viewcvs?rev=262859&root=gcc&view=rev Log: Backport from trunk. PR middle-end/85602 - -Wsizeof-pointer-memaccess for strncat with size of source gcc/c-family/ChangeLog: PR middle-end/85602 * c-warn.c (sizeof_pointer_memaccess_warning): Check for attribute nonstring. gcc/ChangeLog: PR middle-end/85602 * calls.c (maybe_warn_nonstring_arg): Handle strncat. * tree-ssa-strlen.c (is_strlen_related_p): Make extern. Handle integer subtraction. (maybe_diag_stxncpy_trunc): Handle nonstring source arguments. * tree-ssa-strlen.h (is_strlen_related_p): Declare. * doc/invoke.texi (-Wstringop-truncation): Update. gcc/testsuite/ChangeLog: PR middle-end/85602 * gcc.dg/attr-nonstring-2.c: Adjust text of expected warning. * c-c++-common/attr-nonstring-8.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/c-c++-common/attr-nonstring-8.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/c-family/ChangeLog branches/gcc-8-branch/gcc/c-family/c-warn.c branches/gcc-8-branch/gcc/calls.c branches/gcc-8-branch/gcc/doc/invoke.texi branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-strlen.c branches/gcc-8-branch/gcc/tree-ssa-strlen.h
[Bug fortran/86566] The preprocessor cpp6 loses line concatenation on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86566 --- Comment #3 from kargl at gcc dot gnu.org --- The proper way to preprocess Fortran code is with the Fortran compiler. You can and should use 'gfortran -cpp'. See the documentation that comes with your compiler. If you think you need to use gcc, then you must use the --tradition-cpp option. The Fortran concatenation operator // conflicts with modern C's comment delimiter //.
[Bug target/86555] unaligned address for ldrd/strd on armv5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #5 from Rich Felker --- Indeed this is a bug in musl, not gcc. The alignment requirement of the type is 8 so the compiler is completely justified in generating loads and stores that require such alignment. I'll fix it on our side.
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #8 from Alexander Monakov --- Other files seem to miscompare due to -Wnonnull-compare: PR 86569.
[Bug c++/86569] New: -Wnonnull-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569
Bug ID: 86569
Summary: -Wnonnull-compare affects code generation
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
bool b;
int main ()
{
return ((!b) != 0);
}
ICEs with g++ -fcompare-debug=-Wnonnull-compare (this is bool6.C in the
testsuite). It looks as if the warning prevents folding '!b != 0' to '!b'.
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #10 from Paolo Carlini --- Fixed.
[Bug libstdc++/86450] Bootstrap failure due to -Wabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450 --- Comment #26 from Jonathan Wakely --- No, I needed far more than that. Obviously I needed the right versions of autoconf and automake first in my PATH, which is simple. But I also needed to use contrib/gcc_update to fix all the timestamps, so that there weren't loads of errors caused by reconf'ing files in libbacktrace, zlib and lto-plugin. contrib/gcc_update prevented those, but that means a simple "svn up" or "git pull" doesn't work when using maintainer mode, and the script can't be used if you have any uncommitted changes in a git tree. After solving those issues I got a load of errors from libtool macros: configure.ac:40: warning: macro `AM_PROG_LIBTOOL' not found in library I have no idea what that's caused by. Obviously I have libtool installed (in /usr/bin and I also tried a symlink to it in /opt/autotools-gcc/bin where I have the old versions of autoconf and automake). I'm not aware of any dependency on a specific libtool version.
[Bug c++/86568] New: -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
Bug ID: 86568
Summary: -Wnonnull warnings should highlight the relevant
argument not the closing parenthesis
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
void f(void*, void*) __attribute__((nonnull(2)));
struct A {
void f(void*, void*) __attribute__((nonnull(2)));
};
int main()
{
f(0, 0);
A().f(0, 0);
}
nonnull.cc: In function 'int main()':
nonnull.cc:9:9: warning: null argument where non-null required (argument 2)
[-Wnonnull]
f(0, 0);
^
nonnull.cc:10:13: warning: null argument where non-null required (argument 2)
[-Wnonnull]
A().f(0, 0);
^
The location of the caret diagnostic is not helpful. It's especially confusing
for member functions where the argument number includes the implicit 'this'
parameter.
Expected result:
nonnull.cc: In function 'int main()':
nonnull.cc:9:9: warning: null argument where non-null required (argument 2)
[-Wnonnull]
f(0, 0);
^
nonnull.cc:10:13: warning: null argument where non-null required (argument 2)
[-Wnonnull]
A().f(0, 0);
^
[Bug target/86555] unaligned address for ldrd/strd on armv5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555 --- Comment #4 from Ramana Radhakrishnan --- (In reply to Khem Raj from comment #2) > we can avoid the problem by altering the structure, thats not an issue, but > do you think compiler is right here by assuming to generate LDRD on a 4byte > aligned address when it is told that architecture (-march=armv5te) its > building for does not support 4byte aligned address for LDRD but only 8-byte > aligned ? It is correct for the compiler to be doing this - the compiler has just not been given enough information. buf can only get aligned to 8 bytes if there is an input attribute setting the alignment properly otherwise it's a char array and the compiler is within it's rights not to have to force align upwards to 8 bytes in this case. When the compiler is derefencing de->d_off it expects it to be naturally 8 byte aligned. Fix the source.
[Bug target/86555] unaligned address for ldrd/strd on armv5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #3 from Bernd Edlinger --- (In reply to Khem Raj from comment #2) > we can avoid the problem by altering the structure, thats not an issue, but > do you think compiler is right here by assuming to generate LDRD on a 4byte > aligned address when it is told that architecture (-march=armv5te) its > building for does not support 4byte aligned address for LDRD but only 8-byte > aligned ? the structure has to be aligned by 8 bytes. (due to the long long member) Therefore the compiler assumes that the DIR->lock is also aligned by 8 bytes. I do not see why lock[2] vs. lock[1] makes a difference. If you cannot make it aligned, you need to mark the structure with __attribute__((__packed__)) for instance.
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #7 from Alexander Monakov --- cp/mangle.o miscompares due to -Wsign-compare, possibly due to caching in maybe_constant_value as in the above PR.
[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-07-18
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor ---
Confirmed (both the error and that maybe_constant_value has a cache).
$ cat t.C && gcc -S -fcompare-debug=-Wrestrict t.C
#include
std::vector
f()
{
std::vector r;
return r;
}
xg++: error: t.C: -fcompare-debug failure
[Bug target/86555] unaligned address for ldrd/strd on armv5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555 --- Comment #2 from Khem Raj --- we can avoid the problem by altering the structure, thats not an issue, but do you think compiler is right here by assuming to generate LDRD on a 4byte aligned address when it is told that architecture (-march=armv5te) its building for does not support 4byte aligned address for LDRD but only 8-byte aligned ?
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #9 from The Written Word --- (In reply to David Edelsohn from comment #7) > I use GCC 4.6 to bootstrap. It appears that the error is caused by the > "system" bootstrap compiler, which I think is GCC 4.4 in your case. It is > generating code with too large displacements. > > Also, some of the configure options are unusual. Ok, will try something later than 4.4. Thanks.
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #8 from The Written Word --- (In reply to The Written Word from comment #6) > gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build > gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c > successfully. gcc-6.4.0 just died somewhere else with the same error: g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasync hronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing -format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-ma cros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/opt/build/c hina/gcc-6.4.0/gcc -I/opt/build/china/gcc-6.4.0/gcc/. -I/opt/build/china/gcc-6.4 .0/gcc/../include -I./../intl -I/opt/build/china/gcc-6.4.0/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfsw/libmpfr31/include -I/opt/TWWfsw/li bmpc10/include -I/opt/build/china/gcc-6.4.0/gcc/../libdecnumber -I/opt/build/ch ina/gcc-6.4.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/build/china/gcc-6 .4.0/gcc/../libbacktrace -I/opt/TWWfsw/libisl016/include -o rs6000.o -MT rs6000 .o -MMD -MP -MF ./.deps/rs6000.TPo /opt/build/china/gcc-6.4.0/gcc/config/rs6000/ rs6000.c /tmp//ccsn8s2Z.s: Assembler messages: /tmp//ccsn8s2Z.s:177152: Error: value of 0001 too large for field of 2 bytes at 0007e722 /tmp//ccsn8s2Z.s:177680: Error: value of 00010004 too large for field of 2 bytes at 0007ed12 /tmp//ccsn8s2Z.s:178850: Error: value of 00010008 too large for field of 2 bytes at 0007fb5e /tmp//ccsn8s2Z.s:179521: Error: value of 0001000c too large for field of 2 bytes at 00080246 ...
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #7 from David Edelsohn --- I use GCC 4.6 to bootstrap. It appears that the error is caused by the "system" bootstrap compiler, which I think is GCC 4.4 in your case. It is generating code with too large displacements. Also, some of the configure options are unusual.
[Bug c++/86562] Missing warning (error in C++11) for passing nontrivial object to varargs function via function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86562 Jonathan Wakely changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #3 from Jonathan Wakely --- I disagree. This report states "g++ accepts it, but clang++ rejects it" and that is not a bug, it's a feature. If a diagnostic is desired it can be requested with -Wconditionally-supported or -Werror-conditionally-supported 64867 says "It would be nice to have a distinct warning flag for this feature" which is different. This bug is invalid.
[Bug c++/64867] warning for passing non-POD to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 Eric Gallager changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #24 from Eric Gallager --- *** Bug 86562 has been marked as a duplicate of this bug. ***
[Bug c++/86562] Missing warning (error in C++11) for passing nontrivial object to varargs function via function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86562 Eric Gallager changed: What|Removed |Added Keywords||diagnostic CC||egallager at gcc dot gnu.org Resolution|INVALID |DUPLICATE --- Comment #2 from Eric Gallager --- I think this is actually a dup of bug 64867 *** This bug has been marked as a duplicate of bug 64867 ***
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #6 from The Written Word --- (In reply to David Edelsohn from comment #5) > GCC 4.9 is quite old now and out of service. If there is a bug in GCC 4.9, > it will not be fixed because there are no bug fix releases planned. Understood. > You never showed an example of the assembly line representing the error > message to allow someone to observe the exact assembly instruction and > operands in question. I've attached insn-output.s. Looks like the problematic lines are of the form: bl ._Z17gen_rtx_CONST_INT12machine_modex nop mr 0,3 stw 0,0(28) .line 3466 lwz 0,LC..1(2) <-- line 1361 .eb 3466 .line 3468 mr 3,0 addi 1,31,96 ... bl ._Z17gen_rtx_CONST_INT12machine_modex nop mr 0,3 stw 0,0(28) .line 14 lwz 0,LC..2(2) <-- line 1495 .eb 14 .line 16 mr 3,0 addi 1,31,96 ... bl ._Z17gen_rtx_CONST_INT12machine_modex nop mr 0,3 stw 0,0(28) .line 14 lwz 0,LC..3(2) <-- line 1628 .eb 14 .line 16 mr 3,0 addi 1,31,96 gcc-5.5.0 and 7.2.0 errored out in the same way but I am able to build gcc-8.1.0 successfully. gcc-6.4.0 seems to have built insn-output.c successfully.
[Bug middle-end/86554] [7/8/9 Regression] Incorrect code generation with signed/unsigned comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554 --- Comment #6 from Bill Schmidt --- Anton has been able to work around the problem with a source change (this code is unnecessarily baroque anyway), so I don't think anybody is urgently awaiting a fix. If this will be fixed in your eventual rewrite of FRE, I think that's more than sufficient. Thanks!
[Bug c++/86480] [8/9 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86480 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #7 from Jason Merrill --- Fixed for 8.2/9.
[Bug c++/86480] [8/9 Regression] error: parameter packs not expanded with '...' in a recursive variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86480 --- Comment #6 from Jason Merrill --- Author: jason Date: Wed Jul 18 13:42:02 2018 New Revision: 262858 URL: https://gcc.gnu.org/viewcvs?rev=262858&root=gcc&view=rev Log: PR c++/86480 - nested variadic lambda and constexpr if. * pt.c (find_parameter_packs_r) [IF_STMT]: Don't walk into IF_STMT_EXTRA_ARGS. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/constexpr-if24.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #10 from The Written Word --- (In reply to Jonathan Wakely from comment #8) > Created attachment 44406 [details] > Undefine macros for long double math functions > > Does this fix the build? I am trying a similar patch. I basically #undef'd everything to get a clean build of that file and restarted the build from scratch so we'll see.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #9 from The Written Word --- (In reply to Jonathan Wakely from comment #7) > As I suspected, something is doing: > > #define fabsl(X) fabs((double) (X)) > #define acosl(X) acos((double) (X)) > etc. /usr/include/math.h on this platform has: #ifdef _ISOC99_SOURCE #ifdef __LONGDOUBLE128 ... #else ... #define acosl(__x) acos((double) (__x)) #define fabsl(__x) fabs((double) (__x)) ... #endif
[Bug c++/86190] [6/7/8 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190 Marek Polacek changed: What|Removed |Added Summary|[6/7/8/9 Regression]|[6/7/8 Regression] |-Wsign-conversion ignores |-Wsign-conversion ignores |explicit conversion in some |explicit conversion in some |cases |cases --- Comment #9 from Marek Polacek --- Fixed on trunk so far. Unsure about backporting (the fix is simple, but is it worth it? I guess).
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #8 from Jonathan Wakely --- Created attachment 44406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44406&action=edit Undefine macros for long double math functions Does this fix the build? This isn't really a proper fix, as it just allows the file to build. Code including will still see those macros and won't use the stubs defined in math_stubs_long_double.cc Maybe that's good enough though - I'm not sure precisely what the stubs are for.
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #5 from David Edelsohn --- GCC 4.9 is quite old now and out of service. If there is a bug in GCC 4.9, it will not be fixed because there are no bug fix releases planned. You never showed an example of the assembly line representing the error message to allow someone to observe the exact assembly instruction and operands in question. Maybe some other build tool corrupted the generated parameter. Or some bug in AIX C library corrupted the parameter. There are a huge number of possibilities.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #7 from Jonathan Wakely --- As I suspected, something is doing: #define fabsl(X) fabs((double) (X)) #define acosl(X) acos((double) (X)) etc. This would probably be solved by any fix for PR 79700, which would have to add this to : #undef fabsl But I'm not sure when PR 79700 will get fixed.
[Bug bootstrap/68663] Build failure on AIX 7.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663 --- Comment #4 from The Written Word --- (In reply to The Written Word from comment #3) > (In reply to David Edelsohn from comment #2) > > Group Bull, Perzl, and I have been able to build it. Are you using an up to > > date AIX Assembler? > > Hmm. Let me try upgrading. Thanks. I upgraded the system to the following: $ oslevel -s 7100-04-05-1720 $ lslpp -h bos.rte.bind_cmds Fileset Level Action Status Date Time Path: /usr/lib/objrepos bos.rte.bind_cmds 7.1.0.0 COMMIT COMPLETE 11/13/10 21:01:20 7.1.0.15 COMMIT COMPLETE 06/18/12 19:54:09 7.1.0.16 COMMIT COMPLETE 10/12/16 21:23:45 7.1.2.19 COMMIT COMPLETE 10/17/16 20:41:47 7.1.3.47 COMMIT COMPLETE 07/10/18 21:18:33 7.1.4.32 APPLYCOMPLETE 07/10/18 21:31:27 Path: /etc/objrepos bos.rte.bind_cmds 7.1.0.0 COMMIT COMPLETE 11/13/10 21:01:20 7.1.0.15 COMMIT COMPLETE 06/18/12 19:54:10 7.1.0.16 COMMIT COMPLETE 10/12/16 21:23:45 7.1.2.19 COMMIT COMPLETE 10/17/16 20:41:47 7.1.3.47 COMMIT COMPLETE 07/10/18 21:18:33 7.1.4.32 APPLYCOMPLETE 07/10/18 21:31:29 I built gcc-4.9.4 and I still get the error: g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables - W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -peda ntic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -D HAVE_CONFIG_H -I. -I. -I/opt/build/china/gcc-4.9.4/gcc -I/opt/build/china/gcc-4. 9.4/gcc/. -I/opt/build/china/gcc-4.9.4/gcc/../include -I./../intl -I/opt/build/c hina/gcc-4.9.4/gcc/../libcpp/include -I/opt/TWWfsw/libgmp61/include -I/opt/TWWfs w/libmpfr31/include -I/opt/TWWfsw/libmpc10/include -I/opt/build/china/gcc-4.9.4 /gcc/../libdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libdecnumber/dpd -I../l ibdecnumber -I/opt/build/china/gcc-4.9.4/gcc/../libbacktrace -DCLOOG_INT_GMP -I/ opt/TWWfsw/libcloog018/include -I/opt/TWWfsw/libisl015/include -o insn-output.o -MT insn-output.o -MMD -MP -MF ./.deps/insn-output.TPo insn-output.c /tmp//ccGCJgTB.s: Assembler messages: /tmp//ccGCJgTB.s:1361: Error: value of 00012990 too large for field of 2 bytes at 046e /tmp//ccGCJgTB.s:1495: Error: value of 00012990 too large for field of 2 bytes at 05ee /tmp//ccGCJgTB.s:1628: Error: value of 00012990 too large for field of 2 bytes at 0772 /tmp//ccGCJgTB.s:1761: Error: value of 00012990 too large for field of 2 bytes at 08f6 /tmp//ccGCJgTB.s:1913: Error: value of 00012994 too large for field of 2 bytes at 0aa6 /tmp//ccGCJgTB.s:2047: Error: value of 00012990 too large for field of 2 bytes at 0c2a /tmp//ccGCJgTB.s:2183: Error: value of 00012990 too large for field of 2 bytes at 0db6 /tmp//ccGCJgTB.s:2289: Error: value of 00012998 too large for field of 2 bytes at 0eca ... I was able to build gcc-8.1.0 on this system. Trying gcc-5.5.0, 6.4.0, and 7.2.0 now.
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 Jonathan Wakely changed: What|Removed |Added Keywords||build Status|WAITING |NEW --- Comment #6 from Jonathan Wakely --- Thanks
[Bug c++/86190] [6/7/8/9 Regression] -Wsign-conversion ignores explicit conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86190 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Wed Jul 18 13:13:11 2018 New Revision: 262855 URL: https://gcc.gnu.org/viewcvs?rev=262855&root=gcc&view=rev Log: PR c++/86190 - bogus -Wsign-conversion warning * typeck.c (cp_build_binary_op): Fix formatting. Add a warning sentinel. * g++.dg/warn/Wsign-conversion-3.C: New test. * g++.dg/warn/Wsign-conversion-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wsign-conversion-3.C trunk/gcc/testsuite/g++.dg/warn/Wsign-conversion-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/86559] Build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559 --- Comment #3 from The Written Word --- (In reply to Jonathan Wakely from comment #2) > (In reply to The Written Word from comment #1) > > Might be a duplicate of PR64081. > > Wrong bug number? I was looking at bug 64081 comment 31.
[Bug target/86560] FAIL: c-c++-common/asan/swapcontext-test-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86560 H.J. Lu changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=38207 --- Comment #2 from H.J. Lu --- LLVM bug is https://bugs.llvm.org/show_bug.cgi?id=38207
[Bug c++/86563] catch reference to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86563 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-18 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This might depend on the point of instantiation of the function template. The type is complete when the template is instantiated (although T is not dependent in the template body, so maybe it should be diagnosed earlier).
[Bug tree-optimization/86557] missed vectorization with std::vector compared to icc 18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86557 --- Comment #4 from Richard Biener --- Author: rguenth Date: Wed Jul 18 12:57:15 2018 New Revision: 262854 URL: https://gcc.gnu.org/viewcvs?rev=262854&root=gcc&view=rev Log: 2018-07-18 Richard Biener PR tree-optimization/86557 * tree-vect-patterns.c (vect_recog_divmod_pattern): Also handle EXACT_DIV_EXPR. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug libstdc++/86553] libstdc++-v3 build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553 --- Comment #5 from The Written Word --- Created attachment 44405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44405&action=edit Preprocessed source for math_stubs_long_double.cc
[Bug c++/86561] a function definition must occur in a standalone declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86561 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-18 Ever confirmed|0 |1
[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning and is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Martin Liška --- Fixed on trunk, not planning to backport that.
[Bug target/45996] -falign-functions=X does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45996 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Liška --- Fixed on trunk, not planning to backport that.
[Bug c++/86562] Missing warning (error in C++11) for passing nontrivial object to varargs function via function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86562 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Not a bug. The standard says passing non-trivial types through varargs is "conditionally-supported" so an implementation can either support it, or reject it with a diagnostic. GCC supports it, Clang doesn't.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471 --- Comment #21 from Jonathan Wakely --- Surely static_cast is good enough, and doesn't rule out making the function constexpr?
[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567 Richard Biener changed: What|Removed |Added Version|unknown |8.1.1 Target Milestone|--- |8.2 --- Comment #1 from Richard Biener --- I think maybe_constant_value has a cache which may cause side-effects.
[Bug bootstrap/86559] Build failure on AIX 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86559 --- Comment #2 from Jonathan Wakely --- (In reply to The Written Word from comment #1) > Might be a duplicate of PR64081. Wrong bug number? You might need -mcmodel=large
[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518 --- Comment #6 from Alexander Monakov --- GCC 7 sadly has a similar list of miscomparing files. Did not check GCC 6 yet. So far I managed to catch one set of misbehaving warnings by checking testsuite fallout with -fcompare-debug=-Wall, but unfortunately fixing those would not reduce the number of bootstrap miscompares: PR 86567.
[Bug c++/86567] New: [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567
Bug ID: 86567
Summary: [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect
code generation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
#include
std::vector
f()
{
std::vector r;
return r;
}
starting with gcc-8 ICEs using 'g++ -fcompare-debug=-Wnonnull' (as well as
Wformat, Wrestrict, Wsuggest-attribute=format)
cp/call.c:build_over_call() has:
if (warn_nonnull
|| warn_format
|| warn_suggest_attribute_format
|| warn_restrict)
{
tree *fargs = (!nargs ? argarray
: (tree *) alloca (nargs * sizeof (tree)));
for (j = 0; j < nargs; j++)
{
/* For -Wformat undo the implicit passing by hidden reference
done by convert_arg_to_ellipsis. */
if (TREE_CODE (argarray[j]) == ADDR_EXPR
&& TYPE_REF_P (TREE_TYPE (argarray[j])))
fargs[j] = TREE_OPERAND (argarray[j], 0);
else
fargs[j] = maybe_constant_value (argarray[j]);
}
warned_p = check_function_arguments (input_location, fn, TREE_TYPE (fn),
nargs, fargs, NULL);
}
which if bypassed does not cause the ICE, which indicates that something in the
snippet may affect code generation (not investigating further).
