[Bug d/91916] Maybe a dead code in socket.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91916 --- Comment #3 from ibuclaw at gcc dot gnu.org --- (In reply to Martin Liška from comment #2) > @Iain: ping^2 Hi, sorry for the late pick-up, I guess the dead code must come from this line. https://github.com/dlang/phobos/blob/25f38e4b7f2eb4814198ef38dbc44b6ac7b92f78/std/socket.d#L3248-L3251 And whoever wrote the std.socket interface decided to mix multiple different C enums into one type, so of course there'll be a clash between values. It does serve to confuse if someone passes a non-time related socket option to that particular get/setOption override, as the exception message will point to another value than the one they have actually passed. There is otherwise no risk of there actually being any problem in production code.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 --- Comment #3 from Toon Moene --- The patch indeed solved the test case. Thanks !
[Bug c++/93632] New: Build time regression in 9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93632 Bug ID: 93632 Summary: Build time regression in 9.2.1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeanmichael.celerier at gmail dot com Target Milestone: --- Created attachment 47797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47797&action=edit preprocessed source of the buggy file Hello, The following source code takes almost two minutes to build on GCC 9.2.1 - it's a boost.spirit parser./ https://github.com/OSSIA/score/blob/master/src/plugins/score-lib-state/State/ExpressionParser.cpp it only takes two seconds on clang and on previous GCC versions (at least 8.0 and 9.1.0, not sure about 9.2.0). Attached a preprocessed source - my build options are $ g++ -fno-stack-protector -g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -Wno-unused-parameter -Wno-unknown-pragmas -Wnon-virtual-dtor -pedantic -Woverloaded-virtual -pipe -Wno-missing-declarations -Wredundant-decls -Werror=return-type -Werror=trigraphs -Wno-gnu-string-literal-operator-template -Wno-missing-braces -Wmissing-field-initializers -Wno-gnu-statement-expression -Wno-four-char-constants -ftemplate-backtrace-limit=0 -O0 -fdebug-types-section -ggnu-pubnames -ggdb -fPIC -std=gnu++2a -c error.cpp If you want to setup a build from the git repo to reproduce, it's a matter (on archlinux with qt and boost) of : git submodule update --init --recursive cd score && mkdir build && cd build cmake .. -DSCORE_CONFIGURATION=developer -DCMAKE_BUILD_TYPE=Debug this will create a compile_commands.json with the ExpressionParser.cpp command line.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #3 from Thomas Koenig --- Update: I am not convinced that the error message by helgrind is correct. I have been able to reproduce the error in the meantime, by running the test case with #! /bin/sh set -e while true do for a in `seq 1 1000` do ./a.out done echo -n . done which aborts after quite a few thousands of invocations of a.out (65 thousand is the largest I have seen so far).
[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93630 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jakub Jelinek --- Ah, I see, on the trunk (and 9 branch) this has been introduced with r9-6851-g187c6369c0b4c7e013fdbe9eb08d098166359056 and fixed with r10-2213-gb74f15a88ee1a2b96784803f0e38c386796ee704 and on the 9 branch with: r9-7634-g1a095ab0a97169cc0a1bac562041e04c11afa14b *** This bug has been marked as a duplicate of bug 90947 ***
[Bug c++/90947] [9 Regression] Simple lookup table of array of strings is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90947 Jakub Jelinek changed: What|Removed |Added CC||rodrigorivascosta at gmail dot com --- Comment #16 from Jakub Jelinek --- *** Bug 93630 has been marked as a duplicate of this bug. ***
[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:79ab8c4321b2dc940bb706a7432a530e26f0df1a
commit r10-6522-g79ab8c4321b2dc940bb706a7432a530e26f0df1a
Author: Jakub Jelinek
Date: Sat Feb 8 10:59:40 2020 +0100
i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]
On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.
I don't have means of testing it either.
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15
(low
128-bits only) are call preserved.
We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */
typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
V c;
{
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
}
foo ();
{
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
}
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).
The other parts are I guess mainly about SEH. Consider e.g.
void
foo (void)
{
register double x __asm ("xmm14");
register double y __asm ("xmm18");
asm ("" : "=x" (x));
asm ("" : "=v" (y));
x += y;
y += x;
asm ("" : : "x" (x));
asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file "abcdeq.c"
.text
.align 16
.globl foo
.deffoo;.scl2; .type 32; .endef
.seh_proc foo
foo:
subq$40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm%xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm%xmm18, 16
.seh_endprologue
vaddsd %xmm18, %xmm14, %xmm14
vaddsd %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq$40, %rsp
ret
.seh_endproc
.ident "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782
2020-02-08 Uroš Bizjak
Jakub Jelinek
PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.
* gcc.target/i386/pr65782.c: New test.
Co-authored-by: Uroš Bizjak
[Bug c++/93633] New: ICE on consteval virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93633
Bug ID: 93633
Summary: ICE on consteval virtual
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tyker at outlook dot com
Target Milestone: ---
I know that consteval virtual is not yet supported. but not crashing seems like
that bare minimum.
gcc trunk currently crashes on the following code.
struct A {
consteval virtual int f() {
return 1;
}
};
struct B : A {
consteval virtual int f() {
return 0;
}
};
consteval int f() {
A* a = new B();
return a->f();
}
int main() {
return f();
}
https://godbolt.org/z/TR5tLZ
[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93582 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- I'll play with it next week.
[Bug c++/93633] ICE on consteval virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93633
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-02-08
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
It ICEs even without the consteval virtual:
struct A {
virtual int foo () { return 1; }
};
struct B : A {
virtual int foo () { return 0; }
};
consteval int
foo ()
{
A *a = new B ();
return a->foo ();
}
int
main ()
{
return foo ();
}
At that point, I think we need to diagnose call to non-constexpr method, with
constexpr virtual ... it ICEs too. I'll look at it.
[Bug c++/93633] ICE on consteval virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93633 --- Comment #2 from Jakub Jelinek --- Created attachment 47798 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47798&action=edit gcc10-pr93633.patch Untested fix. BTW, your #c0 testcase is not valid, because the new doesn't have corresponding delete.
[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from H.J. Lu --- I got FAIL: g++.dg/eh/sighandle.C with -m32 on Linux/CET machine There is a restore token on shadow stack for signal handler. The restore token is 8 byte and aligned to 8 bytes for both i386 and x86-64. We need to handle the i386 case carefully.
[Bug target/81652] [meta-bug] -fcf-protection=full bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652 Bug 81652 depends on bug 85334, which changed state. Bug 85334 Summary: Shadow stack isn't unwound properly through signal handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #14 from Giulio Benetti --- Hi Ji, thanks for providing this patch, it fixes the problem.
[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93549 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c7c09af8ef0fe6671c7733d4d67bb73ecf10fc1b commit r10-6523-gc7c09af8ef0fe6671c7733d4d67bb73ecf10fc1b Author: Jakub Jelinek Date: Sat Feb 8 15:11:28 2020 +0100 c++: Handle CONSTRUCTORs without indexes in find_array_ctor_elt [PR93549] My change * typeck2.c (store_init_value): Don't call cp_fully_fold_init on initializers of automatic non-constexpr variables in constexpr functions. - value = cp_fully_fold_init (value); + /* Don't fold initializers of automatic variables in constexpr functions, + that might fold away something that needs to be diagnosed at constexpr + evaluation time. */ + if (!current_function_decl + || !DECL_DECLARED_CONSTEXPR_P (current_function_decl) + || TREE_STATIC (decl)) +value = cp_fully_fold_init (value); from the constexpr new change apparently broke the following testcase. When handling COND_EXPR, we build_vector_from_val, however as the argument we pass to it is not an INTEGER_CST/REAL_CST, but that wrapped in a NON_LVALUE_EXPR location wrapper, we end up with a CONSTRUCTOR and as it is middle-end that builds it, it doesn't bother with indexes. The cp_fully_fold_init call used to fold it into VECTOR_CST in the past, but as we intentionally don't invoke it anymore as it might fold away something that needs to be diagnosed during constexpr evaluation, we end up evaluating ARRAY_REF into the index-less CONSTRUCTOR. The following patch fixes the ICE by teaching find_array_ctor_elt to handle CONSTRUCTORs without indexes (that itself could be still very efficient) and CONSTRUCTORs with some indexes present and others missing (the rules are that if the index on the first element is missing, then it is the array's lowest index (in C/C++ 0) and if other indexes are missing, they are the index of the previous element + 1). Here is a new version, which assumes CONSTRUCTORs with all or none indexes and for CONSTRUCTORs without indexes performs the verification for flag_checking directly in find_array_ctor_elt. For CONSTRUCTORs with indexes, it doesn't do the verification of all elts, because some CONSTRUCTORs can be large, and it "verifies" only what it really needs - if all elts touched during the binary search have indexes, that is actually all we care about because we are sure we found the right elt. It is just if we see a missing index we need assurance that all are missing to be able to directly access it. The assumption then simplifies the patch, for no index CONSTRUCTORs we can use direct access like for CONSTRUCTORs where last elt index is equal to the elt position. If we append right after the last elt, we just should clear the index so that we don't violate the assumption, and if we need a gap between the elts and the elt to be added, we need to add indexes. 2020-02-08 Jakub Jelinek PR c++/93549 * constexpr.c (find_array_ctor_elt): If last element has no index, for flag_checking verify all elts have no index. If i is within the elts, return it directly, if it is right after the last elt, append if NULL index, otherwise force indexes on all elts. (cxx_eval_store_expression): Allow cep->index to be NULL. * g++.dg/ext/constexpr-pr93549.C: New test.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #141 from dave.anglin at bell dot net --- On 2020-02-07 8:04 p.m., peter.bisroev at groundlabs dot com wrote: > Program received signal SIGSEGV, Segmentation fault > si_code: 1 - SEGV_MAPERR - Address not mapped to object. > 0x79e7a40 in () > (gdb) bt > #0 0x79e7a40 in () > warning: Attempting to unwind past bad PC 0x79e7a40 > #1 0x6c81c20 in > vector_builder::try_npatterns(unsigned > int)+0x2a0 () I'm not very familiar with selftest but it looks like the code has branched to a bad location in frame 1. Disassemble code around 0x6c81c20. Put a break before bad branch and try to figure out what's going wrong. Something is miscompiled. Probably it's in vector_builder.
[Bug middle-end/93634] New: Improving modular calculations (e.g. divisibility tests).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93634
Bug ID: 93634
Summary: Improving modular calculations (e.g. divisibility
tests).
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
Consider:
bool f(unsigned n) { return n % 6 == 4; }
at -O3 the code generated for x86_64 is
mov%edi,%eax
mov$0xaaab,%edx
imul %rdx,%rax
shr$0x22,%rax
lea(%rax,%rax,2),%eax
add%eax,%eax
sub%eax,%edi
cmp$0x4,%edi
sete %al
retq
whereas it could be
sub$0x4,%edi
imul $0xaaab,%edi,%edi
ror%edi
cmp$0x2aa9,%edi
setbe %al
retq
Notice the later is quite similar to what gcc generates for n % 6 == 3:
imul $0xaaab,%edi,%edi
sub$0x1,%edi
ror%edi
cmp$0x2aaa,%edi
setbe %al
retq
It's true that there's a small mathematical difference for the cases r <= 3 and
r >= 4 but not enough to throw away the faster algorithm. I reckon this is not
obvious and I refer to
https://accu.org/var/uploads/journals/Overload154.pdf#page=13 which presents
the overall idea and some benchmarks. In addition, it makes some comments on
gcc's generated code for other cases of n % d == r. References therein provide
mathematical proofs and extra benchmarks.
FWIW:
1) This relates to bug 82853 and bug 12849 and to a lesser extend bug 89845.
2) Specifically, it confirms the idea (for unsigned integers) described by Orr
Shalom Dvory in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82853#c33
[Bug middle-end/93634] Improving modular calculations (e.g. divisibility tests).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93634 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 Giulio Benetti changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Giulio Benetti --- I mark this bug as resolved by: https://gcc.gnu.org/bugzilla/attachment.cgi?id=47794
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #16 from Andrew Pinski --- (In reply to Giulio Benetti from comment #15) > I mark this bug as resolved by: > https://gcc.gnu.org/bugzilla/attachment.cgi?id=47794 The patch has not been applied to the sources yet.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #11 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:173c8defa6e82f1bc003173b6ee1e4eb2830d1c2 commit r10-6526-g173c8defa6e82f1bc003173b6ee1e4eb2830d1c2 Author: Jason Merrill Date: Fri Feb 7 16:28:20 2020 -0500 c++: Preserve location in maybe_constant_value. If cxx_eval_outermost_constant_expr doesn't change the argument, we really shouldn't unshare it when we try to fold it again. PR c++/92852 * constexpr.c (maybe_constant_value): Don't unshare if the cached value is the same as the argument.
[Bug c++/90691] [9/10 regression] -Wsign-compare false-positive with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90691 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:aaa26bf496a646778ac861aed124d960b5bf549f commit r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f Author: Jason Merrill Date: Sun Jan 26 22:58:32 2020 -0500 c++: Use constexpr to avoid wrong -Wsign-compare (PR90691). We would like to do constexpr evaluation to avoid false positives on warnings, but constexpr evaluation can involve function body copying that changes DECL_UID, which breaks -fcompare-debug. So let's remember that we need to avoid that. PR c++/90691 * expr.c (fold_for_warn): Call maybe_constant_value. * constexpr.c (struct constexpr_ctx): Add uid_sensitive field. (maybe_constant_value): Add uid_sensitive parm. (get_fundef_copy): Don't copy if it's true. (cxx_eval_call_expression): Don't instantiate if it's true. (cxx_eval_outermost_constant_expr): Likewise.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #17 from Giulio Benetti --- (In reply to Andrew Pinski from comment #16) > (In reply to Giulio Benetti from comment #15) > > I mark this bug as resolved by: > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=47794 > > The patch has not been applied to the sources yet. Oops, sorry, I'm not very used to bugzilla/gcc. Thanks again, for providing that patch.
[Bug target/92518] [10 regression] ppc rounding tests fail after r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518
--- Comment #5 from Segher Boessenkool ---
Actually, this is simply wrong.
===
;; Function round_double_uint (round_double_uint, funcdef_no=5, decl_uid=2879,
cgraph_uid=3, symbol_order=2)
round_double_uint (double a)
{
int _4;
double _5;
;; basic block 2, loop depth 0
;;pred: ENTRY
_4 = (int) a_1(D);
_5 = (double) _4;
return _5;
;;succ: EXIT
}
===
It is wrong in gimple already (should be unsigned int, not int).
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #142 from The Written Word --- (In reply to Peter Bisroev from comment #133) > The tests are from are binutils-2.32. > > - gas.log > FAIL: .file file names > FAIL: .file file names ordering > FAIL: .equ redefinitions (ELF) > FAIL: .set with expression > FAIL: good .bss / .struct data allocation directives > FAIL: gas/elf/missing-build-notes > FAIL: ia64 xdata (ilp32) > FAIL: ia64 unwind descriptors > > - binutils.log (they look like gas related failures) > FAIL: assembler generated build notes > FAIL: --localize-hidden test 1 > FAIL: readelf -S bintest > > Are any of these tests critical and would you want me to look at them in > more detail? I get the same test failures with binutils-2.32.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #143 from The Written Word --- (In reply to Peter Bisroev from comment #131) > ... > > After a bit of digging around looks > like my ar and ranlib binaries from binutils are not working properly. For > example: > > $ ./ar --help > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module > '/usr/lib/hpux32/libl.so.1'. > /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module > '/usr/lib/hpux32/libl.so.1'. > Killed > > But those symbols are present in libl.so from what I can see. For now I am > still using HP's ar and ranlib, will take a look into what is going on with > binutils ar and ranlib a bit later. We solve this by setting LEXLIB in the environment to a static verison of the flex library. You could probably also set LEXLIB="-L -Wl,+b, -lfl".
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #144 from The Written Word --- (In reply to Peter Bisroev from comment #135) > I just had a chance to do some testing tonight. So attempting to bootstrap > 8.3.0 in stock configuration gives PCREL21B style errors in stage1 as have > been shown before. If I compile stage1 with '-O2' only, stage1 compiles, but > straight away we get > -- > /home/pbisroev/src/build/./gcc/xgcc -B/home/pbisroev/src/build/./gcc/ -xc > -nostdinc /dev/null -S -o /dev/null > -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests > cc1: internal compiler error: Segmentation fault > -- This succeeds with our gcc-8.3.0 build: $ /opt/build/china/gcc-8.3.0/.obj/prev-gcc/xgcc -B/opt/build/china/gcc-8.3.0/.obj/prev-gcc -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/opt/build/china/gcc-8.3.0/gcc/testsuite/selftests -fself-test: 40028 pass(es) in 1.02 seconds We have a build running that seems to be going well. We are using gcc-4.9.4 to build 8.3.0. I will attach the current patch set we are building against.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 The Written Word changed: What|Removed |Added Attachment #46623|0 |1 is obsolete|| --- Comment #145 from The Written Word --- Created attachment 47799 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47799&action=edit gcc-8.3.0 patches v2 v2 of our patch set.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #4 from Thomas Koenig --- Created attachment 47800 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47800&action=edit Possible fix Here is something that Nicolas and I came up with. The theory is that pthread_cond_wait can get a spurious interrupt once in a blue moon which previosly led to the macro becoming a no-op. I have tested this to around 8 Million invocations of the test program, but this is not a guarantee... Incidentially, this also appears to fix the issue that helgrind reported. It passes regression testing. Is there a reasonable way to test this further?
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #5 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #4) > Created attachment 47800 [details] > Possible fix > > Here is something that Nicolas and I came up with. The theory is that > pthread_cond_wait can get a spurious interrupt once in a blue moon which > previosly led to the macro becoming a no-op. > > I have tested this to around 8 Million invocations of the test program, but > this is not a guarantee... > > Incidentially, this also appears to fix the issue that helgrind reported. > It passes regression testing. > > Is there a reasonable way to test this further? Awesome sleuthing. I think we could run your test case on a PowerPC64 either in the gcc compile farm for at OSU (Oregon State University) I will check to see if I can still get into the OSU machine.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #6 from Jerry DeLisle --- Forgot to mention. Did you test with or without Janne's patch here: https://gcc.gnu.org/ml/fortran/2020-01/msg00158.html It could be related or influence this.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #18 from CVS Commits --- The master branch has been updated by Jim Wilson : https://gcc.gnu.org/g:b780f68e025b2cf5631183e199ebf672ea463af6 commit r10-6528-gb780f68e025b2cf5631183e199ebf672ea463af6 Author: Jim Wilson Date: Sat Feb 8 13:57:36 2020 -0800 RISC-V: Improve caller-save code generation. Avoid paradoxical subregs when caller save. This reduces stack frame size due to smaller loads and stores, and more frequent rematerialization. PR target/93532 * config/riscv/riscv.h (HARD_REGNO_CALLER_SAVE_MODE): Define.
[Bug target/92518] [10 regression] ppc rounding tests fail after r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518 --- Comment #6 from Segher Boessenkool --- It is still okay in ppc-round.c.048t.local-fnsummary2 but it is wrong in ppc-round.c.088t.fixup_cfg3 (the pass immediately after it, at -O2).
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 Jim Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Jim Wilson --- Patch applied to mainline. This is just a minor optimization for gcc-10 as a combiner patch between gcc-8 and gcc-9 reduces register pressure enough to prevent the hang. Hence there is no real need for the patch in gcc-9. The patch might be useful in gcc-8, but the problem is hard to reproduce, buildroot is the only one that ran into the problem, and they can always add the patch to their tree, so not clear if we really need it on the gcc-8 branch.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #20 from Jim Wilson --- Thanks for confirming that it solves the buildroot build problem. My gcc mainline g++ test failure turned out to be a thread related issue with qemu cross testing. The testcase works always on hardware, but fails maybe 10-20% of the time when run under qemu. RISC-V qemu is known to still have a few bugs in this area, though they might already be fixed in newer qemu versions than what I have.
[Bug target/92518] [10 regression] ppc rounding tests fail after r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518 --- Comment #7 from Segher Boessenkool --- Ah, -fdump-ipa-all-all . So it seems like ppc-round.c.072i.icf is what is wrong; it says Equals called for: round_float_uint/3:round_float_int/1 with result: true Equals called for: round_double_uint/2:round_double_int/0 with result: true (that is the first thing wrong I see).
[Bug fortran/93484] [8/9/10 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120 since r7-4028-g87c9fca50cbe7ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93484 --- Comment #2 from kargl at gcc dot gnu.org --- This patch is against svn r280157. Whomever commit the patch needs to convert the example code into a testcase. Index: gcc/fortran/match.c === --- gcc/fortran/match.c (revision 280157) +++ gcc/fortran/match.c (working copy) @@ -,9 +,9 @@ gfc_match_type_spec (gfc_typespec *ts) found: - m = gfc_match_init_expr (&e); + m = gfc_match_expr (&e); if (m == MATCH_NO || m == MATCH_ERROR) - return MATCH_NO; + return m; /* If a comma appears, it is an intrinsic subprogram. */ gfc_gobble_whitespace ();
[Bug target/92923] __builtin_vec_xor() causes subregs to be used when not using V4SImode vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92923 --- Comment #5 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:4b39d801b2698d0f756231f6f8fa0be5a36f0c05 commit r10-6529-g4b39d801b2698d0f756231f6f8fa0be5a36f0c05 Author: Peter Bergner Date: Sat Feb 8 17:33:08 2020 -0600 rs6000: Fix testsuite fallout from previous fix. [PR93136] The fix for PR target/92923 exposed some test cases with fragile scan-assembler-times counting. Split the test cases into smaller functions, which allows less chance of optimizations causing slight instruction count numbers. gcc/testsuite/ PR target/93136 * gcc.dg/vmx/ops.c: Add -flax-vector-conversions to dg-options. * gcc.target/powerpc/vsx-vector-6.h: Split tests into smaller functions. * gcc.target/powerpc/vsx-vector-6.p7.c: Adjust scan-assembler-times regex directives. Adjust expected instruction counts. * gcc.target/powerpc/vsx-vector-6.p8.c: Likewise. * gcc.target/powerpc/vsx-vector-6.p9.c: Likewise.
[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136 --- Comment #4 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:4b39d801b2698d0f756231f6f8fa0be5a36f0c05 commit r10-6529-g4b39d801b2698d0f756231f6f8fa0be5a36f0c05 Author: Peter Bergner Date: Sat Feb 8 17:33:08 2020 -0600 rs6000: Fix testsuite fallout from previous fix. [PR93136] The fix for PR target/92923 exposed some test cases with fragile scan-assembler-times counting. Split the test cases into smaller functions, which allows less chance of optimizations causing slight instruction count numbers. gcc/testsuite/ PR target/93136 * gcc.dg/vmx/ops.c: Add -flax-vector-conversions to dg-options. * gcc.target/powerpc/vsx-vector-6.h: Split tests into smaller functions. * gcc.target/powerpc/vsx-vector-6.p7.c: Adjust scan-assembler-times regex directives. Adjust expected instruction counts. * gcc.target/powerpc/vsx-vector-6.p8.c: Likewise. * gcc.target/powerpc/vsx-vector-6.p9.c: Likewise.
[Bug target/93136] [10 regression] gcc.dg/vmx/ops.c and several other test break after r279772
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93136 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Peter Bergner --- Fixed.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #146 from The Written Word --- (In reply to The Written Word from comment #142) > (In reply to Peter Bisroev from comment #133) > > The tests are from are binutils-2.32. > > > > - gas.log > > FAIL: .file file names > > FAIL: .file file names ordering > > FAIL: .equ redefinitions (ELF) > > FAIL: .set with expression > > FAIL: good .bss / .struct data allocation directives > > FAIL: gas/elf/missing-build-notes > > FAIL: ia64 xdata (ilp32) > > FAIL: ia64 unwind descriptors > > > > - binutils.log (they look like gas related failures) > > FAIL: assembler generated build notes > > FAIL: --localize-hidden test 1 > > FAIL: readelf -S bintest > > > > Are any of these tests critical and would you want me to look at them in > > more detail? > > I get the same test failures with binutils-2.32. For binutils-2.25.1, test failures are: $ grep FAIL gas.log FAIL: .file file names FAIL: .equ redefinitions (ELF) FAIL: .set with expression FAIL: ia64 psn FAIL: ia64 xdata (ilp32) FAIL: ia64 unwind descriptors FAIL: lns-duplicate FAIL: lns-common-1 For binutils-2.26, test failures are: $ grep FAIL gas.log FAIL: .file file names FAIL: .equ redefinitions (ELF) FAIL: .set with expression FAIL: ia64 unwind descriptors FAIL: lns-duplicate FAIL: lns-common-1
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 --- Comment #12 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:c2a4bf2d6edde8b148421668a4c07c844b994271 commit r10-6530-gc2a4bf2d6edde8b148421668a4c07c844b994271 Author: Andrew Pinski Date: Sat Feb 8 15:57:54 2020 + aarch64: fix strict alignment for vector load/stores (PR 91927) Hi, The problem here is that the vector mode version of movmisalign was only conditionalized on if SIMD was enabled instead of being also conditionalized on STRICT_ALIGNMENT too. Applied as pre-approved in the bug report by Richard Sandiford after a bootstrap/test on aarch64-linux-gnu. Thanks, Andrew Pinski ChangeLog: PR target/91927 * config/aarch64/aarch64-simd.md (movmisalign): Check STRICT_ALIGNMENT also. testsuite/ChangeLog: PR target/91927 * gcc.target/aarch64/pr91927.c: New testcase.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 --- Comment #4 from David Malcolm --- (In reply to Toon Moene from comment #3) > The patch indeed solved the test case. > Thanks ! Thanks for confirming it. Any chance you could review the preparatory patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00395.html which adds an analyzer subdirectory to gfortran.dg in the testsuite?
[Bug target/92518] [10 regression] ppc rounding tests fail after r278207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92518 --- Comment #8 from Segher Boessenkool --- I confirm this is caused by r278207.
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #13 from Andrew Pinski --- Fixed for GCC 10. Note I am not backporting this change; if someone else wants to backport it, I would be ok with that.
[Bug tree-optimization/55177] missed optimizations with __builtin_bswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177
--- Comment #20 from Andrew Pinski ---
So the original testcase shows there are missing other bitop related
optimizations on the tree level and conversions.
I have two patches which fix the original issue.
The first patch also fixes:
unsigned foo(unsigned x, int b)
{
int a = x;
a &= b;
x = a;
x |= b;
return x;
}
--- CUT ---
The problem here is:
a_3 = (int) x_2(D);
a_5 = a_3 & b_4(D);
x_6 = (unsigned int) a_5;
is not optimized to:
_7 = (unsigned int) b_4(D);
x_6 = _6 & x_2(D);
Which shows up in testcase in comment #0:
_2 = __builtin_bswap32 (x.0_1);
a_6 = (int) _2;
a_7 = a_6 & 1515936861;
a.1_3 = (unsigned int) a_7;
_4 = __builtin_bswap32 (a.1_3);
Fixing the bitop with convert, we get rid of the two byteswaps in comment #0.
diff --git a/gcc/match.pd b/gcc/match.pd
index 363006e28fd..d0258a19534 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1393,7 +1393,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
/* Or if the precision of TO is not the same as the precision
of its mode. */
|| !type_has_mode_precision_p (type)))
- (convert (bitop @0 (convert @1))
+ (convert (bitop @0 (convert @1)
+ (simplify
+ (convert (bitop:c (nop_convert @0) @1))
+ (if (tree_nop_conversion_p (type, TREE_TYPE (@1))
+ && types_match (type, TREE_TYPE (@0)))
+ (bitop @0 (convert @1)
(for bitop (bit_and bit_ior)
rbitop (bit_ior bit_and)
[Bug c/85957] i686: Integers appear to be different, but compare as equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957 --- Comment #13 from Vincent Lefèvre --- (In reply to Rich Felker from comment #12) > [...] and making the floating point results even more semantically incorrect > (double-rounding all over the place, mismatching FLT_EVAL_METHOD==2) No problems: FLT_EVAL_METHOD==2 means "evaluate all operations and constants to the range and precision of the long double type", which is what really occurs. The consequence is indeed double rounding when storing in memory, but this can happen at *any* time even without -ffloat-store (due to spilling), because you are never sure that registers are still available; see some reports in bug 323. Double rounding can be a problem with some codes, but this just means that the code is not compatible with FLT_EVAL_METHOD==2. For some floating-point algorithms, double rounding is not a problem at all, while keeping a result in extended precision will make them fail.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #8 from Vincent Lefèvre --- (In reply to Rich Felker from comment #7) > Note that such an option would be nice to have anyway, for arbitrary > functions, since it's necessary for being able to call code that was > compiled with -fexcess-precision=fast from code that can't accept the > non-conforming/optimizer-unsafe behavior and safely use the return value. It > should probably be an attribute, with a flag to set the global default. For > example, __attribute__((__returns_excess_precision__)). If you're talking about arbitrary functions, they may have been implemented in languages other than C, anyway. So that's an ABI issue. If the ABI allows excess precision, then GCC must assume that excess precision is possible.
[Bug c/85957] i686: Integers appear to be different, but compare as equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85957 --- Comment #14 from Rich Felker --- > No problems: FLT_EVAL_METHOD==2 means "evaluate all operations and constants > to the range and precision of the long double type", which is what really > occurs. The consequence is indeed double rounding when storing in memory, but > this can happen at *any* time even without -ffloat-store (due to spilling), > because you are never sure that registers are still available; see some > reports in bug 323. It sounds like you misunderstand the standard's requirements on, and GCC's implementation of, FLT_EVAL_METHOD==2/excess-precision. The availability of registers does not in any way affect the result, because when expressions are evaluated with excess precision, any spills must take place in the format of float_t or double_t (long double) and are thereby transparent to the application. The buggy behavior prior to -fexcess-precision=standard (and now produced with -fexcess-precision=fast which is default in "gnu" modes) spills in the nominal type, producing nondeterministic results that depend on the compiler's transformations and that lead to situations like this bug (where the optimizer has been lied to that two expressions are equal, but they're not). > Double rounding can be a problem with some codes, but this just means that > the code is not compatible with FLT_EVAL_METHOD==2. For some floating-point > algorithms, double rounding is not a problem at all, while keeping a result > in extended precision will make them fail. With standards-conforming behavior, the rounding of an operation and of storage to an object of float/double type are discrete roundings and you can observe and handle the intermediate value between them. With -ffloat-store, every operation inherently has a double-rounding attached to it. This behavior is non-conforming but at least deterministic, and is what I was referring to in my previous comment. But I think this is largely a distraction from the issue at hand; I was only pointing out that -ffloat-store is a workaround, but one with its own (often severe) problems.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 --- Comment #9 from Rich Felker --- Indeed, I don't think the ABI says anything about this; a bug against the psABI should probably be opened.
[Bug fortran/93635] New: Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 Bug ID: 93635 Summary: Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- User programming error produces an ICE instead of the expected error message if trying to allocate equivalences variables. Only occurs if variables are also in a NAMELIST group ## MINIMAL REPRODUCER program boom implicit none character(len=:),allocatable :: r,rel namelist /args/ r,rel equivalence(r,rel) !! USER ERROR: NOT ALLOWED FOR ALLOCATABLES allocate(character(len=1024) :: r) end program boom ## RESULTING ERROR boom.f90:5:0: allocate(character(len=1024) :: r) internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:2723 Please submit a full bug report, ERROR IF NAMELIST STATEMENT REMOVED (a correct message to the user that code has an error) equivalence(r,rel) ! it is not legal to equivalence allocatable variables 1 Error: EQUIVALENCE attribute conflicts with ALLOCATABLE attribute in 'r' at (1)
