[Bug c++/82850] g++ permits redefinition of default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850 --- Comment #1 from Jonathan Wakely --- GCC 4.8 stopped being supported by the upstream GCC project several years ago (and I think this is fixed in current releases).
[Bug middle-end/78044] -Wmaybe-uninitialized and -O2: false positive with boost::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044
--- Comment #7 from Andrzej Krzemienski ---
This still reproduces in version 7.2. Here is a Wandbox link:
https://wandbox.org/permlink/5uCAr5u0xpynljhQ
Here is the code, you need to compile it with -DNDEBUG -O2:
```
#include
class O
{
int _val;
bool _init = false;
public:
O() = default;
O(const int& i) : _val(i), _init(true) {}
explicit operator bool () const { return _init; }
const int& operator*() const { assert (_init); return _val; }
void operator=(int const& i) { _init = true; _val = i; }
};
bool equal_pointees ( O const& x, O const& y )
{
return (!x) != (!y) ? false : ( !x ? true : (*x) == (*y) ) ;
}
O getitem();
int main(int argc, const char *[])
{
O a = getitem();
O b;
if (argc > 0)
b = argc;
if (equal_pointees(a, b))
return 1;
return 0;
}
```
Is there a way to give a hint to the compiler (like with an attribute) so that
the warning is silenced?
[Bug ada/82844] [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Eric Botcazou --- > The last good subversion checkin is r253135. And the first revision for which you have the timeouts?
[Bug ada/82844] [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from H.J. Lu --- (In reply to Eric Botcazou from comment #4) > > If there is a git repo where a single commit contains only a single > > change, I can track down exactly which change caused this. > > The question was only whether you are 100% sure that this was broken between > 09/05 and 10/02, or if this was only an interpolation. > > IOW what are the dates of the last good run and the first bad run you have > got? The last good subversion checkin is r253135.
[Bug ada/82844] [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Eric Botcazou --- > If there is a git repo where a single commit contains only a single > change, I can track down exactly which change caused this. The question was only whether you are 100% sure that this was broken between 09/05 and 10/02, or if this was only an interpolation. IOW what are the dates of the last good run and the first bad run you have got?
[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2008-05-25 20:03:26 |2017-11-05 Depends on||82856 --- Comment #10 from Thomas Koenig --- Hope PR 82856 gets resolved soon - hard to do anything with generated files without a working automake :-( Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 [Bug 82856] [8 Regression] --enable-maintainter-mode broken by automake failure
[Bug bootstrap/82856] [8 Regression] --enable-maintainter-mode broken by automake failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |8.0
[Bug bootstrap/82856] New: [8 Regression] --enable-maintainter-mode broken by automake failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856
Bug ID: 82856
Summary: [8 Regression] --enable-maintainter-mode broken by
automake failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
I currently cannot build gcc on OpenSuse Tumbleweed due to
some problem with automake 1.11-6 (which is prescribed by the
gcc prerequisites):
make[3]: Verzeichnis „/home/ig25/Gcc/trunk-bin/zlib“ wird verlassen
make[3]: Verzeichnis „/home/ig25/Gcc/trunk-bin/libbacktrace“ wird betreten
cd ../../trunk/libbacktrace && /bin/sh /home/ig25/Gcc/trunk/missing --run
automake-1.11 --foreign --ignore-deps
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in
m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /home/ig25/bin/automake-1.11 line 4159.
make[3]: *** [Makefile:423: ../../trunk/libbacktrace/Makefile.in] Fehler 1
make[3]: Verzeichnis „/home/ig25/Gcc/trunk-bin/libbacktrace“ wird verlassen
make[2]: *** [Makefile:11465: all-stage1-libbacktrace] Fehler 2
make[2]: Verzeichnis „/home/ig25/Gcc/trunk-bin“ wird verlassen
make[1]: *** [Makefile:27970: stage1-bubble] Fehler 2
make[1]: Verzeichnis „/home/ig25/Gcc/trunk-bin“ wird verlassen
make: *** [Makefile:956: all] Fehler 2
configure was
../trunk/configure --prefix=$HOME --enable-maintainer-mode
--enable-languages=c,c++,fortran --disable-multilib
Perl is
g25@linux-d6cw:~/Gcc/trunk-bin> perl -v
This is perl 5, version 26, subversion 1 (v5.26.1) built for
x86_64-linux-thread-multi
Copyright 1987-2017, Larry Wall
automake-1.15 runs at least without a syntax error.
So, it may be that a never Perl version has broken the antique
version of automake we are using. Maybe an upgrade to a newer version
could fix it.
In the meantime, I am unable to work on libfortran issues.
[Bug target/82834] Cross-compiler doesn't find correct multilib for target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82834 --- Comment #2 from simon at pushface dot org --- (In reply to Andrew Pinski from comment #1) > # Single-precision floating-point is NOT supported; we don't build a > # suitable library for that. Use the rm-profile config in that case. > > You need to use --with-multilib-list=rmprofile but then you cannot use > --with-arch=armv7 . I’d just realised that, & was about to come back and ask for the PR to be closed. Thanks for preempting, & apologies for the noise.
[Bug c/82855] New: AVX512: replace OP+movemask with OP_mask+ktest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82855
Bug ID: 82855
Summary: AVX512: replace OP+movemask with OP_mask+ktest
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
Before AVX512, AVX/SSE code was written as in test1 function below: some
operation(s) created mask in vector register, it was then converted to int with
movemask instruction, and resulting int value was used in another expression -
e.g. compared with some constant. AVX512 added new k1..k7 registers and set of
instructions with _mask suffix which writes to them instead of creating mask in
vector register. So test2 function is simple attempt to rewrite test1 with new
instructions:
#include "immintrin.h"
bool test1(void* ptr)
{
__m256i v = _mm256_loadu_si256((const __m256i*)ptr);
v = _mm256_cmpeq_epi32(v, _mm256_setzero_si256());
return 0 == _mm256_movemask_epi8(v);
}
bool test2(void* ptr)
{
__m256i v = _mm256_loadu_si256((const __m256i*)ptr);
__mmask8 m = _mm256_cmpeq_epi32_mask(v, _mm256_setzero_si256());
return 0 == m;
}
I have tried to compile this using Compiler Explorer at https://godbolt.org/
with with following options:
-O3 -mavx -ftree-vectorize -mbmi -mpopcnt -mbmi2 -mavx2 -mavx512f -mavx512cd
-mavx512vl -mavx512bw -mavx512dq
gcc 7.2 and gcc trunk created following code:
test1(void*):
vmovdqu8 xmm0, XMMWORD PTR [rdi]
vinserti128 ymm1, ymm0, XMMWORD PTR [rdi+16], 0x1
vpxord xmm0, xmm0, xmm0
vpcmpeqd ymm0, ymm0, ymm1
vpmovmskb eax, ymm0
test eax, eax
sete al
ret
test2(void*):
vmovdqu8 xmm0, XMMWORD PTR [rdi]
vpxord xmm1, xmm1, xmm1
vinserti128 ymm0, ymm0, XMMWORD PTR [rdi+16], 0x1
vpcmpeqd k1, ymm0, ymm1
kmovb eax, k1
test al, al
sete al
ret
clang 5.0.0 created this:
test1(void*): # @test1(void*)
vpxor ymm0, ymm0, ymm0
vpcmpeqd k0, ymm0, ymmword ptr [rdi]
vpmovm2d ymm0, k0
vpmovmskb eax, ymm0
test eax, eax
sete al
vzeroupper
ret
test2(void*): # @test2(void*)
vpxor ymm0, ymm0, ymm0
vpcmpeqd k0, ymm0, ymmword ptr [rdi]
ktestb k0, k0
sete al
vzeroupper
ret
gcc output does not look very optimal. clang output for test2 is better, it
uses ktestb instead of kmovb+test. gcc should be able to do this too.
There is also one more possible optimization which can be applied for test1:
automatically replace OP and movemask instruction pair with OP_mask
instruction. Something like this is already performed for FMA3, gcc is able to
replace mul/add instruction pair with one FMA instruction. I do not have access
to any machine with AVX512 so I cannot perform any benchmarks. However this
kind of optimization looks promising, so it is worth exploring.
[Bug fortran/36313] [F03] {MIN,MAX}{LOC,VAL} should accept character arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #9 from Thomas Koenig --- Let's see if we can make some progress here.
[Bug fortran/29600] [F03] MINLOC and MAXLOC take an optional KIND argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Thomas Koenig --- Really closing.
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 29600, which changed state. Bug 29600 Summary: [F03] MINLOC and MAXLOC take an optional KIND argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/77908] Array operation fails for arrays with "long" indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77908 --- Comment #3 from Thomas Koenig --- I think we can fix this by rejecting arrays with an upper bound of huge(index_kind). This is an acceptable implementation limitation.
[Bug tree-optimization/82854] New: more missing simplifcations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82854
Bug ID: 82854
Summary: more missing simplifcations
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
These all come from a paper
"Optgen: A Generator for Local Optimizations" (Buchwald et.al.).
https://pp.info.uni-karlsruhe.de/uploads/publikationen/buchwald15cc.pdf
These were found by a SAT solver.
I wrote them in partial pseudo match.pd syntax (untested, likely buggy)
I'm not sure how useful they are really for real programs, but with the auto
generated matchers scaling well to more rules they wouldn't hurt I suppose.
/* x + (x & 0x8000) -> x & 0x7fff */
(simplify
(plus:c @0 (bit_and @0 integer_msb_onlyp@1))
(bit_and @0 { @1 - 1; } ))
/* (x | 0x8000) + 0x8000 -> x & 0x7FFF */
(simplify
(plus:c (bit_ior @0 integer_msb_onlyp) msb_setp)
(bit_and @0 { msb_minus_one_val(type); } ))
/* x & (x + 0x8000) -> x & 0x7FFF */
(simplify
(bit_and:c (plus @0 msb_setp) @0)
(bit_and @0 { msb_minus_one_val(type); } ))
/* x & (0x7FFF - x) -> x & 0x8000 */
(simplify
(bit_and:c @0 (minus msb_minus_onep @0))
(bit_and @0 { msb_val(type); } ))
/* is_power_of_2(c1) && c0 & (2 * c1 - 1) == c1 - 1 ->
(c0 - x) & c1 -> x & c1 */
/* x | (x + 0x8000) -> x | 0x8000 */
(simplify
(bit_ior:c @0 (plus @0 msb_onlyp))
(bit_ior @0 { msb_val(type); } ))
/* x | (0x7FFF - x) -> x | 0x7FFF */
(simplify
(bit_ior:c @0 (minus 0x7FFF @0))
(bit_ior @0 0x7FFF))
/* x | (x ^ y) -> x | y */
(simplify
(bit_ior:c @0 (bit_xor:c @0 @1))
(bit_ior @0 @1))
/* ((c0 | -c0) & ∼c1) == 0 AND (x + c0) | c1 -> x | c1 */
/* is_power_of_2(∼c1) && c0 & (2 * ∼c1 - 1) == ∼c1 - 1 AND
(c0 - x) | c1 ->
x | c1 */
/* -x | 0xFFFE -> x | 0xFFFE */
(simplify
(bit_or (negate @0) 0xFFFE)
(bit_or @0 0xFFFE))
/* 0 - (x & 0x8000) -> x & 0x8000 */
(simplify
(minus 0 (bit_and:c @0 0x8000))
(bit_and @0 0x8000))
/* 0x7FFF - (x & 0x8000) -> x | 0x7FFF */
(simplify
(minus 0x7FFF (bit_and @0 0x8000))
(bit_ior @0 0x7FFF))
/* 0x7FFF - (x | 0x7FFF) -> x & 0x8000 */
(simplify
(minus 0x7FFF (bit_ior:c @0 0x7FFF))
(bit_and @0 0x8000))
/* 0xFFFE - (x | 0x7FFF) -> x | 0x7FFF */
(simplify
(minus 0xFFFE (bit_ior:c @0 0x7FFF))
(bit_ior @0 0x7FFF))
/* (x & 0x7FFF) - x -> x & 0x8000 */
(simplify
(minus (bit_and:c @0 0x7FFF) @0)
(bit_and @0 0x8000))
/* x ^ (x + 0x8000) -> 0x8000 */
(simplify
(bit_xor:c (plus:c @0 0x8000))
0x8000)
/* x ^ (0x7FFF - x) -> 0x7FFF */
(simplify
(bit_xor:c @0 (minus 0x7FFF @0))
0x7FFF)
/* (x + 0x7FFF) ^ 0x7FFF -> -x */
(simplify
(bit_xor:c (plus:c @0 0x7FFF) 0x7FFF)
(negate @0))
/* -x ^ 0x8000 -> 0x8000 - x */
(simplify
(bit_xor:c (negate @0) 0x8000)
(minus 0x8000 @0))
/* (0x7FFF - x) ^ 0x7FFF -> x */
(simplify
(bit_xor:c (minus 0x7FFF @0) 0x7FFF)
@0)
/* ~(x + c) -> ~c - x */
(simplify
(bit_not (plus:c @0 CONSTANT_CLASS_P@1))
(minus (bit_not c) @0))
/* -x ^ 0x7FFF -> x + 0x7FFF */
(simplify
(bit_xor (negate @0) 0x7FFF)
(plus @0 0x7FFF))
/* (x | c) - c -> x & ∼c */
(simplify
(minus (bit_ior @0 CONSTANT_CLASS_P@1) @1)
(bit_and @0 (bit_not @1)))
/* ~(c - x) -> x + ∼c */
(simplify
(bit_not (minus CONSTANT_CLASS_P@0 @1))
(plus @1 (bit_not @0)))
/* -c0 == c1 AND (x | c0) + c1 -> x & ∼c1 */
(simplify
(plus (bit_or @0 CONSTANT_CLASS_P@1) CONSTANT_CLASS_P@2)
(if (...)
(bit_and @0 (bit_not @2))
/* (c0 & ∼c1) == 0 AND (x ^ c0) | c1 -> x | c1 */
/* 0x7FFF - (x ^ c) -> x ^ (0x7FFF - c) */
[Bug tree-optimization/82854] more missing simplifcations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82854 --- Comment #1 from Andi Kleen --- Also I suppose a lot of them could be generalized to 8/16/64bit.
[Bug target/82834] Cross-compiler doesn't find correct multilib for target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82834 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|driver |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- # Single-precision floating-point is NOT supported; we don't build a # suitable library for that. Use the rm-profile config in that case. You need to use --with-multilib-list=rmprofile but then you cannot use --with-arch=armv7 .
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #8 from Andi Kleen --- I'm not sure if it works with other numbers too. (need to dig through Hacker's delight & Matters Computational to see if they have anything on it) But it could be extended for other word lengths at least BTW there are some other cases, will file a bug shortly on those too.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #7 from Marc Glisse --- Is that a special case of a more generic transformation, which might apply for other values of 3, 0, == etc, or is this meant only literally for x%3==0?
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #38 from Marc Glisse --- *** Bug 82845 has been marked as a duplicate of this bug. ***
[Bug c/82845] -ftree-loop-distribute-patterns creates recursive loops on function called "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82845 Marc Glisse changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Marc Glisse --- Please don't touch the status field, I marked it as "duplicate" pointing to the other PR, that's more useful than "fixed" (which is false). Indeed we can hope that it will serve as a reminder for people working on PR 56888. *** This bug has been marked as a duplicate of bug 56888 ***
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-05 Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- (In reply to Andi Kleen from comment #5) > Also I'm not sure why you would want it in the middle end. It should all > work at the tree level Because we lose meaning and there is already code to handle the %N (where N is a constant) to a multiplication in the middle-end so reusing that code would be easy. Plus 0 is simpler than 0x5556.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #5 from Andi Kleen --- Also I'm not sure why you would want it in the middle end. It should all work at the tree level
[Bug target/82848] [8 Regression] ICE in expand_expr_real_2, at expr.c:8715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82848 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-05 CC||meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed.
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 --- Comment #4 from Andi Kleen --- Right it's about special casing the complete expression
[Bug middle-end/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 Andrew Pinski changed: What|Removed |Added Component|target |middle-end --- Comment #3 from Andrew Pinski --- For your code aarch64 produces: mod3: mov w1, 43691 movkw1, 0x, lsl 16 umull x1, w0, w1 lsr x1, x1, 32 lsr w1, w1, 1 add w1, w1, w1, lsl 1 cmp w0, w1 csetw0, eq ret Oh you mean not to produce a%3 followed by == part :). Anyways this code should go into the middle-end expanders and not be part of match.pd.
[Bug target/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
--- Comment #2 from Andrew Pinski ---
>Could be done in match.pd I suppose.
NO! There are a lot of code in the expander to handle division and modulus by
a constant already. If the division cost is high enough, then it is not used
directly and the multiply method is used as shown by what happens on aarch64:
f:
mov w1, 21846
movkw1, 0x, lsl 16
smull x1, w0, w1
lsr x1, x1, 32
sub w1, w1, w0, asr 31
add w1, w1, w1, lsl 1
sub w0, w0, w1
ret
int f(int a)
{
return a%3;
}
[Bug target/82853] Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* Component|tree-optimization |target --- Comment #1 from Andrew Pinski --- Works for me on aarch64: f: mov w1, 21846 movkw1, 0x, lsl 16 smull x1, w0, w1 lsr x1, x1, 32 sub w1, w1, w0, asr 31 add w1, w1, w1, lsl 1 sub w0, w0, w1 ret Most likely a target cost issue.
[Bug tree-optimization/82853] New: Optimize x % 3 == 0 without modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853
Bug ID: 82853
Summary: Optimize x % 3 == 0 without modulo
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Ralph Levien pointed out as part of FizzBuzz optimization:
Turns out you can compute x%3 == 0 with even fewer steps, it's (x*0xb)
< 0x5556 (assuming wrapping unsigned 32 bit arithmetic).
gcc currently generates the full modulo and then checks.
Could be done in match.pd I suppose.
Test case
unsigned mod3(unsigned a) { return 0==(a%3); }
[Bug rtl-optimization/82849] [8 Regression] ICE on valid code since r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82849 Andrew Pinski changed: What|Removed |Added Component|c |rtl-optimization Version|7.0 |8.0 Target Milestone|--- |8.0 --- Comment #1 from Andrew Pinski --- What target is this on?
[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 Andreas Tobler changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Andreas Tobler --- Trunk and active branches are fixed.
[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 --- Comment #17 from Andreas Tobler --- Author: andreast Date: Sun Nov 5 19:33:44 2017 New Revision: 254432 URL: https://gcc.gnu.org/viewcvs?rev=254432&root=gcc&view=rev Log: 2017-11-05 Andreas Tobler Backport from mainline 2017-11-04 Andreas Tobler PR libgcc/82635 * config/i386/freebsd-unwind.h (MD_FALLBACK_FRAME_STATE_FOR): Use a sysctl to determine whether we're in a trampoline. Keep the pattern matching method for systems without KERN_PROC_SIGTRAMP sysctl. Modified: branches/gcc-6-branch/libgcc/ChangeLog branches/gcc-6-branch/libgcc/config/i386/freebsd-unwind.h
[Bug libgcc/82635] std::thread's join broken on FreeBSD with all GCCs >= 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 --- Comment #16 from Andreas Tobler --- Author: andreast Date: Sun Nov 5 19:30:41 2017 New Revision: 254431 URL: https://gcc.gnu.org/viewcvs?rev=254431&root=gcc&view=rev Log: 2017-11-05 Andreas Tobler Backport from mainline 2017-11-04 Andreas Tobler PR libgcc/82635 * config/i386/freebsd-unwind.h (MD_FALLBACK_FRAME_STATE_FOR): Use a sysctl to determine whether we're in a trampoline. Keep the pattern matching method for systems without KERN_PROC_SIGTRAMP sysctl. Modified: branches/gcc-7-branch/libgcc/ChangeLog branches/gcc-7-branch/libgcc/config/i386/freebsd-unwind.h
[Bug ada/82844] [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > This happens only when GCC is compiled as the native x32 binary. There are 2 issues to track down which change caused the regression: 1. A GCC subversion checkin contains multiple changes. 2. One of the changes: 2017-09-25 Doug Rupp * libgnarl/s-taprop__linux.adb (Base_Monotonic_Clock): New variable. (Compute_Base_Monotonic_Clock): New function. (Timed_Sleep): Adjust to use Base_Monotonic_Clock. (Timed_Delay): Likewise. (Monotonic_Clock): Likewise. * s-oscons-tmplt.c (CLOCK_MONOTONIC): Use on Linux. broke x32 built, which wasn't fixed until commit 2d2d4c5b6ab083e65fb10e42c11dd68548fdc036 (HEAD) Author: ebotcazou Date: Mon Oct 2 19:38:06 2017 + PR ada/82384 * libgnarl/s-linux__x32.ads (suseconds_t): New subtype. (time_t): Change from derived type to subtype. (timeval): Use suseconds_t for tv_usec. * libgnarl/s-osinte__x32.adb (To_Timespec): Remove use type clause. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253366 138bc75d-0d04-0410-961f-82ee72b054a4 If there is a git repo where a single commit contains only a single change, I can track down exactly which change caused this.
[Bug target/82852] New: [8 regression] i386/vect-unpack-1.c, i386/avx512f-gather-2.c, i386/avx256-unaligned-store-2.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82852 Bug ID: 82852 Summary: [8 regression] i386/vect-unpack-1.c, i386/avx512f-gather-2.c, i386/avx256-unaligned-store-2.c fails Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r254012 triggers these fails: spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/vect-unpack-1.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -ftree-vectorize -ffast-math -mavx512bw -save-temps -ffat-lto-objects -lm -o ./vect-unpack-1.exe PASS: gcc.target/i386/vect-unpack-1.c (test for excess errors) PASS: gcc.target/i386/vect-unpack-1.c execution test FAIL: gcc.target/i386/vect-unpack-1.c scan-assembler-times vpmovzxbw[ \\t]+[^\n]*%zmm 2 (found 0 times) --- spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/avx512f-gather-2.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -mavx512f -fdump-tree-vect-details -ffat-lto-objects -S -o avx512f-gather-2.s PASS: gcc.target/i386/avx512f-gather-2.c (test for excess errors) PASS: gcc.target/i386/avx512f-gather-2.c scan-assembler-not gather[^\n]*ymm[^\n]*ymm PASS: gcc.target/i386/avx512f-gather-2.c scan-assembler-not gather[^\n]*xmm[^\n]*ymm PASS: gcc.target/i386/avx512f-gather-2.c scan-assembler-not gather[^\n]*ymm[^\n]*xmm FAIL: gcc.target/i386/avx512f-gather-2.c scan-assembler-not gather[^\n]*xmm[^\n]*xmm FAIL: gcc.target/i386/avx512f-gather-2.c scan-tree-dump-times vect "note: vectorized 1 loops in function" 16 (found 10 times) --- spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-2.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -mtune-ctrl=sse_typeless_stores -dp -mavx -mavx256-split-unaligned-store -mno-prefer-avx128 -ffat-lto-objects -S -o avx256-unaligned-store-2.s PASS: gcc.target/i386/avx256-unaligned-store-2.c (test for excess errors) PASS: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler-not vmovups.*movv32qi_internal/4 FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler vmovups.*movv16qi_internal/4 FAIL: gcc.target/i386/avx256-unaligned-store-2.c scan-assembler vextract.128 Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm
[Bug target/82851] New: [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82851 Bug ID: 82851 Summary: [8 regression] g++.dg/vect/slp-pr56812.cc, i386/avx2-vpaddq-3.c, i386/avx2-vpsubq-3.c fails Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r253975 triggers these fails: spawn -ignore SIGHUP /work/gcc/testsuite/g++6/../../xg++ -B/work/gcc/testsuite/g++6/../../ /source/gcc/testsuite/g++.dg/vect/slp-pr56812.cc -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/work/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/work/x86_64-pc-linux-gnu/libstdc++-v3/include -I/source/libstdc++-v3/libsupc++ -I/source/libstdc++-v3/include/backward -I/source/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98 -O2 -ftree-vectorize -fno-vect-cost-model -msse2 -fdump-tree-slp-details -O3 -funroll-loops -fvect-cost-model=dynamic -S -o slp-pr56812.s PASS: g++.dg/vect/slp-pr56812.cc -std=c++98 (test for excess errors) FAIL: g++.dg/vect/slp-pr56812.cc -std=c++98 scan-tree-dump-times slp1 "basic block vectorized" 1 (found 0 times) --- spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/avx2-vpaddq-3.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -save-temps -ffat-lto-objects -lm -o ./avx2-vpaddq-3.exe PASS: gcc.target/i386/avx2-vpaddq-3.c (test for excess errors) PASS: gcc.target/i386/avx2-vpaddq-3.c execution test FAIL: gcc.target/i386/avx2-vpaddq-3.c scan-assembler-times vpaddq[ \\t]+[^\n]*%ymm[0-9] 1 (found 0 times) --- spawn -ignore SIGHUP /work/gcc/xgcc -B/work/gcc/ /source/gcc/testsuite/gcc.target/i386/avx2-vpsubq-3.c -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxrt -L/work/x86_64-pc-linux-gnu/./libmpx/mpxrt/.libs -B/work/x86_64-pc-linux-gnu/./libmpx/ -B/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap -L/work/x86_64-pc-linux-gnu/./libmpx/mpxwrap/.libs -fno-diagnostics-show-caret -fdiagnostics-color=never -mavx2 -mno-prefer-avx128 -O2 -ftree-vectorize -save-temps -ffat-lto-objects -lm -o ./avx2-vpsubq-3.exe PASS: gcc.target/i386/avx2-vpsubq-3.c (test for excess errors) PASS: gcc.target/i386/avx2-vpsubq-3.c execution test FAIL: gcc.target/i386/avx2-vpsubq-3.c scan-assembler-times vpsubq[ \\t]+[^\n]*%ymm[0-9] 1 (found 0 times) Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm
[Bug c++/82850] New: g++ permits redefinition of default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850
Bug ID: 82850
Summary: g++ permits redefinition of default arguments
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ec13n at my dot fsu.edu
Target Milestone: ---
g++ allows for the redefinition of default arguments, shown by the following
code:
// compiled with -Wall -Wextra
template < class T = int >
void myFunc ();
template < class T = int >
void myFunc () {
//..
}
int main(){
return 0;
}
According to specification, this should not be allowed. (§14.1.12, I believe?)
If however two (potentially distinct) default arguments *are* allowed, this
could create a serious point of failure for client programs that may be relying
on one of the default values but are getting a different one.
gcc version details:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC)
[Bug c/82849] New: [8 Regression] ICE on valid code since r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82849 Bug ID: 82849 Summary: [8 Regression] ICE on valid code since r254379 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- We divide by zero here: 1425if (single_exit (loop)->count () > profile_count::zero ()) 1426 trip_count = latch_edge->count ().to_gcov_type () 1427 / single_exit (loop)->count ().to_gcov_type (); $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/eoshift_5.f90 -O2 -fmodulo-sched during RTL pass: sms /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/eoshift_5.f90:182:0: end program main internal compiler error: Floating point exception 0xc0fd1f crash_signal ../../gcc/toplev.c:324 0x143b536 sms_schedule ../../gcc/modulo-sched.c:1426 0x143cd6f execute ../../gcc/modulo-sched.c:3342
[Bug target/82848] New: [8 Regression] ICE in expand_expr_real_2, at expr.c:8715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82848
Bug ID: 82848
Summary: [8 Regression] ICE in expand_expr_real_2, at
expr.c:8715
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: ppc64-linux-gnu
Following ICEs:
$ ppc64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c:12:16:
internal compiler error: in expand_expr_real_2, at expr.c:8715
vector float b = __builtin_vec_madd (b, a, (vector float) { C, C, C, C });
^
0x82d5d9 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
.././../gcc/expr.c:8715
0x6ffa69 expand_gimple_stmt_1
.././../gcc/cfgexpand.c:3712
0x6ffa69 expand_gimple_stmt
.././../gcc/cfgexpand.c:3773
0x70132f expand_gimple_basic_block
.././../gcc/cfgexpand.c:5774
0x706d36 execute
.././../gcc/cfgexpand.c:6375
Note that GCC 7.1 did:
$ powerpc64-suse-linux-gcc-7
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c -c
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c: In
function 'foo':
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/powerpc/pr37168.c:12:16:
error: Builtin function __builtin_altivec_vmaddfp requires the -maltivec option
vector float b = __builtin_vec_madd (b, a, (vector float) { C, C, C, C });
^
So the error somehow disappeared.
[Bug fortran/82471] Reorder loop for unfavorable index ordering in DO CONCURRENT and FORALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/82471] Reorder loop for unfavorable index ordering in DO CONCURRENT and FORALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #11 from Thomas Koenig --- Author: tkoenig Date: Sun Nov 5 17:24:37 2017 New Revision: 254430 URL: https://gcc.gnu.org/viewcvs?rev=254430&root=gcc&view=rev Log: 2017-11-05 Thomas Koenig PR fortran/82471 * lang.opt (ffrontend-loop-interchange): New option. (Wfrontend-loop-interchange): New option. * options.c (gfc_post_options): Handle ffrontend-loop-interchange. * frontend-passes.c (gfc_run_passes): Run optimize_namespace if flag_frontend_optimize or flag_frontend_loop_interchange are set. (optimize_namespace): Run functions according to flags set; also call index_interchange. (ind_type): New function. (has_var): New function. (index_cost): New function. (loop_comp): New function. 2017-11-05 Thomas Koenig PR fortran/82471 * gfortran.dg/loop_interchange_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/loop_interchange_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/36854] [meta-bug] fortran front-end optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854 Bug 36854 depends on bug 82471, which changed state. Bug 82471 Summary: Reorder loop for unfavorable index ordering in DO CONCURRENT and FORALL https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ada/82844] [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-05 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- So is the given range of revisions meaningful in the end?
[Bug c/82845] -ftree-loop-distribute-patterns creates recursive loops on function called "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82845 David Brown changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #2 from David Brown --- (In reply to Marc Glisse from comment #1) > Richard's patch seems to have been forgotten :-( > > *** This bug has been marked as a duplicate of bug 56888 *** Sorry for the noise. (Unless it encourages the fix from bug 56888 to be implemented!)
[Bug c/82845] -ftree-loop-distribute-patterns creates recursive loops on function called "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82845 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Marc Glisse --- Richard's patch seems to have been forgotten :-( *** This bug has been marked as a duplicate of bug 56888 ***
[Bug fortran/81447] [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81447 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on 7-branch and trunk Many thanks for the report. Paul
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Marc Glisse changed: What|Removed |Added CC||david at westcontrol dot com --- Comment #37 from Marc Glisse --- *** Bug 82845 has been marked as a duplicate of this bug. ***
[Bug middle-end/82847] New: [8 regression] gcc.dg/vect/slp-perm-9.c fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82847 Bug ID: 82847 Summary: [8 regression] gcc.dg/vect/slp-perm-9.c fail Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r248909 triggers this fail: FAIL: gcc.dg/vect/slp-perm-9.c scan-tree-dump-times vect "vectorized 1 loops" 1 Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=slm --with-cpu=slm
[Bug fortran/81447] [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81447 --- Comment #4 from Paul Thomas --- Author: pault Date: Sun Nov 5 16:56:14 2017 New Revision: 254429 URL: https://gcc.gnu.org/viewcvs?rev=254429&root=gcc&view=rev Log: 2017-11-05 Paul Thomas PR fortran/81447 PR fortran/82783 * resolve.c (resolve_component): There is no need to resolve the components of a use associated vtype. (resolve_fl_derived): Unconditionally generate a vtable for any module derived type, as long as the standard is F2003 or later and it is not a vtype or a PDT template. 2017-11-05 Paul Thomas PR fortran/81447 * gfortran.dg/class_65.f90: New test. * gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free count from 18 to 21. * gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free count from 32 to 54. * gfortran.dg/auto_dealloc_1.f90: Increase builtin_free count from 4 to 10. * gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to 3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from 2 to 5. * gfortran.dg/finalize_28.f90: Increase builtin_free count from 3 to 6. * gfortran.dg/move_alloc_15.f90: Increase builtin_free and builtin_malloc counts from 11 to 14. * gfortran.dg/typebound_proc_27.f03: Increase builtin_free count from 7 to 10. Likewise builtin_malloc from 12 to 15. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_65.f90 Modified: branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/auto_dealloc_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray_lib_realloc_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/finalize_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/move_alloc_15.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/typebound_proc_27.f03
[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82783 --- Comment #6 from Paul Thomas --- Author: pault Date: Sun Nov 5 16:56:14 2017 New Revision: 254429 URL: https://gcc.gnu.org/viewcvs?rev=254429&root=gcc&view=rev Log: 2017-11-05 Paul Thomas PR fortran/81447 PR fortran/82783 * resolve.c (resolve_component): There is no need to resolve the components of a use associated vtype. (resolve_fl_derived): Unconditionally generate a vtable for any module derived type, as long as the standard is F2003 or later and it is not a vtype or a PDT template. 2017-11-05 Paul Thomas PR fortran/81447 * gfortran.dg/class_65.f90: New test. * gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free count from 18 to 21. * gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free count from 32 to 54. * gfortran.dg/auto_dealloc_1.f90: Increase builtin_free count from 4 to 10. * gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to 3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from 2 to 5. * gfortran.dg/finalize_28.f90: Increase builtin_free count from 3 to 6. * gfortran.dg/move_alloc_15.f90: Increase builtin_free and builtin_malloc counts from 11 to 14. * gfortran.dg/typebound_proc_27.f03: Increase builtin_free count from 7 to 10. Likewise builtin_malloc from 12 to 15. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_65.f90 Modified: branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/auto_dealloc_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/coarray_lib_realloc_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/finalize_28.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/move_alloc_15.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/typebound_proc_27.f03
[Bug jit/82846] [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 --- Comment #1 from Andrey Guskov --- Also affects test-alignment.cc.exe: NOTE: test-alignment.cc.exe iteration 1 of 5: writing reproducer to ./test-alignment.cc.exe.reproducer.c PASSED: test-alignment.cc.exe iteration 1 of 5: verify_aligned_code: result is non-null PASSED: test-alignment.cc.exe iteration 1 of 5: verify_aligned_code: test_writing is non-null FAILED: test-alignment.cc.exe iteration 1 of 5: verify_aligned_code: actual: test_writing (&tmp) != expected: 35 incorrect value PASS: test-alignment.cc.exe iteration 1 of 5: verify_aligned_code: result is non-null PASS: test-alignment.cc.exe iteration 1 of 5: verify_aligned_code: test_writing is non-null FAIL: test-alignment.cc.exe iteration 1 of 5: verify_aligned_code: actual: test_writing (&tmp) != expected: 35 FAIL: test-alignment.cc.exe killed: 45660 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
[Bug jit/82846] New: [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82846 Bug ID: 82846 Summary: [8 regression] jit.dg test-alignment.c.exe, test-combination.c.exe, test-threads.c.exe fails Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: andrey.y.guskov at intel dot com Target Milestone: --- r254152 triggers several fails in JIT: --- PASSED: test-alignment.c.exe iteration 1 of 5: verify_aligned_code_s2: result is non-null PASSED: test-alignment.c.exe iteration 1 of 5: verify_aligned_code_s2: test_writing is non-null FAILED: test-alignment.c.exe iteration 1 of 5: verify_aligned_code_s2: actual: test_writing (&tmp) != expected: 35 incorrect value PASS: test-alignment.c.exe iteration 1 of 5: verify_aligned_code_s2: result is non-null PASS: test-alignment.c.exe iteration 1 of 5: verify_aligned_code_s2: test_writing is non-null FAIL: test-alignment.c.exe iteration 1 of 5: verify_aligned_code_s2: actual: test_writing (&tmp) != expected: 35 FAIL: test-alignment.c.exe killed: 34058 exp9 0 0 CHILDKILLED SIGABRT SIGABRT --- PASSED: test-combination.c.exe iteration 1 of 5: verify_aligned_code_s2: result is non-null PASSED: test-combination.c.exe iteration 1 of 5: verify_aligned_code_s2: test_writing is non-null FAILED: test-combination.c.exe iteration 1 of 5: verify_aligned_code_s2: actual: test_writing (&tmp) != expected: 35 incorrect value PASS: test-combination.c.exe iteration 1 of 5: verify_aligned_code_s2: result is non-null PASS: test-combination.c.exe iteration 1 of 5: verify_aligned_code_s2: test_writing is non-null FAIL: test-combination.c.exe iteration 1 of 5: verify_aligned_code_s2: actual: test_writing (&tmp) != expected: 35 FAIL: test-combination.c.exe killed: 30447 exp9 0 0 CHILDKILLED SIGABRT SIGABRT --- NOTE: run_threaded_test: autovectorize iteration: 2 PASSED: test-threads.c.exe: verify_aligned_code_s2: result is non-null PASSED: test-threads.c.exe: verify_aligned_code_s2: test_writing is non-null FAILED: test-threads.c.exe: verify_aligned_code_s2: actual: test_writing (&tmp) != expected: 35 incorrect value PASS: test-threads.c.exe: verify_aligned_code_s2: result is non-null PASS: test-threads.c.exe: verify_aligned_code_s2: test_writing is non-null FAIL: test-threads.c.exe: verify_aligned_code_s2: actual: test_writing (&tmp) != expected: 35 FAIL: test-threads.c.exe killed: 3769 exp9 0 0 CHILDKILLED SIGABRT SIGABRT Option set: -with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-shared --enable-host-shared --enable-clocale=gnu --enable-cloog-backend=isl --enable-languages=c,c++,fortran,jit,lto -with-arch=haswell --with-cpu=haswell
[Bug c/82845] New: -ftree-loop-distribute-patterns creates recursive loops on function called "memset"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82845
Bug ID: 82845
Summary: -ftree-loop-distribute-patterns creates recursive
loops on function called "memset"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
(I have tested this using several gcc versions, including x86_64 and arm ports,
up to an 8.0.0 trunk test version.)
The -ftree-loop-distribute-patterns optimisation spots constructs that look
like memset, memcpy, etc., calls - and generates library calls to these
functions to give fast code using the library routines rather than generating
large amounts of inline code (so that the set or copy operations can be done in
lumps larger than one byte at a time).
But if you have have your own implementation of one of these functions (as may
be done for tracing calls, or in some embedded systems - or simply because you
are writing a C library), the call does not go to the library version - it will
go to the new local definition of the function. For example, given this simple
memset implementation:
void *memset(void *s, int c, size_t n)
{
char *p = s;
while (n--) *p++ = c;
return s;
}
gcc on x86_64 with -O2 gives simple, solid code:
memset:
testq %rdx, %rdx
movq%rdi, %rax
je .L6
addq%rdi, %rdx
movq%rdi, %rcx
.L3:
addq$1, %rcx
movb%sil, -1(%rcx)
cmpq%rdx, %rcx
jne .L3
.L6:
rep ret
With -O3, which enables -ftree-loop-distribute-patterns, it gives:
memset:
testq %rdx, %rdx
je .L6
subq$8, %rsp
movsbl %sil, %esi
callmemset
addq$8, %rsp
ret
.L6:
movq%rdi, %rax
ret
gcc spots that the loop is like an memset, and replaces it with a call to
memset. But now that leads to infinite recursion.
[Bug fortran/82843] (PDT) Constructors with PDT components do not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82843 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/82841] Segfault in gfc_simplify_transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82841 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- I get the ICE from 4.8 up to trunk (8.0). Compiling the test with an instrumented compiler gives ../../work/gcc/fortran/simplify.c:6623:4: runtime error: member access within null pointer of type 'struct gfc_constructor'
[Bug fortran/82842] (PDT) Constructors do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82842
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-11-05
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres ---
The same test appears twice in comment 0 and the test in comment 1 gives the
errors
pr82842_1.f90:19:11:
x = s3(2)(transfer('Xe',['x']))
1
Error: Invalid character in name at (1)
pr82842_1.f90:27:10:
u = s4(x)
1
Error: Can't convert TYPE(Pdts3) to TYPE(s3) at (1)
[Bug target/82767] [8 regression] gcc.target/i386/pr71321.c scan-assembler-times fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82767 --- Comment #2 from Sebastian Peryt --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00308.html
[Bug ada/82844] [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 H.J. Lu changed: What|Removed |Added Host||x32 --- Comment #1 from H.J. Lu --- This happens only when GCC is compiled as the native x32 binary.
[Bug ada/82844] New: [8 Regression] Many ada tests time out on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82844 Bug ID: 82844 Summary: [8 Regression] Many ada tests time out on x32 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: derodat at adacore dot com, ebotcazou at gcc dot gnu.org, rupp at gnat dot com Target Milestone: --- Target: x32 Between commit 88d1247af311afb63a8ca464ae09d5b7a275724c Author: pmderodat Date: Mon Sep 25 08:40:27 2017 + 2017-09-25 Ed Schonberg * sem_ch12.adb (Save_References_In_Aggregate): Small correction to previous change. 2017-09-25 Hristian Kirtchev * exp_ch5.adb, sem_ch4.adb, sem_ch13.adb, sem_attr.adb, exp_ch3.adb: Minor reformatting. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253135 138bc75d-0d04-0410-961f-82ee72b054a4 and commit 2d2d4c5b6ab083e65fb10e42c11dd68548fdc036 (HEAD) Author: ebotcazou Date: Mon Oct 2 19:38:06 2017 + PR ada/82384 * libgnarl/s-linux__x32.ads (suseconds_t): New subtype. (time_t): Change from derived type to subtype. (timeval): Use suseconds_t for tv_usec. * libgnarl/s-osinte__x32.adb (To_Timespec): Remove use type clause. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@253366 138bc75d-0d04-0410-961f-82ee72b054a4 many ada tests time out on x32. This regression is probably introduced by 2017-09-25 Doug Rupp * libgnarl/s-taprop__linux.adb (Base_Monotonic_Clock): New variable. (Compute_Base_Monotonic_Clock): New function. (Timed_Sleep): Adjust to use Base_Monotonic_Clock. (Timed_Delay): Likewise. (Monotonic_Clock): Likewise. * s-oscons-tmplt.c (CLOCK_MONOTONIC): Use on Linux.
[Bug tree-optimization/61000] No loop interchange for inner loop along the slow index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 --- Comment #7 from Thomas Koenig --- When tackling this in the front end, one problem is when _not_ to do loop interchange. Consider do i=1,10 do j=1,10 call foo(a(i,j)) end do end do where we have no idea what foo does, and if it depends on the order it is called (unless it is pure). Also, if you look at program main integer, dimension(3,3) :: a integer, dimension(9) :: b a = reshape([(4**(i-1),i=1,9)],shape(a)) b = [(2*4**(i-1),i=1,9)] k = 0 do i=1,3 do j=1,3 k = k + 1 a(i,j) = a(i,j) + b(k) end do end do print *,a a = reshape([(4**(i-1),i=1,9)],shape(a)) k = 0 do j=1,3 do i=1,3 k = k + 1 a(i,j) = a(i,j) + b(k) end do end do print *,a end program main you see that loop reordering can introduce wrong code quite easily.
[Bug fortran/78641] [6/7/8 Regression] [OOP] ICE on polymorphic allocatable function in array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78641 --- Comment #7 from Paul Thomas --- Author: pault Date: Sun Nov 5 14:32:05 2017 New Revision: 254428 URL: https://gcc.gnu.org/viewcvs?rev=254428&root=gcc&view=rev Log: 2017-11-05 Paul Thomas PR fortran/78641 * resolve.c (resolve_ordinary_assign): Do not add the _data component for class valued array constructors being assigned to derived type arrays. * trans-array.c (gfc_trans_array_ctor_element): Take the _data of class valued elements for assignment to derived type arrays. 2017-11-05 Paul Thomas PR fortran/78641 * gfortran.dg/class_66.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_66.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/82842] (PDT) Constructors do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82842
--- Comment #1 from Paul Thomas ---
A related bug from:
https://groups.google.com/forum/#!topic/comp.lang.fortran/NDE6JKTFbNU
module mod1
implicit none
type s3(selector)
integer, len :: selector
character key(selector)
end type s3
type s4
type(s3(:)), allocatable :: key
end type s4
end module mod1
program main
use mod1
implicit none
type(s3(:)), allocatable :: x
type(s3(:)), allocatable :: z
type(s4) u
type(s4) v
x = s3(2)(transfer('Xe',['x']))
write(*,*) 'ALLOCATED(x) = ',ALLOCATED(x)
write(*,*) 'x%selector = ',x%selector
write(*,*) 'x%key = ',x%key
z = x
write(*,*) 'ALLOCATED(z) = ',ALLOCATED(z)
write(*,*) 'z%selector = ',z%selector
write(*,*) 'z%key = ',z%key
u = s4(x)
write(*,*) 'ALLOCATED(u%key) = ',ALLOCATED(u%key)
write(*,*) 'u%key%selector = ',u%key%selector
write(*,*) 'u%key%key = ',u%key%key
v = u
write(*,*) 'ALLOCATED(v%key) = ',ALLOCATED(v%key)
write(*,*) 'v%key%selector = ',v%key%selector
write(*,*) 'v%key%key = ',v%key%key
end program main
gfortran.exe -c p.f90 -o p.o
f951.exe: internal compiler error: Segmentation fault
[Bug fortran/82843] New: (PDT) Constructors with PDT components do not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82843 Bug ID: 82843 Summary: (PDT) Constructors with PDT components do not work. Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- And another one to try once the earlier cases are resolved: Another goodie from https://groups.google.com/forum/#!topic/comp.lang.fortran/NDE6JKTFbNU --- begin case --- type :: t(ell) integer, len :: ell end type type :: u type(t(ell=:)), allocatable :: x end type type(t(ell=:)), allocatable :: foo type(u) :: bar allocate( t(ell=1) :: foo ) bar = u( x=foo ) end --- end case --- gfortran.exe -c p.f90 -o p.o p.f90:14:14: bar = u( x=foo ) 1 Error: Can't convert TYPE(Pdtt) to TYPE(t) at (1) Not only is the constructor failing to compile, but I need to be turning the PDT name back into the original for the error message.
[Bug fortran/82842] New: (PDT) Constructors do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82842 Bug ID: 82842 Summary: (PDT) Constructors do not work Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- From: https://groups.google.com/forum/#!topic/comp.lang.fortran/NDE6JKTFbNU type :: t(k) integer, kind :: k end type type :: s(ell) integer, len :: ell end type type(t(k=1)), allocatable :: foo type(s(ell=:)), allocatable :: bar foo = t(k=1)() bar = s(ell=2)() end type :: t(k) integer, kind :: k end type type :: s(ell) integer, len :: ell end type type(t(k=1)), allocatable :: foo type(s(ell=:)), allocatable :: bar foo = t(k=1)() bar = s(ell=2)() end
[Bug fortran/82841] New: Segfault in gfc_simplify_transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82841
Bug ID: 82841
Summary: Segfault in gfc_simplify_transfer
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pault at gcc dot gnu.org
Target Milestone: ---
From: https://groups.google.com/forum/#!topic/comp.lang.fortran/NDE6JKTFbNU
integer, parameter :: N = 2
character(len=1) :: chr(N)
chr = transfer(source=repeat("x",ncopies=N), mold=[ character(len=1) :: ],
size=N)
end
[pault@pc30 fortranfan]$ ~/irun/bin/gfortran -static-libgfortran f*2.f90
f951: internal compiler error: Segmentation fault
0xcb6d8f crash_signal
../../trunk/gcc/toplev.c:324
0x791330 gfc_simplify_transfer(gfc_expr*, gfc_expr*, gfc_expr*)
../../trunk/gcc/fortran/simplify.c:6589
0x71de22 do_simplify
../../trunk/gcc/fortran/intrinsic.c:4407
0x7282b6 gfc_intrinsic_func_interface(gfc_expr*, int)
../../trunk/gcc/fortran/intrinsic.c:4777
0x77d11c resolve_unknown_f
../../trunk/gcc/fortran/resolve.c:2865
0x77d11c resolve_function
../../trunk/gcc/fortran/resolve.c:3174
0x779a1d gfc_resolve_expr(gfc_expr*)
../../trunk/gcc/fortran/resolve.c:6702
0x77237f gfc_resolve_code(gfc_code*, gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:11060
0x77498f resolve_codes
../../trunk/gcc/fortran/resolve.c:16406
0x774a5e gfc_resolve(gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:16441
0x763414 resolve_all_program_units
../../trunk/gcc/fortran/parse.c:6030
0x763414 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6280
0x7a72ff gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
[Bug fortran/82783] [7/8 Regression] gfortran ICEs when compiling polymorphic function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82783 --- Comment #5 from Paul Thomas --- Author: pault Date: Sun Nov 5 12:38:42 2017 New Revision: 254427 URL: https://gcc.gnu.org/viewcvs?rev=254427&root=gcc&view=rev Log: 2017-11-05 Paul Thomas PR fortran/81447 PR fortran/82783 * resolve.c (resolve_component): There is no need to resolve the components of a use associated vtype. (resolve_fl_derived): Unconditionally generate a vtable for any module derived type, as long as the standard is F2003 or later and it is not a vtype or a PDT template. 2017-11-05 Paul Thomas PR fortran/81447 * gfortran.dg/class_65.f90: New test. * gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free count from 18 to 21. * gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free count from 32 to 54. * gfortran.dg/auto_dealloc_1.f90: Increase builtin_free count from 4 to 10. * gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to 3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from 2 to 5. * gfortran.dg/finalize_28.f90: Increase builtin_free count from 3 to 6. * gfortran.dg/move_alloc_15.f90: Increase builtin_free and builtin_malloc counts from 11 to 14. * gfortran.dg/typebound_proc_27.f03: Increase builtin_free count from 7 to 10. Likewise builtin_malloc from 12 to 15. Added: trunk/gcc/testsuite/gfortran.dg/class_65.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 trunk/gcc/testsuite/gfortran.dg/auto_dealloc_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_lib_realloc_1.f90 trunk/gcc/testsuite/gfortran.dg/finalize_28.f90 trunk/gcc/testsuite/gfortran.dg/move_alloc_15.f90 trunk/gcc/testsuite/gfortran.dg/typebound_proc_27.f03
[Bug fortran/81447] [7/8] gfortran fails to recognize the exact dynamic type of a polymorphic entity that was allocated in a external procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81447 --- Comment #3 from Paul Thomas --- Author: pault Date: Sun Nov 5 12:38:42 2017 New Revision: 254427 URL: https://gcc.gnu.org/viewcvs?rev=254427&root=gcc&view=rev Log: 2017-11-05 Paul Thomas PR fortran/81447 PR fortran/82783 * resolve.c (resolve_component): There is no need to resolve the components of a use associated vtype. (resolve_fl_derived): Unconditionally generate a vtable for any module derived type, as long as the standard is F2003 or later and it is not a vtype or a PDT template. 2017-11-05 Paul Thomas PR fortran/81447 * gfortran.dg/class_65.f90: New test. * gfortran.dg/alloc_comp_basics_1.f90: Increase builtin_free count from 18 to 21. * gfortran.dg/allocatable_scalar_9.f90: Increase builtin_free count from 32 to 54. * gfortran.dg/auto_dealloc_1.f90: Increase builtin_free count from 4 to 10. * gfortran.dg/coarray_lib_realloc_1.f90: Increase builtin_free count from 3 to 6. Likewise _gfortran_caf_deregister from 2 to 3, builtin_malloc from 1 to 4 and builtin_memcpy|= MEM from 2 to 5. * gfortran.dg/finalize_28.f90: Increase builtin_free count from 3 to 6. * gfortran.dg/move_alloc_15.f90: Increase builtin_free and builtin_malloc counts from 11 to 14. * gfortran.dg/typebound_proc_27.f03: Increase builtin_free count from 7 to 10. Likewise builtin_malloc from 12 to 15. Added: trunk/gcc/testsuite/gfortran.dg/class_65.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 trunk/gcc/testsuite/gfortran.dg/auto_dealloc_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_lib_realloc_1.f90 trunk/gcc/testsuite/gfortran.dg/finalize_28.f90 trunk/gcc/testsuite/gfortran.dg/move_alloc_15.f90 trunk/gcc/testsuite/gfortran.dg/typebound_proc_27.f03
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #12 from Tom de Vries ---
Author: vries
Date: Sun Nov 5 09:58:27 2017
New Revision: 254425
URL: https://gcc.gnu.org/viewcvs?rev=254425&root=gcc&view=rev
Log:
Remove semicolon after do {} while (0) in DEF_SANITIZER_BUILTIN
2017-11-05 Tom de Vries
PR other/82784
* asan.c (DEF_SANITIZER_BUILTIN_1): Factor out of ...
(DEF_SANITIZER_BUILTIN): ... here.
(initialize_sanitizer_builtins): Use DEF_SANITIZER_BUILTIN_1 instead of
DEF_SANITIZER_BUILTIN in if stmt. Add missing semicolon.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #8 from Tom de Vries ---
Author: vries
Date: Sun Nov 5 09:57:43 2017
New Revision: 254421
URL: https://gcc.gnu.org/viewcvs?rev=254421&root=gcc&view=rev
Log:
[graphite] Remove semicolon after do {} while (0) in DEBUG_PRINT
2017-11-05 Tom de Vries
PR other/82784
* graphite-scop-detection.c (DEBUG_PRINT): Remove semicolon after
"do {} while (0)".
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-scop-detection.c
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #9 from Tom de Vries ---
Author: vries
Date: Sun Nov 5 09:57:53 2017
New Revision: 254422
URL: https://gcc.gnu.org/viewcvs?rev=254422&root=gcc&view=rev
Log:
[fortran] Remove semicolon after do {} while (0) in match macros
2017-11-05 Tom de Vries
PR other/82784
* parse.c (match, matcha, matchs, matcho, matchds, matchdo): Remove
semicolon after "do {} while (0)".
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #11 from Tom de Vries ---
Author: vries
Date: Sun Nov 5 09:58:16 2017
New Revision: 254424
URL: https://gcc.gnu.org/viewcvs?rev=254424&root=gcc&view=rev
Log:
[libcpp] Remove semicolon after do {} while (0) in BUF_APPEND
2017-11-05 Tom de Vries
PR other/82784
* lex.c (BUF_APPEND): Remove semicolon after
"do {} while (0)".
Modified:
trunk/libcpp/ChangeLog
trunk/libcpp/lex.c
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784 --- Comment #10 from Tom de Vries --- Author: vries Date: Sun Nov 5 09:58:05 2017 New Revision: 254423 URL: https://gcc.gnu.org/viewcvs?rev=254423&root=gcc&view=rev Log: Remove semicolon after ASM_OUTPUT_BEFORE_CASE_LABEL macro body 2017-11-05 Tom de Vries PR other/82784 * config/elfos.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Remove semicolon after macro body. (ASM_OUTPUT_CASE_LABEL): Add semicolon after ASM_OUTPUT_BEFORE_CASE_LABEL call. * config/arc/arc.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Remove semicolon after macro body. * config/m68k/m68kelf.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Same. * config/mips/mips.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Same. * config/v850/v850.h (ASM_OUTPUT_BEFORE_CASE_LABEL): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arc/arc.h trunk/gcc/config/elfos.h trunk/gcc/config/m68k/m68kelf.h trunk/gcc/config/mips/mips.h trunk/gcc/config/v850/v850.h
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #7 from Tom de Vries ---
Author: vries
Date: Sun Nov 5 09:57:30 2017
New Revision: 254420
URL: https://gcc.gnu.org/viewcvs?rev=254420&root=gcc&view=rev
Log:
[libquadmath] Remove semicolon after do {} while (0) in MPN_MUL_N_RECURSE
2017-11-05 Tom de Vries
PR other/82784
* printf/gmp-impl.h (MPN_MUL_N_RECURSE): Remove semicolon after
"do {} while (0)".
Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/printf/gmp-impl.h
[Bug other/82784] Remove semicolon after "do {} while (0)" macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82784
--- Comment #6 from Tom de Vries ---
Author: vries
Date: Sun Nov 5 09:57:17 2017
New Revision: 254419
URL: https://gcc.gnu.org/viewcvs?rev=254419&root=gcc&view=rev
Log:
[libsanitizer] Remove semicolon after do {} while (0) in macro body
2017-11-05 Tom de Vries
PR other/82784
* asan/asan_poisoning.cc (CHECK_SMALL_REGION): Remove semicolon after
"do {} while (0)".
* lsan/lsan_common.cc (LOG_POINTERS, LOG_THREADS): Same.
Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/asan_poisoning.cc
trunk/libsanitizer/lsan/lsan_common.cc
