[Bug preprocessor/83173] C preprocessor generates incorrect linemarkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173 --- Comment #8 from Eric Gallager --- (In reply to Pádraig Brady from comment #7) > Have been running with these patches on an extremely large code base for the > last few months, without issue Can you say which code base?
[Bug target/85860] [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860 --- Comment #3 from Arseny Solokha --- I cannot reproduce it anymore w/ gcc-9.0.0-alpha20181021 snapshot (r265361). Seems to be fixed on the trunk w/ recent LRA-related patches.
[Bug middle-end/21161] [6/7/8/9 Regression] "clobbered by longjmp" warning ignores the data flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161 Eric Gallager changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #18 from Eric Gallager --- (In reply to Jeffrey A. Law from comment #12) > I've got something that is working on most targets. I'm still refining a > bit, but I'm pretty confident we'll be able to fix in this cycle. > > As expected scanning RTL from the setjmp point to figure out where the > longjmp will go (so that we can use the live-in set at the longjmp target > rather than the live set at the setjmp point) is a bit hairy. > > It's almost certainly the case that the scanning is not going to work on all > targets. For example MIPS inserts an unspec sequence to fiddle the GOT > after the call and I really don't want to ignore an insn we don't > understand. But again, what I've currently got works on most targets and > there's still some refinements to do to improve coverage. Changing status to ASSIGNED, then, since you made yourself the assignee
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 68836, which changed state. Bug 68836 Summary: GCC can't properly emit debug info for function arguments in a back-trace when using -Og https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID
[Bug debug/68836] GCC can't properly emit debug info for function arguments in a back-trace when using -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68836 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Eric Gallager --- (In reply to Richard Biener from comment #1) > Without a (guality?) testcase there's nothing to do here. Well, still no testcase, guality or otherwise, so closing due to being in WAITING for so long.
[Bug libffi/28036] libffi executable stack (missing .note.GNU-stack on .o files)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036 --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > (In reply to Eric Gallager from comment #4) > > Seeing as this bug is about how libffi is used by gcj, and gcj has been > > removed from gcc, does it still need to stay open? Or does it affect other > > users of libffi in gcc, too? (e.g. go) > > Go uses libffi still. Yeah but does Go care whether libffi's stack is executable or not?
[Bug c++/87760] New: Unable to delete overloads of std::memset on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87760
Bug ID: 87760
Summary: Unable to delete overloads of std::memset on arm
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
I know this is technically speaking undefined behavior (not allowed to change
things inside namespace std), and thus not a bug but more a feature request.
Since all version of gcc I've tested (x86 and x64), clang, icc and msvc accept
following code, I think it makes sense to open this bug because it would be
nice for gcc to be more consistent, since it's just gcc on arm rejecting it.
#include
namespace std{
void* memset(void*, std::size_t count, int ch) = delete;
}
struct foo{ // POD
int a;
int* b;
char c;
};
int main() {
foo b[10];
std::memset(, 0, sizeof b);
std::memset(, 0u, sizeof b);
}
This code on arm64 fails to compile with following error message:
:4:7: error: deleted definition of 'void* std::memset(void*,
std::size_t, int)'
void* memset(void*, std::size_t count, int ch) = delete;
^~
: note: previous declaration of 'void* std::memset(void*, int, long
unsigned int)'
Compiler returned: 1
As already mentioned, this hack works with different compilers and helps to
avoid common errors like forgetting the right order of parameter of memset, ie
it helps at compile time to spot errors where someone writes `std::memset(,
sizeof b, 0);` instead of `std::memset(, 0, sizeof b);`.
Since I do not have locally an arm version, I tested it on compiler explorer:
https://godbolt.org/z/aTX9FZ
Also note that removing the overload from the global namespace is not an issue
on arm64, ie
#include
void* memset(void*, std::size_t count, int ch) = delete;
struct foo{ // POD
int a;
int* b;
char c;
};
int main() {
foo b[10];
memset(, 0, sizeof b);
memset(, 0u, sizeof b);
}
compiles fine (except on arm non x64 because the overload is ambiguous, but
AFAIK there is nothing we can do about it).
[Bug rtl-optimization/87759] New: [8/9 Regression] ICE in lra_assign, at lra-assigns.c:1624, or ICE: Maximum number of LRA assignment passes is achieved (30), or compile-time hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
Bug ID: 87759
Summary: [8/9 Regression] ICE in lra_assign, at
lra-assigns.c:1624, or ICE: Maximum number of LRA
assignment passes is achieved (30), or compile-time
hog
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: compile-time-hog, ice-on-invalid-code, ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
1.
gcc-9.0.0-alpha20181021 snapshot (r265361) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast) -fschedule-insns -fselective-scheduling -ftrapv
-fno-dce -fno-expensive-optimizations -fno-ipa-ra -fno-tree-dce -fno-tree-ter:
int cc;
void
rc (__int128 *oi)
{
__int128 qz = (__int128)2 << cc;
if (qz != 0)
{
if (cc != 0)
{
__int128 zp = 1;
for (;;)
{
unsigned __int128 *ar =
int y5;
if (oi != 0)
{
y3:
zp = *oi + *ar;
}
y5 = (cc + 1) == ((*ar /= *oi) << ((zp >>= 128) / cc));
qz += !!y5 ? 1 : qz == (*ar ^ zp + 1);
++*oi;
}
}
else
++qz;
}
goto y3;
}
% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181021 -O2 -fschedule-insns
-fselective-scheduling -ftrapv -fno-dce -fno-expensive-optimizations
-fno-ipa-ra -fno-tree-dce -fno-tree-ter -w -c alqzfpag.c
during RTL pass: reload
alqzfpag.c: In function 'rc':
alqzfpag.c:35:1: internal compiler error: in lra_assign, at lra-assigns.c:1624
35 | }
| ^
0xb582d9 lra_assign(bool&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/lra-assigns.c:1624
0xb5319d lra(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/lra.c:2508
0xb0b131 do_reload
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/ira.c:5469
0xb0b131 execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/ira.c:5653
2.
Removing -fno-ipa-ra from the command line above yields the following:
% x86_64-pc-linux-gnu-gcc-9.0.0-alpha20181021 -O2 -fschedule-insns
-fselective-scheduling -ftrapv -fno-dce -fno-expensive-optimizations
-fno-tree-dce -fno-tree-ter -w -c alqzfpag.c
during RTL pass: reload
alqzfpag.c: In function 'rc':
alqzfpag.c:35:1: internal compiler error: Maximum number of LRA assignment
passes is achieved (30)
35 | }
| ^
0xb582c0 lra_assign(bool&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/lra-assigns.c:1669
0xb5319d lra(_IO_FILE*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/lra.c:2508
0xb0b131 do_reload
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/ira.c:5469
0xb0b131 execute
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181021/work/gcc-9-20181021/gcc/ira.c:5653
3.
gcc 8.2 takes indefinite time to compile the testcase w/ either set of command
line options.
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #7 from Arthur O'Dwyer ---
> std::string is not trivially relocatable in libstdc++
This is surprising news to me! Just goes to show that we would benefit from an
accurate detection mechanism and type trait. :)
> so I won't waste any time there. IIRC, one difference with what you did is
> that I use relocation even for some types that are not trivially relocatable
> (in particular std::string)
...but which are is_nothrow_relocatable. Right. This is a good point in the
direction of maybe keeping is_nothrow_relocatable in P1144. I was thinking that
maybe it was pointless and should be removed until a use-case is found for it.
Now I'm even more unsure.
> 2) the conditionally trivial stuff is not very convenient, it seems to
> involve a lot of code duplication. People regularly suggest attributes of the
> form [[trivially_relocatable(condition)]] which might reduce the noise but
> are harder to specify.
Agreed on all counts. Particularly for this attribute, I worry that the common
use-case would be something really ugly like
template
class [[trivially_relocatable(
is_trivially_relocatable_v &&
is_trivially_relocatable_v::pointer>
)]] vector {
};
which I hope you'd agree would be even more ridiculous than the current
metaprogramming/duplication. And then on top of that, parsing an attribute-list
would become as hard as parsing all of C++, which I don't think we want.
> 4) ... Relocating a pair where A is trivially relocatable and B is not
> can still benefit from doing piecewise relocations so it avoids A's
> super-costly move constructor.
Hmm, I see what you mean, and that is a relevant and novel point AFAIC. The
judo dodge for P1144 here is to point out that if today we provide a way to
warrant/detect *trivial* relocation, well, that is not incompatible with
providing a way to *customize* relocation tomorrow. We just need to agree that
relocation ought to be "tantamount to" a move plus a destroy.
> Ideally relocation would be a constructor or something similarly magic and
> the compiler would auto-generate it for aggregates, etc. But I am asking a
> bit much there...
Yes, Denis Bider's P0023 "Relocator"
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0023r0.pdf
went that route, and I think it was not well received -- or possibly just not
discussed at all, I'm not sure.
Thanks for the comments and the nice work!
[Bug c/87758] New: --print-file-name= ignores -L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87758 Bug ID: 87758 Summary: --print-file-name= ignores -L Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: John.Ericson at Obsidian dot Systems Target Milestone: --- Not respecting -L makes for confusing behavior. I'm surprised there was no issue for this before, as this behavior is probably quite old. --print-prog-name= likewise doesn't use PATH, but at least in that case gcc will also use just -B to find as/ld, so this is honest. [I take some issue with ignoring PATH, but that is a separate issue.] A --print-include-name= using -I (and maybe variants for -isystem, and -iquote) would also be useful primitives.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #43 from Wilco --- (In reply to Douglas Mencken from comment #42) > (In reply to Wilco from comment #41) > > > So what is the disassembly now? > > $ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -O2 -fno-inline pr78468.c > -save-temps > $ mv pr78468.s ~/ > $ diff -u ~/8.2patched-pr78468.s ~/pr78468.s > > Shows nothing, so they are identical So that patch didn't do anything to fix STACK_DYNAMIC_OFFSET then. If it has no effect then is that header really used? > > The 2nd diff still shows the original unaligned STACK_DYNAMIC_OFFSET. > > Second is vanilla 8.2, unpatched, which is marked with “-” in diff I posted > > Possible problem is that in > > - if (size_align > known_align) > - size_align = known_align; > + if (extra && size_align > BITS_PER_UNIT) > +size_align = BITS_PER_UNIT; > > you forgot if (extra /* assumed >0 */ No the problem is not in this code. It's STACK_DYNAMIC_OFFSET which is wrong.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #42 from Douglas Mencken --- (In reply to Wilco from comment #41) > So what is the disassembly now? $ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -O2 -fno-inline pr78468.c -save-temps $ mv pr78468.s ~/ $ diff -u ~/8.2patched-pr78468.s ~/pr78468.s Shows nothing, so they are identical > The 2nd diff still shows the original unaligned STACK_DYNAMIC_OFFSET. Second is vanilla 8.2, unpatched, which is marked with “-” in diff I posted Possible problem is that in - if (size_align > known_align) - size_align = known_align; + if (extra && size_align > BITS_PER_UNIT) +size_align = BITS_PER_UNIT; you forgot if (extra /* assumed >0 */
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #41 from Wilco --- (In reply to Douglas Mencken from comment #40) > To build it, I patched its sources with fix_gcc8_build.patch reversion > together with changes from comment #16 So what is the disassembly now? The 2nd diff still shows the original unaligned STACK_DYNAMIC_OFFSET.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #40 from Douglas Mencken --- Yet I got what I wanted ~ the working GCC 8.2 $ /Developer/GCC/8.2p/PowerPC/32bit/bin/gcc -v Using built-in specs. COLLECT_GCC=/Developer/GCC/8.2p/PowerPC/32bit/bin/gcc COLLECT_LTO_WRAPPER=/Developer/GCC/8.2p/PowerPC/32bit/libexec/gcc/powerpc-unknown-darwin/8.2.0/lto-wrapper Target: powerpc-unknown-darwin Configured with: ../gcc-8.2.0/configure --build=powerpc-unknown-darwin --host=powerpc-unknown-darwin --target=powerpc-unknown-darwin --prefix=/Developer/GCC/8.2p/PowerPC/32bit --enable-languages=c,c++,objc,obj-c++ --enable-shared --enable-static --enable-checking=release --enable-threads=posix --with-__thread --without-system-zlib --disable-nls --disable-werror Thread model: posix gcc version 8.2.0 (GCC) To build it, I patched its sources with fix_gcc8_build.patch reversion together with changes from comment #16
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #39 from Douglas Mencken --- (In reply to Wilco from comment #38) > You can have data in text sections, including bytes and half words. Even if > instructions aligned automatically, the function label might be unaligned if > it was preceded by a byte. Ah, like in these old days of manual coding in ppc assembly... But when entry of function is aligned on 2-byte but not 4-byte then code of such function would not be understood by processor at all. Thus or .align 4, or ditch that “can have data in text sections” completely
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #38 from Wilco --- (In reply to Douglas Mencken from comment #37) > And some more in my wish list. May GCC don’t generate these > > .align2 > > in text section? Any, each and every powerpc instruction is 32bit-wide, no > and never more, no and never less, so these aligns are redundant You can have data in text sections, including bytes and half words. Even if instructions aligned automatically, the function label might be unaligned if it was preceded by a byte.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #37 from Douglas Mencken --- And some more in my wish list. May GCC don’t generate these .align 2 in text section? Any, each and every powerpc instruction is 32bit-wide, no and never more, no and never less, so these aligns are redundant
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #36 from Douglas Mencken --- (In reply to Iain Sandoe from comment #31) > * please could you use > --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 > --target=powerpc-apple-darwin9 (or leave these off - which will cause it to > use the current system version). Does it matter so much? I bet it doesn’t. And host (stage0) compiler I use is patched 7.3 GCC configured with powerpc-unknown-darwin triplet > * how about a build --enable-checking=yes[,rtf,tree] ? in case that shows > something useful? Yet I’m some kind of being tired of process of building GCC many times, so maybe.. later
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #35 from Douglas Mencken --- (In reply to Wilco from comment #33) > So functions must preserve 16-byte alignment, but can they rely on the stack > being always 16-byte aligned on entry? I bet yes when it’s not some hardcoded-by-hand assembly with its own rules. So you may be sure that you get r1 with zeroes in last four bits of it on “bl” or like
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #34 from Douglas Mencken --- Created attachment 44903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44903=edit 8.2vanilla-pr78468.s And there’s assembly produced by *vanilla* (id est with Wilco’s r251713 causing the fail in question) 8.2’s stage1 xgcc --- 8.2vanilla-pr78468.s +++ 8.2patched-pr78468.s @@ -70,7 +70,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,15 + addi r3,r3,18 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -103,7 +103,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,15 + addi r3,r3,18 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -137,7 +137,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,15 + addi r3,r3,22 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -170,7 +170,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,15 + addi r3,r3,22 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -204,7 +204,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,15 + addi r3,r3,30 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -237,7 +237,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,15 + addi r3,r3,30 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -271,7 +271,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,31 + addi r3,r3,46 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1) @@ -305,7 +305,7 @@ mflr r0 stw r30,-8(r1) stw r0,8(r1) - addi r3,r3,31 + addi r3,r3,46 stw r31,-4(r1) rlwinm r3,r3,0,0,27 stwu r1,-96(r1)
[Bug middle-end/87757] weird underlining and colors in sprintf warnings for unterminated arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87757 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||dmalcolm at gcc dot gnu.org Severity|normal |minor --- Comment #1 from Martin Sebor --- In the first case the argument seen by the sprintf pass is: QI size unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffefbe8690 domain pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffefbe8e70> readonly constant arg:0 readonly addressable used public static read QI /build/tmp/t.c:1:12 size unit-size align:8 warn_if_not_align:0 context initial chain used public static unsigned common read DI /build/tmp/t.c:3:7 size unit-size align:64 warn_if_not_align:0 context chain >> /build/tmp/t.c:7:31 start: /build/tmp/t.c:7:31 finish: /build/tmp/t.c:7:31> while in the second case it is: unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffefae51f8 precision:8 min max pointer_to_this > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffefae52a0> readonly constant arg:0 readonly arg:0 readonly addressable used public static read QI /build/tmp/t.c:1:12 size unit-size align:8 warn_if_not_align:0 context initial chain > arg:1 /build/tmp/t.c:8:33 start: /build/tmp/t.c:8:32 finish: /build/tmp/t.c:8:35> /build/tmp/t.c:8:3 start: /build/tmp/t.c:8:3 finish: /build/tmp/t.c:8:36> The (presumably) relevant difference in the locations of the two is: /build/tmp/t.c:7:31 start: /build/tmp/t.c:7:31 finish: /build/tmp/t.c:7:31 vs /build/tmp/t.c:8:3 start: /build/tmp/t.c:8:3 finish: /build/tmp/t.c:8:36 Not sure where that comes from, but the ADDR_EXPR operand does have the right location.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #33 from Wilco --- (In reply to Iain Sandoe from comment #30) > From "Mac_OS_X_ABI_Function_Calls.pdf" > > m32 calling convention > > Prologs and Epilogs > The called function is responsible for allocating its own stack frame, > making sure to preserve 16-byte alignment in the stack. This operation is > accomplished by a section of code called the prolog, which the compiler > places before the body of the subroutine. After the body of the subroutine, > the compiler places an epilog to restore the processor to the state it was > prior to the subroutine call. So functions must preserve 16-byte alignment, but can they rely on the stack being always 16-byte aligned on entry?
[Bug middle-end/87757] New: weird underlining and colors in sprintf warnings for unterminated arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87757
Bug ID: 87757
Summary: weird underlining and colors in sprintf warnings for
unterminated arrays
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC produces slightly different output for the two equivalent calls to sprintf
below. The underlining for the second call looks wrong, as does its color:
it's green.
$ cat t.c && gcc -O2 -S -Wall t.c
const char a[] = { 'a' };
char *d, *e;
void f (void)
{
__builtin_sprintf (d, "%s", a);
__builtin_sprintf (e, "%s", [0]);
}
t.c: In function ‘f’:
t.c:7:26: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
7 | __builtin_sprintf (d, "%s", a);
| ^~ ~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a' };
|^
t.c:8:26: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
8 | __builtin_sprintf (e, "%s", [0]);
| ~~~^~~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a' };
|^
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #32 from Wilco --- (In reply to Segher Boessenkool from comment #29) > It aligns the stack to 16: > > # r3 is size, at entry > addi r3,r3,18 > ... > rlwinm r3,r3,0,0,27 > ... > neg r3,r3 > ... > lwz r2,0(r1) > ... > stwux r2,r1,r3 > > (the rlwinm is r3 &= ~15; ) So this rounds up the size but also adds an extra 16 bytes to the requested allocation. The alloca blocks don't get correctly aligned since STACK_DYNAMIC_OFFSET returns 72 (which is not a multiple of 16): t1_a4 addi r2,r1,72 -> 72 % 16 != 0 (correct value would be 64) stw r6,60(r1) stw r2,56(r1) This also shows in t1/t2_a32: addi r2,r1,103 -> 31 + 72 = 103 (correct value would be 80+31) stw r6,64(r1) rlwinm r2,r2,0,0,26 So this proves STACK_DYNAMIC_OFFSET is incorrect indeed. If there are still failures with that fixed then the stack pointer must also be unaligned.
[Bug tree-optimization/87756] missing unterminated argument warning using address of a constant character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-25 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Testing a fix.
[Bug tree-optimization/87756] New: missing unterminated argument warning using address of a constant character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87756
Bug ID: 87756
Summary: missing unterminated argument warning using address of
a constant character
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC 9 successfully diagnoses the unterminated array argument when it's an
actual array but fails to do the same when the argument is the address of a
single character.
$ cat t.c && gcc -O2 -S -Wall t.c
const char c = 'a';
const char a[] = { 'a' };
char *d, *e;
void f (void)
{
__builtin_sprintf (d, "%s", a);// warning (good)
__builtin_sprintf (e, "%s", ); // missing warning
}
void g (void)
{
__builtin_strcpy (d, a);// warning (good)
__builtin_strcpy (e, ); // missing warning
}
t.c: In function ‘g’:
t.c:14:3: warning: ‘strcpy’ argument missing terminating nul
[-Wstringop-overflow=]
14 | __builtin_strcpy (d, a);// warning (good)
| ^~~
t.c:2:12: note: referenced argument declared here
2 | const char a[] = { 'a' };
|^
t.c: In function ‘f’:
t.c:8:26: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
8 | __builtin_sprintf (d, "%s", a);// warning (good)
| ^~ ~
t.c:2:12: note: referenced argument declared here
2 | const char a[] = { 'a' };
|^
[Bug c++/87742] [7/8/9 Regression] false warning: array subscript 3 is above array bounds of 'const std::type_info* const [3]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87742 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-25 CC||msebor at gcc dot gnu.org Summary|False warning "warning: |[7/8/9 Regression] false |array subscript 3 is above |warning: array subscript 3 |array bounds of 'const |is above array bounds of |std::type_info* const [3]' |'const std::type_info* |" |const [3]' Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. The warning first appeared in GCC 5.0, with r217260: r217260 | rguenth | 2014-11-09 06:27:00 -0500 (Sun, 09 Nov 2014) | 12 lines 2014-11-09 Richard Biener * match.pd: Add patterns convering two conversions in a row from fold-const.c. * fold-const.c (fold_unary_loc): Remove them here. * tree-ssa-forwprop.c (combine_conversions): Likewise. * genmatch.c (dt_node::gen_kids): Check whether we may follow SSA use-def chains. * g++.dg/cpp0x/constexpr-reinterpret1.C: XFAIL. * gcc.dg/tree-ssa/pr21031.c: XFAIL.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #31 from Iain Sandoe --- (In reply to Douglas Mencken from comment #4) > (In reply to Richard Biener from comment #3) > > How did you configure? > > As always > > ../gcc-8.1.0/configure \ > --build=powerpc-unknown-darwin --host=powerpc-unknown-darwin > --target=powerpc-unknown-darwin \ > --prefix=/Developer/GCC/8.1/PowerPC/32bit \ > --enable-languages=c,c++,objc,obj-c++ \ > --enable-shared --enable-static \ > --enable-checking=release \ > --enable-threads=posix --with-__thread --without-system-zlib \ > --disable-nls --disable-werror * please could you use --build=powerpc-apple-darwin9 --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 (or leave these off - which will cause it to use the current system version). Some of the configury will choose values suitable for 10.0+ when there's no version given, which isn't much tested. There are also two places that explicitly mention 'apple' (I doubt they are important here - and I have a patch to remove them, but for now...) * I'm not sure what --with-__thread is going to do here. * how about a build --enable-checking=yes[,rtf,tree] ? in case that shows something useful? hopefully, will find time to boot a system over the weekend.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #30 from Iain Sandoe --- (In reply to Segher Boessenkool from comment #27) > The stack is always 16B-aligned on Darwin as far as I know. Cc:ing Iain, he > will know for sure (I cannot find the docs, &^%*&^$#*&%) I actually thought we'd been around this loop a couple of revs. ago (when there was a change made to the headers, and it had been confirmed to be OK). don't have a system booted at the moment .. and haven't (yet) had the details - but here: From "Mac_OS_X_ABI_Function_Calls.pdf" m32 calling convention Prologs and Epilogs The called function is responsible for allocating its own stack frame, making sure to preserve 16-byte alignment in the stack. This operation is accomplished by a section of code called the prolog, which the compiler places before the body of the subroutine. After the body of the subroutine, the compiler places an epilog to restore the processor to the state it was prior to the subroutine call. m64 calling convention Prologs and Epilogs The called function is responsible for allocating its own stack frame, making sure to preserve 16-byte alignment in the stack. This operation is accomplished by a section of code called the prolog, which the compiler places before the body of the subroutine. After the body of the subroutine, the compiler places an epilog to restore the processor to the state it was prior to the subroutine call.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #29 from Segher Boessenkool --- It aligns the stack to 16: # r3 is size, at entry addi r3,r3,18 ... rlwinm r3,r3,0,0,27 ... neg r3,r3 ... lwz r2,0(r1) ... stwux r2,r1,r3 (the rlwinm is r3 &= ~15; )
[Bug c++/87709] c++17 class template argument deduction not working in a very specific case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709
--- Comment #4 from Baruch Burstein ---
There is a pretty good (speculative) analysis of this issue here:
https://stackoverflow.com/a/52986284/331785
I am copying it to here for completeness, but credit for this goes to the
author of that post:
There are two kinds of expressions that look similar but have vastly different
meaning:
(type) + expr
(expr) + expr
The first is a C-style cast expression, that converts the unary expression +
expr to type, the second is a binary expression that performs addition.
To disambiguate an expression of form (something) + expr, GCC first assumes
that something is a type and does a tentative parse. If that succeeds, then the
whole expression is treated as a cast expression, otherwise, something is
reparsed as an expression.
Now here's where I think the bug resides: during the tentative parse, GCC
wrongly believes that class template argument deduction (CTAD) cannot appear,
so it issues an error when it appears. But in fact, even though the tentative
parse will definitely fail in this case, something may still be a valid
function-style cast expression, and thus the reparse might be successful.
For cat((lit('b')), lit('d')), lit('b') + lit('d'), and (lit('b')), GCC is
clever enough to see that they can't be C-style cast expression, so it does not
do the tentative parse. For (lit('b')) + lit('d'), there's no CTAD in
lit('b'), so it is fine as well.
Prove of the above analysis:
If + is changed to / (or most operators other than -, * or &), no error occurs,
because (something) / expr can't be a valid cast expression.
Similar ambiguity exists in sizeof(something) (could be sizeof(type) or
sizeof(expr)), and as expected, sizeof(lit(0)) triggers a similar error.
[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 --- Comment #13 from Dominique d'Humieres --- > FYI : On my environment it's not possible to produce an ICE with gcc-9 > and several tested combinations of options / all tested configurations. > > $ gfortran-9-20181021 -c pr52994.f90 > pr52994.f90:43:29: > >43 | a%left_halo(psi%arr) = -666 > | 1 > Error: Different types in pointer assignment at (1); attempted assignment > of REAL(4) to INTEGER(4) The change occurred between revisions r227742 (2015-09-14, ICE) and r228457 (2015-10-04, error), likely r228222 (pr40054, pr63921). Note that I am surprised by the order of REAL(4) and INTEGER(4): AFAICT a%left_halo(psi%arr) is real and -666 an integer, isn't it?
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #28 from Douglas Mencken --- Created attachment 44902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44902=edit 8.2patched-pr78468.s Assembly produced by patched 8.2’s stage1 xgcc compiled using prev-gcc/xgcc -B/Volumes/LibreOffice/TheGCC/_build_8.2/prev-gcc/ -O2 -fno-inline pr78468.c -save-temps
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 Segher Boessenkool changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #27 from Segher Boessenkool --- The stack is always 16B-aligned on Darwin as far as I know. Cc:ing Iain, he will know for sure (I cannot find the docs, &^%*&^$#*&%)
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #26 from Wilco --- (In reply to Douglas Mencken from comment #25) > (In reply to Wilco from comment #24) > > > Yes the stage1 compiler would be fine or alternatively use > > --disable-bootstrap to get an installed compiler. > > I’m yet at libstdc++ of stage2 (which means that it succeeded the place of > failing) for 8.2 patched with the reversion I’ve just published. About four > hours and I’d get working 8.2 If that's the case then STACK_BOUNDARY is incorrect. So what is the actual alignment on Darwin, 8-byte alignment? How are Altivec instructions handled which do require 16-byte alignment? > Or do you want to look at results with your r251713? Does it matter? Either would be interesting - it would show what alignment the prologue really uses and what code it generates for alloca.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #25 from Douglas Mencken --- (In reply to Wilco from comment #24) > Yes the stage1 compiler would be fine or alternatively use > --disable-bootstrap to get an installed compiler. I’m yet at libstdc++ of stage2 (which means that it succeeded the place of failing) for 8.2 patched with the reversion I’ve just published. About four hours and I’d get working 8.2 Or do you want to look at results with your r251713? Does it matter?
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #24 from Wilco --- (In reply to Douglas Mencken from comment #22) > (In reply to Wilco from comment #21) > > > That's odd. The stack pointer is definitely 16-byte aligned in all cases > > right? > > As I know, PowerPC has no special “stack pointer”, it is just one of general > purpose register, conventionally it is r1. Instruction like “stwu r3,-2(r1)” > which are common for prologues easily bin any alignment. STACK_BOUNDARY is the minimum stack alignment. The optimizer relies on this being correct. If the ABI or prologue doesn't guarantee the minimum alignment then alloca will fail, so it's essential to set STACK_BOUNDARY correctly. > > Can you check gcc.dg/pr78468.c passes and attach the disassembly > > please? > > Using which compiler? xgcc from stage1? Is it buildable alone by itself? Yes the stage1 compiler would be fine or alternatively use --disable-bootstrap to get an installed compiler.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #23 from Douglas Mencken --- Created attachment 44901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44901=edit fix_gcc8_build.patch Reversion of r251713, updated for patching sources of 8.2 release
[Bug other/87755] [9 regression] ERROR: couldn't compile regular expression pattern: quantifier operand invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87755
--- Comment #1 from seurer at gcc dot gnu.org ---
Note: This happens during a make check.
This may be more of the error output:
ERROR: tcl error sourcing
/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/lto/lto.exp.
ERROR: couldn't compile regular expression pattern: quantifier operand invalid
while executing
"regsub -all $pat $text "\n" text"
(procedure "lto_handle_diagnostics_for_file" line 28)
invoked from within
"lto_handle_diagnostics_for_file $testcase $src ${dg-messages} $text"
(procedure "lto_handle_diagnostics" line 15)
invoked from within
"lto_handle_diagnostics $comp_output"
(procedure "lto-link-and-maybe-run" line 47)
invoked from within
"lto-link-and-maybe-run "[lindex $obj_list 0]-[lindex $obj_list end]"
$obj_list $execname $filtered ${dg-extra-ld-options} $filtered"
(procedure "lto-execute" line 142)
invoked from within
"lto-execute $src $sid"
("foreach" body line 7)
invoked from within
"foreach src [lsort [find $srcdir/$subdir *_0.\[cC\]]] {
# If we're only testing specific files and this isn't one of them, skip it.
if ![runte..."
(file "/home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/lto/lto.exp" line
51)
invoked from within
"source /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/lto/lto.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/lto/lto.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #22 from Douglas Mencken --- (In reply to Wilco from comment #21) > That's odd. The stack pointer is definitely 16-byte aligned in all cases > right? As I know, PowerPC has no special “stack pointer”, it is just one of general purpose register, conventionally it is r1. Instruction like “stwu r3,-2(r1)” which are common for prologues easily bin any alignment. > Can you check gcc.dg/pr78468.c passes and attach the disassembly > please? Using which compiler? xgcc from stage1? Is it buildable alone by itself?
[Bug lto/87754] [9 regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11, ||x86_64-pc-linux-gnu --- Comment #1 from Rainer Orth --- I just checked: Linux/x86_64 is likewise affected.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #21 from Wilco --- (In reply to Douglas Mencken from comment #18) > (In reply to Wilco from comment #17) > > > Yes that should work. > > Oops, but it doesn’t. I just tested it with patched 8.2. Same messages, same > breakage That's odd. The stack pointer is definitely 16-byte aligned in all cases right? Can you check gcc.dg/pr78468.c passes and attach the disassembly please?
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #20 from Segher Boessenkool --- This is #define SUPPORTS_STACK_ALIGNMENT (MAX_STACK_ALIGNMENT > STACK_BOUNDARY) and #define MAX_STACK_ALIGNMENT STACK_BOUNDARY so that seems normal.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #19 from Douglas Mencken --- I dunno are such warnings related or not echo timestamp > s-gtype ccache /Developer/GCC/7.3p/PowerPC/32bit/bin/g++ -std=gnu++98 -fno-PIE -c -g -mdynamic-no-pic -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-8.2.0/gcc -I../../gcc-8.2.0/gcc/. -I../../gcc-8.2.0/gcc/../include -I../../gcc-8.2.0/gcc/../libcpp/include -I/Volumes/LibreOffice/TheGCC/_build_8.2/./gmp -I/Volumes/LibreOffice/TheGCC/gcc-8.2.0/gmp -I/Volumes/LibreOffice/TheGCC/_build_8.2/./mpfr/src -I/Volumes/LibreOffice/TheGCC/gcc-8.2.0/mpfr/src -I/Volumes/LibreOffice/TheGCC/gcc-8.2.0/mpc/src -I../../gcc-8.2.0/gcc/../libdecnumber -I../../gcc-8.2.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-8.2.0/gcc/../libbacktrace -I/Volumes/LibreOffice/TheGCC/_build_8.2/./isl/include -I/Volumes/LibreOffice/TheGCC/gcc-8.2.0/isl/include -o explow.o -MT explow.o -MMD -MP -MF ./.deps/explow.TPo ../../gcc-8.2.0/gcc/explow.c ../../gcc-8.2.0/gcc/explow.c: In function 'rtx_def* round_push(rtx)': ../../gcc-8.2.0/gcc/explow.c:989:248: warning: self-comparison always evaluates to false [-Wtautological-compare] if (!SUPPORTS_STACK_ALIGNMENT ~~~ ^ ../../gcc-8.2.0/gcc/explow.c: In function 'void emit_stack_restore(save_level, rtx)': ../../gcc-8.2.0/gcc/explow.c:1104:247: warning: self-comparison always evaluates to false [-Wtautological-compare] if (SUPPORTS_STACK_ALIGNMENT) ^ rm -rf libbackend.a
[Bug other/87755] New: [9 regression] ERROR: couldn't compile regular expression pattern: quantifier operand invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87755 Bug ID: 87755 Summary: [9 regression] ERROR: couldn't compile regular expression pattern: quantifier operand invalid Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- These errors started showing up in builds today somewhere in r265483 or r265484 ERROR: couldn't compile regular expression pattern: quantifier operand invalid ERROR: tcl error sourcing /home/gccbuild/gcc_trunk_anonsvn/gcc/gcc/testsuite/g++.dg/lto/lto.exp. I am not sure exactly where they are coming out as the text is commingled with other text. It happening on at least all the powerpc64 targets and x86 ones too. r265484 | hubicka | 2018-10-25 07:18:28 -0500 (Thu, 25 Oct 2018) | 6 lines * ipa-devirt.c (odr_types_equivalent_p): Do not ICE if one of types is anonymous. * g++.dg/lto/odr-1_0.C: New test. * g++.dg/lto/odr-1_1.C: New test. r265483 | thopre01 | 2018-10-25 05:35:21 -0500 (Thu, 25 Oct 2018) | 18 lines dg-cmp-results: display NA->FAIL & NA->UNRESOLVED by default Currently, dg-cmp-results will not print anything for a test that was not run before, even if it is a FAIL or UNRESOLVED now. This means that when contributing a code change together with a testcase in the same commit one must run dg-cmp-results twice: once to check for regression on a full testsuite run and once against the new testcase with -v -v. This also prevents using dg-cmp-results on sum files generated with test_summary since these would not contain PASS. This patch changes dg-cmp-results to print NA->FAIL and NA->UNRESOLVED changes by default. 2018-10-25 Thomas Preud'homme contrib/ * dg-cmp-results.sh: Print NA-FAIL and NA->UNRESOLVED changes at default verbosity.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #18 from Douglas Mencken --- (In reply to Wilco from comment #17) > Yes that should work. Oops, but it doesn’t. I just tested it with patched 8.2. Same messages, same breakage
[Bug lto/87754] [9 regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug lto/87754] New: [9 regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87754 Bug ID: 87754 Summary: [9 regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1250 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20181024 (r265465) and 20181025 (r265498), the following error occured on Solaris 11/x86 and SPARC, both 32 and 64-bit: +ERROR: couldn't compile regular expression pattern: quantifier operand invalid +ERROR: tcl error sourcing /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/lto.exp. This was caused by throwing lto.exp off-balance. The underlying ICE is this: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/odr-1_0.C:3:8: warning: type 'struct a' violates the C++ One Definition Rule [-Wodr] /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/odr-1_1.C:4:8: note: a different type is defined in another translation unit /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/odr-1_0.C:4:13: note: the first difference of corresponding definitions is field 'ptr' /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/lto/odr-1_1.C:5:13: note: a field of same name but different type is defined in another translation unit lto1: internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1250 0x71b7a7 odr_types_equivalent_p /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1250 0x71b7a7 odr_types_equivalent_p /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1242 0x71ccf3 odr_types_equivalent_p(tree_node*, tree_node*) /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1648 0x71cd9b type_mismatch_p /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1027 0x71d1cf warn_types_mismatch(tree_node*, tree_node*, unsigned int, unsigned int) /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1172 0x71c517 odr_types_equivalent_p /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1559 0x71c517 odr_types_equivalent_p 0x71c517 odr_types_equivalent_p /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1242 0x717dd3 add_type_duplicate /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:1855 0x717dd3 get_odr_type(tree_node*, bool) /vol/gcc/src/hg/trunk/local/gcc/ipa-devirt.c:2035 0x3f6847 lto_read_decls /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:1900 0x3f7f33 lto_file_finalize /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:2134 0x3f7f33 lto_create_files_from_ids /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:2144 0x3f7f33 lto_file_read /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:2185 0x3f7f33 read_cgraph_and_symbols /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:2865 0x3f7f33 lto_main() /vol/gcc/src/hg/trunk/local/gcc/lto/lto.c:3401 And has obviously been caused by changeset: 49043:8f8f242f9f43 user:hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 date:Thu Oct 25 12:18:28 2018 + files: gcc/ChangeLog gcc/ipa-devirt.c gcc/testsuite/ChangeLog gcc/testsuite/g++.dg/lto/odr-1_0.C gcc/testsuite/g++.dg/lto/odr-1_1.C description: * ipa-devirt.c (odr_types_equivalent_p): Do not ICE if one of types is anonymous. * g++.dg/lto/odr-1_0.C: New test. * g++.dg/lto/odr-1_1.C: New test.
[Bug fortran/86837] [8/9 Regression] Optimization breaks an unformatted read with implicit loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 Dominique d'Humieres changed: What|Removed |Added CC||hvandam at bnl dot gov --- Comment #9 from Dominique d'Humieres --- *** Bug 87753 has been marked as a duplicate of this bug. ***
[Bug fortran/87753] READ statement with nested implied do broken with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- Duplicate of pr86837, fixed on trunk (9.0) by revision r263838 and in 8.2.1 by r263844. *** This bug has been marked as a duplicate of bug 86837 ***
[Bug fortran/87753] READ statement with nested implied do broken with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753 --- Comment #1 from Hubertus van Dam --- Created attachment 44900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44900=edit The data file that the program reads
[Bug fortran/87753] New: READ statement with nested implied do broken with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87753 Bug ID: 87753 Summary: READ statement with nested implied do broken with optimization Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hvandam at bnl dot gov Target Milestone: --- Created attachment 44899 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44899=edit The test program demonstrating the problem I have code snippet that uses an implied do loop when reading some data from a file. Dependent on the level of optimization the code either reads the data correctly or does not seem to read any data at all. Compiling with the -Wall and -Wextra flags it seems that some of the variables in the implied do loop are mistaken for functions if the optimization is turned on. The code is (file "test.F"): program test implicit none integer, parameter :: mxj = 3 integer :: numj = mxj integer :: numi(mxj) = (/5,3,1/) integer :: anum(5,mxj) integer :: ii, jj anum=0 open(unit=10,file="input.dat",status="old") read(10,*)((anum(ii,jj),ii=1,numi(jj)),jj=1,numj) do ii=1,maxval(numi) write(*,*)(anum(ii,jj),jj=1,numj) enddo close(10) end The data file "input.dat" contains: 11 12 13 14 15 21 22 23 31 Compiling the code and running it gives: $ gfortran -Wall -Wextra test.F $ ./a.out 11 21 31 12 22 0 13 23 0 14 0 0 15 0 0 $ gfortran -Wall -Wextra -O1 test.F test.F:10:0: read(10,*)((anum(ii,jj),ii=1,numi(jj)),jj=1,numj) Warning: ‘jj’ is used uninitialized in this function [-Wuninitialized] $ ./a.out 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 The warning makes no sense because jj is neither uninitialized nor used in a function. The resulting code is clearly broken. Higher optimization levels generate the same wrong results (-O2 and -O3). Turning optimization off (with -O0) produces the same correct result as specifying no optimization flags. GFortran version (I tried locating 8.2.1 and 9.0 but could not find those on any of the mirror sites): $ gfortran --version GNU Fortran (GCC) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. Operating system: $ uname -a Linux host 2.6.32-220.el6.x86_64 #1 SMP Sat Dec 10 17:04:11 CST 2011 x86_64 x86_64 x86_64 GNU/Linux GCC configure line: $ ./configure --prefix=/home/username --disable-multilib
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #6 from Marc Glisse --- Re-reading P1144R0 (those are not necessarily comments on the paper, just what comes to mind for gcc): 1) yes, an automatic detection mechanism would be nice, and an attribute makes sense. 2) the conditionally trivial stuff is not very convenient, it seems to involve a lot of code duplication. People regularly suggest attributes of the form [[trivially_relocatable(condition)]] which might reduce the noise but are harder to specify. 3) there are indeed many places outside of vector that can benefit from relocation. The compromises may not be the same though. For my use in vectors, relocation was never worse, it performed the same moves and destructions as the original. In other places, using relocation would replace a move-assignment with a construction and a destruction, which could be worse, so we may want to limit it to the trivially relocatable case. 4) I think it might be useful to be able to specify how to relocate an object that is not trivially relocatable. Relocating a pair where A is trivially relocatable and B is not can still benefit from doing piecewise relocations so it avoids A's super-costly move constructor. Ideally relocation would be a constructor or something similarly magic and the compiler would auto-generate it for aggregates, etc. But I am asking a bit much there... By the way, thanks for keeping destructive moves alive :-)
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #17 from Wilco --- (In reply to Douglas Mencken from comment #16) > Like this? > > --- a/gcc/config/rs6000/darwin.h > +++ b/gcc/config/rs6000/darwin.h > @@ -150,13 +150,12 @@ > > #undef RS6000_STARTING_FRAME_OFFSET > #define RS6000_STARTING_FRAME_OFFSET \ > - (RS6000_ALIGN (crtl->outgoing_args_size, 16) > \ > - + RS6000_SAVE_AREA) > + RS6000_ALIGN (crtl->outgoing_args_size + RS6000_SAVE_AREA, 16) > > #undef STACK_DYNAMIC_OFFSET > #define STACK_DYNAMIC_OFFSET(FUNDECL) > \ > - (RS6000_ALIGN (crtl->outgoing_args_size.to_constant (), 16) > \ > - + (STACK_POINTER_OFFSET)) > + RS6000_ALIGN (crtl->outgoing_args_size.to_constant() > \ > + + STACK_POINTER_OFFSET, 16) > > /* Darwin uses a function call if everything needs to be saved/restored. */ Yes that should work.
[Bug fortran/52994] [OOP] [F08] internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:6881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52994 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #12 from G. Steinmetz --- FYI : On my environment it's not possible to produce an ICE with gcc-9 and several tested combinations of options / all tested configurations. $ gfortran-9-20181021 -c pr52994.f90 pr52994.f90:43:29: 43 | a%left_halo(psi%arr) = -666 | 1 Error: Different types in pointer assignment at (1); attempted assignment of REAL(4) to INTEGER(4)
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #16 from Douglas Mencken --- Like this? --- a/gcc/config/rs6000/darwin.h +++ b/gcc/config/rs6000/darwin.h @@ -150,13 +150,12 @@ #undef RS6000_STARTING_FRAME_OFFSET #define RS6000_STARTING_FRAME_OFFSET \ - (RS6000_ALIGN (crtl->outgoing_args_size, 16) \ - + RS6000_SAVE_AREA) + RS6000_ALIGN (crtl->outgoing_args_size + RS6000_SAVE_AREA, 16) #undef STACK_DYNAMIC_OFFSET #define STACK_DYNAMIC_OFFSET(FUNDECL) \ - (RS6000_ALIGN (crtl->outgoing_args_size.to_constant (), 16) \ - + (STACK_POINTER_OFFSET)) + RS6000_ALIGN (crtl->outgoing_args_size.to_constant() \ + + STACK_POINTER_OFFSET, 16) /* Darwin uses a function call if everything needs to be saved/restored. */
[Bug fortran/87752] ICE in omp_add_variable, at gimplify.c:6776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87752 --- Comment #1 from G. Steinmetz --- Compiles without "simd" : $ cat z2.f90 subroutine foo (n, u, v) integer :: n real, pointer :: u(:), v(:) !$omp parallel do do i = 1, n u(:) = v(:) end do end $ gfortran -9-20181021 -c z2.f90 -fopenmp -O3 $ gfortran -9-20181021 -c z2.f90 -fopenmp -Ofast
[Bug fortran/87752] New: ICE in omp_add_variable, at gimplify.c:6776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87752 Bug ID: 87752 Summary: ICE in omp_add_variable, at gimplify.c:6776 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least version 5 : $ cat z1.f90 subroutine foo (n, u, v) integer :: n real, pointer :: u(:), v(:) !$omp parallel do simd do i = 1, n u(:) = v(:) end do end $ gfortran -9-20181021 -c z1.f90 -fopenmp -O3 $ gfortran -9-20181021 -c z1.f90 -fopenmp -Ofast z1.f90:6:0: 6 | u(:) = v(:) | internal compiler error: Segmentation fault 0xb1c86f crash_signal ../../gcc/toplev.c:325 0x8f6510 omp_add_variable ../../gcc/gimplify.c:6776 0x8fd2ad gimplify_bind_expr ../../gcc/gimplify.c:1300 0x8fa41a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11805 0x8fc208 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6614 0x8f96eb gimplify_statement_list ../../gcc/gimplify.c:1763 0x8f96eb gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:12033 0x8fc208 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6614 0x907d2b gimplify_and_add(tree_node*, gimple**) ../../gcc/gimplify.c:441 0x907d2b gimplify_and_return_first ../../gcc/gimplify.c:453 0x907d2b gimplify_omp_for ../../gcc/gimplify.c:10400 0x8f940a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:12091 0x8fc208 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6614 0x8fcb61 gimplify_bind_expr ../../gcc/gimplify.c:1331 0x8fa41a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:11805 0x8fc208 gimplify_stmt(tree_node**, gimple**) ../../gcc/gimplify.c:6614 0x907d2b gimplify_and_add(tree_node*, gimple**) ../../gcc/gimplify.c:441 0x907d2b gimplify_and_return_first ../../gcc/gimplify.c:453 0x907d2b gimplify_omp_for ../../gcc/gimplify.c:10400 0x8f940a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gimplify.c:12091
[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87704 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.5 --- Comment #6 from Jonathan Wakely --- Fixed for 6.5, 7.4, 8.3 and 9
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for 6.5, 7.4, 8.3 and 9
[Bug fortran/87751] New: ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87751 Bug ID: 87751 Summary: ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10255 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Down to version 5 at least, with an invalid function reference and together with option -fcheck=all or -fcheck=mem : $ cat z1.f90 program p interface function f() result(z) integer, allocatable :: z(:) end end interface procedure(f), pointer :: g => null() g = 1 end $ gfortran-9-20181021 -c z1.f90 $ $ gfortran-9-20181021 -c z1.f90 -fcheck=all z1.f90:8:0: 8 |g = 1 | internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:10255 0x6fc273 gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10254 0x6bd90f trans_code ../../gcc/fortran/trans.c:1822 0x6e51c4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6505 0x673426 translate_all_program_units ../../gcc/fortran/parse.c:6125 0x673426 gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6ba3ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu Oct 25 16:42:01 2018 New Revision: 265500 URL: https://gcc.gnu.org/viewcvs?rev=265500=gcc=rev Log: PR libstdc++/87749 fix (and optimize) string move construction The move constructor for the SSO string uses assign(const basic_string&) when either: (1) the source string is "local" and so the contents of the small string buffer need to be copied, or (2) the allocator does not propagate and is_always_equal is false. Case (1) is suboptimal, because the assign member is not noexcept and the compiler isn't smart enough to see it won't actually throw in this case. This causes extra code in the move assignment operator so that any exception will be turned into a call to std::terminate. This can be fixed by copying small strings inline instead of calling assign. Case (2) is a bug, because the specific instances of the allocators could be equal even if is_always_equal is false. This can result in an unnecessary deep copy (and potentially-throwing allocation) when the storage should be moved. This can be fixed by simply checking if the allocators are equal. PR libstdc++/87749 * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::operator=(basic_string&&)): For short strings copy the buffer inline. Only fall back to using assign(const basic_string&) to do a deep copy when reallocation is needed. * testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/char/ move_assign_optim.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/ move_assign_optim.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc branches/gcc-6-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc branches/gcc-6-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc branches/gcc-6-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/basic_string.h
[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87704 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Thu Oct 25 16:41:54 2018 New Revision: 265499 URL: https://gcc.gnu.org/viewcvs?rev=265499=gcc=rev Log: PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors Using a delegating constructor to implement these constructors means that they instantiate the destructor, which requires the element_type to be complete. In C++11 and C++14 they were specified to be delegating, but that was changed as part of LWG 2801 so in C++17 they don't require a complete type (as was intended all along). Backport from mainline 2018-10-23 Jonathan Wakely PR libstdc++/87704 * include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do not delegate to default constructor. (unique_ptr::unique_ptr(nullptr_t)): Likewise. * testsuite/20_util/unique_ptr/cons/incomplete.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/unique_ptr.h branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/assign/48635_neg.cc branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/cv_qual_neg.cc
[Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196 --- Comment #5 from G. Steinmetz --- Looking at variations z1..z4 with two data statements and combinations z5..z8 with one data statement only : # cat z1.f90 # ICE, see comment above $ cat z2.f90 program p type t character(3) :: c integer :: i end type type t2 type(t) :: a end type type(t2) :: x data x%a%i / 1 / data x%a%c / 'abc' / print *, x end $ gfortran-9-20181021 -static-libgfortran z2.f90 $ a.out abc 1 $ cat z3.f90 program p type t integer :: i character(3) :: c end type type t2 type(t) :: a end type type(t2) :: x data x%a%c / 'abc' / data x%a%i / 1 / print *, x end $ gfortran-9-20181021 -static-libgfortran z3.f90 $ a.out 1 abc $ cat z4.f90 program p type t character(3) :: c integer :: i end type type t2 type(t) :: a end type type(t2) :: x data x%a%c / 'abc' / data x%a%i / 1 / print *, x end # ICE, see comment above $ cat z5.f90 program p type t integer :: i character(3) :: c end type type t2 type(t) :: a end type type(t2) :: x data x%a%i / 1 / print *, x end $ gfortran-9-20181021 -static-libgfortran z5.f90 $ a.out 1 $ cat z6.f90 program p type t integer :: i character(3) :: c end type type t2 type(t) :: a end type type(t2) :: x data x%a%c / 'abc' / print *, x end # ICE when configured with --enable-checking=yes $ gfortran-9-20181021-chk -c z6.f90 z6.f90:12:0: 12 | end | internal compiler error: in output_constant, at varasm.c:4986 0xf8f91c output_constant ../../gcc/varasm.c:4986 0xf90f2d output_constant ../../gcc/varasm.c:5219 0xf90f2d output_constructor_regular_field ../../gcc/varasm.c:5219 0xf90f2d output_constructor ../../gcc/varasm.c:5490 0xf90f2d output_constant ../../gcc/varasm.c:5219 0xf90f2d output_constructor_regular_field ../../gcc/varasm.c:5219 0xf90f2d output_constructor ../../gcc/varasm.c:5490 0xf920c9 output_constant ../../gcc/varasm.c:4858 0xf920c9 assemble_variable_contents ../../gcc/varasm.c:2140 0xf9b12a assemble_variable(tree_node*, int, int, int) ../../gcc/varasm.c:2319 0xf9f414 varpool_node::assemble_decl() ../../gcc/varpool.c:586 0x828fdc output_in_order ../../gcc/cgraphunit.c:2442 0x828fdc symbol_table::compile() ../../gcc/cgraphunit.c:2682 0x82b9c6 symbol_table::compile() ../../gcc/cgraphunit.c:2864 0x82b9c6 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2861 $ cat z7.f90 program p type t character(3) :: c integer :: i end type type t2 type(t) :: a end type type(t2) :: x data x%a%c / 'abc' / print *, x end $ gfortran-9-20181021 -static-libgfortran z7.f90 $ a.out abc 0 $ cat z8.f90 program p type t character(3) :: c integer :: i end type type t2 type(t) :: a end type type(t2) :: x data x%a%i / 1 / print *, x end # ICE, see comment above
[Bug fortran/71196] f951: internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #4 from G. Steinmetz --- Update : $ cat z1.f90 program p type t integer :: i character(3) :: c end type type t2 type(t) :: a end type type(t2) :: x data x%a%i / 1 / data x%a%c / 'abc' / print *, x end $ gfortran-9-20181021 -c z1.f90 z1.f90:1:0: 1 | program p | internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148 0x6d888b gfc_conv_string_init(tree_node*, gfc_expr*) ../../gcc/fortran/trans-const.c:148 0x6fca5f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:7034 0x6ec173 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7894 0x6fca91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:7027 0x6ec173 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7894 0x6fca91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:7027 0x6e1647 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1824 0x6e3ec7 generate_local_decl ../../gcc/fortran/trans-decl.c:5596 0x6a80f2 do_traverse_symtree ../../gcc/fortran/symbol.c:4151 0x6e4fe4 generate_local_vars ../../gcc/fortran/trans-decl.c:5796 0x6e4fe4 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6440 0x673426 translate_all_program_units ../../gcc/fortran/parse.c:6125 0x673426 gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6ba3ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #5 from Marc Glisse --- (In reply to Arthur O'Dwyer from comment #4) > Have you seen my libc++ patch on the same topic as yours? > > https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially- > relocatable/ > https://github.com/Quuxplusone/libcxx/tree/trivially-relocatable/include I am not sure I should look too closely for copyright reasons. Maybe I can... I did read the papers though. > Specifically, the piece that I think is still missing from libstdc++'s > implementation (besides all the cool stuff that you'd get from the > attribute) is the trait `__has_trivial_construct`. I already filed Bug 87604 for that. > This trait > allows you to write your `__relocate_a_1` generically, instead of > special-casing it for `std::allocator` in particular. (So for example it > could also get picked up for `std::pmr::polymorphic_allocator`... I am not particularly interested in polymorphic_allocator. The patch is still missing more important pieces, like the ability to actually specialize __is_trivially_relocatable (I already have another patch locally with the missing piece). > I hope we get P1144 so that you don't have to waste time and brain cells > specializing `__is_trivially_relocatable` for std::string and std::pair > and so on. std::string is not trivially relocatable in libstdc++, so I won't waste any time there. IIRC, one difference with what you did is that I use relocation even for some types that are not trivially relocatable (in particular std::string), because it actually helps, as shown in the first message of this bug report. > Complete tangent: I'm confused how vector.tcc is allowed to use "if > constexpr" in C++11 mode. > https://github.com/gcc-mirror/gcc/commit/e9f84d4c#diff- > 05b068171cedf9d0176bada75d7dd112R76 It is enabled as an extension and produces a warning which is disabled in system headers.
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Thu Oct 25 16:32:47 2018 New Revision: 265497 URL: https://gcc.gnu.org/viewcvs?rev=265497=gcc=rev Log: PR libstdc++/87749 fix (and optimize) string move construction The move constructor for the SSO string uses assign(const basic_string&) when either: (1) the source string is "local" and so the contents of the small string buffer need to be copied, or (2) the allocator does not propagate and is_always_equal is false. Case (1) is suboptimal, because the assign member is not noexcept and the compiler isn't smart enough to see it won't actually throw in this case. This causes extra code in the move assignment operator so that any exception will be turned into a call to std::terminate. This can be fixed by copying small strings inline instead of calling assign. Case (2) is a bug, because the specific instances of the allocators could be equal even if is_always_equal is false. This can result in an unnecessary deep copy (and potentially-throwing allocation) when the storage should be moved. This can be fixed by simply checking if the allocators are equal. PR libstdc++/87749 * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::operator=(basic_string&&)): For short strings copy the buffer inline. Only fall back to using assign(const basic_string&) to do a deep copy when reallocation is needed. * testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/char/ move_assign_optim.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/ move_assign_optim.cc: New test. Added: branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc branches/gcc-7-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/include/bits/basic_string.h
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Thu Oct 25 16:21:19 2018 New Revision: 265496 URL: https://gcc.gnu.org/viewcvs?rev=265496=gcc=rev Log: PR libstdc++/87749 fix (and optimize) string move construction The move constructor for the SSO string uses assign(const basic_string&) when either: (1) the source string is "local" and so the contents of the small string buffer need to be copied, or (2) the allocator does not propagate and is_always_equal is false. Case (1) is suboptimal, because the assign member is not noexcept and the compiler isn't smart enough to see it won't actually throw in this case. This causes extra code in the move assignment operator so that any exception will be turned into a call to std::terminate. This can be fixed by copying small strings inline instead of calling assign. Case (2) is a bug, because the specific instances of the allocators could be equal even if is_always_equal is false. This can result in an unnecessary deep copy (and potentially-throwing allocation) when the storage should be moved. This can be fixed by simply checking if the allocators are equal. PR libstdc++/87749 * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::operator=(basic_string&&)): For short strings copy the buffer inline. Only fall back to using assign(const basic_string&) to do a deep copy when reallocation is needed. * testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/char/ move_assign_optim.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/ move_assign_optim.cc: New test. Added: branches/gcc-8-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc branches/gcc-8-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc branches/gcc-8-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc branches/gcc-8-branch/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/bits/basic_string.h
[Bug c++/87750] New: Failed compilation / parsing of template member call after 'using' declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87750 Bug ID: 87750 Summary: Failed compilation / parsing of template member call after 'using' declaration Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mark.atkinson99 at gmail dot com Target Milestone: --- Problem code: https://godbolt.org/z/3IpLz1 This is a cut down sample of real code that no longer compiles in gcc 8.x. On godbolt the sample does not compile under 8.1, 8.2 & current trunk, but works in previous gcc. The first call marked (1) compiles in gcc <= 7.x, clang, msvc & icc. The call marked (2) is accepted by gcc 5.x to 7.x and clang 7 but not clang 5 & 6. I can work around it, but can you advise root cause.
[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87723 --- Comment #2 from Andreas Krebbel --- (In reply to Andreas Krebbel from comment #1) > Created attachment 44898 [details] > Patch > > The "*rsbg_di_rotl" output string uses mode attributes with actually > using a mode iterator. s/with/without/
[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87723 --- Comment #1 from Andreas Krebbel --- Created attachment 44898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44898=edit Patch The "*rsbg_di_rotl" output string uses mode attributes with actually using a mode iterator.
[Bug testsuite/87739] new test case gcc.dg/tree-ssa/pr84436-5.c fails with its introduction in r265463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87739 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug testsuite/87739] new test case gcc.dg/tree-ssa/pr84436-5.c fails with its introduction in r265463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87739 --- Comment #4 from Martin Liška --- Author: marxin Date: Thu Oct 25 15:36:48 2018 New Revision: 265495 URL: https://gcc.gnu.org/viewcvs?rev=265495=gcc=rev Log: Use signed char in a test (PR testsuite/87739). 2018-10-25 Martin Liska PR testsuite/87739 * gcc.dg/tree-ssa/pr84436-5.c (foo): Use signed char. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr84436-5.c
[Bug other/87735] [9 regression] gcc.dg/tree-prof/time-profiler-1.c and -2.c and -3.c fail starting with r265454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87735 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed.
[Bug other/87735] [9 regression] gcc.dg/tree-prof/time-profiler-1.c and -2.c and -3.c fail starting with r265454
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87735 --- Comment #4 from Martin Liška --- Author: marxin Date: Thu Oct 25 15:36:12 2018 New Revision: 265494 URL: https://gcc.gnu.org/viewcvs?rev=265494=gcc=rev Log: Revert partially changes from r265454 (PR other/87735). 2018-10-25 Martin Liska PR other/87735 * gcc.dg/tree-prof/time-profiler-1.c: Revert. * gcc.dg/tree-prof/time-profiler-2.c: Likewise. * gcc.dg/tree-prof/time-profiler-3.c: Likewise. 2018-10-25 Martin Liska PR other/87735 * libgcov-profiler.c: Revert. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-prof/time-profiler-1.c trunk/gcc/testsuite/gcc.dg/tree-prof/time-profiler-2.c trunk/gcc/testsuite/gcc.dg/tree-prof/time-profiler-3.c trunk/libgcc/ChangeLog trunk/libgcc/libgcov-profiler.c
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Thu Oct 25 15:34:04 2018 New Revision: 265493 URL: https://gcc.gnu.org/viewcvs?rev=265493=gcc=rev Log: PR libstdc++/87749 fix (and optimize) string move construction The move constructor for the SSO string uses assign(const basic_string&) when either: (1) the source string is "local" and so the contents of the small string buffer need to be copied, or (2) the allocator does not propagate and is_always_equal is false. Case (1) is suboptimal, because the assign member is not noexcept and the compiler isn't smart enough to see it won't actually throw in this case. This causes extra code in the move assignment operator so that any exception will be turned into a call to std::terminate. This can be fixed by copying small strings inline instead of calling assign. Case (2) is a bug, because the specific instances of the allocators could be equal even if is_always_equal is false. This can result in an unnecessary deep copy (and potentially-throwing allocation) when the storage should be moved. This can be fixed by simply checking if the allocators are equal. PR libstdc++/87749 * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::operator=(basic_string&&)): For short strings copy the buffer inline. Only fall back to using assign(const basic_string&) to do a deep copy when reallocation is needed. * testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/char/ move_assign_optim.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc: New test. * testsuite/21_strings/basic_string/modifiers/assign/wchar_t/ move_assign_optim.cc: New test. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/87749.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/char/move_assign_optim.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/87749.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/assign/wchar_t/move_assign_optim.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #15 from Wilco --- > This will correctly align the outgoing arguments to fails to align the > outgoing arguments. The STACK_DYNAMIC_OFFSET definitions in rs6000.h and > aix.h are correct. Note RS6000_STARTING_FRAME_OFFSET also needs to be updated, again the definition in aix.h is correct.
[Bug target/87723] [9 Regression] ICE: output_operand: invalid %-code on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87723 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2018-10-24 00:00:00 |2018-10-25 Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW CC||tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig --- The idea is to find pieces of code which (gfortran internally) do not have information about where they are. If an error occurs which involves such a piece of code, an ICE would occur. This is mostly done to catch cases when a patch forgets to add this info - it shiws uo on regression testing right away. This is also why this is disabled with checking=release. Maybe we should do something about the warning to make it clearer that this is internal - suggestions welcome. We should also find out where copying localization does not happen.
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #14 from Wilco --- Since DEFAULT_ABI == ABI_DARWIN, the save area is 24 bytes: #define RS6000_SAVE_AREA \ ((DEFAULT_ABI == ABI_V4 ? 8 : DEFAULT_ABI == ABI_ELFv2 ? 16 : 24) \ << (TARGET_64BIT ? 1 : 0)) STACK_BOUNDARY is 128 bit (due to TARGET_ALTIVEC_ABI == 1 on darwin): #define STACK_BOUNDARY \ ((TARGET_32BIT && !TARGET_ALTIVEC && !TARGET_ALTIVEC_ABI && !TARGET_VSX) \ ? 64 : 128) So here is the bug in darwin.h: #undef STACK_DYNAMIC_OFFSET #define STACK_DYNAMIC_OFFSET(FUNDECL) \ (RS6000_ALIGN (crtl->outgoing_args_size.to_constant (), 16) \ + (STACK_POINTER_OFFSET)) This will correctly align the outgoing arguments to fails to align the outgoing arguments. The STACK_DYNAMIC_OFFSET definitions in rs6000.h and aix.h are correct.
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 --- Comment #6 from Jürgen Reuter --- Indeed, with --enable-checking=release on MACOSX and default option (which is --enable-checking=yes) if I understand it correctly, the warning seems not to be present. I didn't test --enable-checking=yes on MACOSX but I believe this could be closed as WORKSFORME.
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #4 from Arthur O'Dwyer --- Hi, I'm the author of P1144 "Object relocation in terms of move plus destroy". Awesome work you've done here! Have you seen my libc++ patch on the same topic as yours? https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-relocatable/ https://github.com/Quuxplusone/libcxx/tree/trivially-relocatable/include Specifically, the piece that I think is still missing from libstdc++'s implementation (besides all the cool stuff that you'd get from the attribute) is the trait `__has_trivial_construct`. This trait allows you to write your `__relocate_a_1` generically, instead of special-casing it for `std::allocator` in particular. (So for example it could also get picked up for `std::pmr::polymorphic_allocator`... even though I guess I didn't implement that part for my libc++ patch, because I'm still waiting on to get merged.) Here's my `__has_trivial_construct`: https://github.com/Quuxplusone/libcxx/blob/99d734b4/include/memory#L5790-L5800 And here's how std::vector uses it (which is significantly different from how libstdc++'s std::vector is arranged, but I'm sure the trait would be the same): https://github.com/Quuxplusone/libcxx/blob/99d734b4/include/vector#L587-L600 I hope we get P1144 so that you don't have to waste time and brain cells specializing `__is_trivially_relocatable` for std::string and std::pair and so on. Complete tangent: I'm confused how vector.tcc is allowed to use "if constexpr" in C++11 mode. https://github.com/gcc-mirror/gcc/commit/e9f84d4c#diff-05b068171cedf9d0176bada75d7dd112R76
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #11 from Martin Liška --- I have a working patch for it.
[Bug testsuite/86158] [9 regression] gcc.c-torture/unsorted/dump-noaddr.c.*i.lto-stream-out fails starting with 261546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86158 --- Comment #10 from seurer at gcc dot gnu.org --- For a while the test case stopped failing (I don't know why but from the results logs it was about 25 June this year around r262009) but just recently it started again (sometime around r264987 on 6 October).
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #13 from Douglas Mencken --- Current repo which HEAD is commit b75be89021ca1da066f892d9a26329009432654c Author: meissner Date: Wed Oct 24 20:16:31 2018 + git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@265471 138bc75d-0d04-0410-961f-82ee72b054a4 r265471 https://gcc.gnu.org/viewcvs/gcc?view=revision=265471 fails the same way build/gencfn-macros.o build/errors.o build/hash-table.o build/vec.o build/ggc-none.o build/sort.o ../../host-powerpc-unknown-darwin/libiberty/libiberty.a build/gencfn-macros -c \ > tmp-case-cfn-macros.h build/gencfn-macros: DEF_INTERNAL_FLT_FN (ACOS) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (ASIN) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (ATAN) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (COS) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (EXP) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (EXP10) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (EXP2) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (EXPM1) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (LOG) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (LOG10) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (LOG1P) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (LOG2) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (LOGB) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (SIN) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (SQRT) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (TAN) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (CEIL) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (FLOOR) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (RINT) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (ROUND) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (TRUNC) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (ATAN2) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (FMOD) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (POW) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (SCALB) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (FMIN) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (FMAX) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (LDEXP) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_FLT_FN (FMA) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_INT_FN (CLRSB) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_INT_FN (CLZ) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_INT_FN (CTZ) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_INT_FN (FFS) has no associated built-in functions build/gencfn-macros: DEF_INTERNAL_INT_FN (PARITY) has no associated built-in functions make[3]: *** [s-case-cfn-macros] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2
[Bug target/85669] fail on s-case-cfn-macros: build/gencfn-macros: DEF_INTERNAL_FLT/INT_FN (%smth%) has no associated built-in functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85669 --- Comment #12 from Douglas Mencken --- I finished it git bisect start git bisect good gcc-7_3_0-release # r257041 git bisect bad gcc-8_1_0-release # r259829 git bisect good 7369309777f6d6e630fb7763bcd08a0317727e36 # r247015 merge parent git bisect bad b50e3690fbcafedefdb888c2d66725b8f405706e # r253946 git bisect skip 61cb18166c6a1507af78ce73a4e3c8a21b0cb8ab # r250239 git bisect good 4f5b1ee8ccfd04b939e07bd99f4ca6f8d3f5aa83 # r249172 git bisect good a5079b7fe2c7b4c862704149db5fb0948a7d02f8 # r251339 git bisect bad 237c1ea8f68a7cc3100b63ee50da05c9e0b0ea6d # r253033 git bisect bad 1f0c90bb95ae0d59c93a97dc12294425831c5080 # r251838 git bisect good bc3e9c9df58c165b0157aabf69b222130c835a63 # r251559 git bisect bad 1694a564a16d2403ba1d80778eaacd49b1a62b2c # r251723 git bisect good 9e9e5c15ab8377f3fedc0dd571a0e29810c8c349 # r251637 git bisect good 0d58671cf9b85d18b3a4d2ec785dd95b6bd604db # r251681 git bisect good 404455fef970eea7f65545ed7ed87501ef925718 # r251700 git bisect good 3daf52f78423515253c156cf5adc94d5e6b00994 # r251711 git bisect bad b0e3c082a4b51073d516d7e308e3720c482019ef # r251717 git bisect bad d29e4e8c5dad17dc1f22c5acf950b13820c7876f # r251714 git bisect bad ef6533727511b05fd7e4c7325bf822f4fc1ae4d8 # r251713 first bad commit: [ef6533727511b05fd7e4c7325bf822f4fc1ae4d8] Improve alloca alignment ef6533727511b05fd7e4c7325bf822f4fc1ae4d8 is the first bad commit commit ef6533727511b05fd7e4c7325bf822f4fc1ae4d8 Author: wilco https://gcc.gnu.org/viewcvs/gcc?view=revision=251713
[Bug bootstrap/87747] [9 regression] Bootstrap failure if using gcc-4.6 as stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747 --- Comment #3 from iii at gcc dot gnu.org --- Author: iii Date: Thu Oct 25 13:47:10 2018 New Revision: 265488 URL: https://gcc.gnu.org/viewcvs?rev=265488=gcc=rev Log: Fix rtx_code_size static initialization order fiasco r264556 and r264537 changed the format of EQ_ATTR_ALT RTXs to "ww", which also required adjusting rtx_code_size initializer. In order to simplify things, the list of rtx_codes known to use HOST_WIDE_INTs was replaced by the format string check. However, unlike the old one, this new check cannot be always performed at compile time, in which case a static constructor is generated. This may lead to a static initialization order fiasco with respect to other static constructors in the compiler, in case of PR87747, cselib's pool_allocator. gcc/ChangeLog: 2018-10-25 Ilya Leoshkevich PR bootstrap/87747 * rtl.c (RTX_CODE_HWINT_P_1): New helper macro. (RTX_CODE_HWINT_P): New macro. (rtx_code_size): Use RTX_CODE_HWINT_P (). Modified: trunk/gcc/ChangeLog trunk/gcc/rtl.c
[Bug tree-optimization/87745] [9 regression] ICE in get_later_stmt, at tree-vectorizer.h:1109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87745 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Oct 25 13:46:20 2018 New Revision: 265487 URL: https://gcc.gnu.org/viewcvs?rev=265487=gcc=rev Log: 2018-10-25 Richard Biener PR tree-optimization/87665 PR tree-optimization/87745 * tree-vectorizer.h (get_earlier_stmt): Remove. (get_later_stmt): Pick up UID from the original non-pattern stmt. * gfortran.dg/20181025-1.f: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/20181025-1.f Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vectorizer.h
[Bug tree-optimization/87665] [6/7 Regression] gcc HEAD (svn: 265340) breaks elements on resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87665 --- Comment #19 from Richard Biener --- Author: rguenth Date: Thu Oct 25 13:46:20 2018 New Revision: 265487 URL: https://gcc.gnu.org/viewcvs?rev=265487=gcc=rev Log: 2018-10-25 Richard Biener PR tree-optimization/87665 PR tree-optimization/87745 * tree-vectorizer.h (get_earlier_stmt): Remove. (get_later_stmt): Pick up UID from the original non-pattern stmt. * gfortran.dg/20181025-1.f: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/20181025-1.f Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-vectorizer.h
[Bug bootstrap/87747] [9 regression] Bootstrap failure if using gcc-4.6 as stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747 --- Comment #2 from Ilya Leoshkevich --- This is a little bit more complicated, because EQ_ATTR_ALT is valid only for GENERATOR_FILEs. The regtest has just finished, so I will post the patch to the mailing list now.
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #3 from Marc Glisse --- Author: glisse Date: Thu Oct 25 13:03:13 2018 New Revision: 265485 URL: https://gcc.gnu.org/viewcvs?rev=265485=gcc=rev Log: Relocation (= move+destroy) 2018-10-25 Marc Glisse PR libstdc++/87106 * include/bits/alloc_traits.h (_S_construct, _S_destroy, construct, destroy): Add noexcept specification. * include/bits/allocator.h (construct, destroy): Likewise. * include/ext/alloc_traits.h (construct, destroy): Likewise. * include/ext/malloc_allocator.h (construct, destroy): Likewise. * include/ext/new_allocator.h (construct, destroy): Likewise. * include/bits/stl_uninitialized.h (__relocate_object_a, __relocate_a, __relocate_a_1): New functions. (__is_trivially_relocatable): New class. * include/bits/stl_vector.h (__use_relocate): New static member. * include/bits/vector.tcc (reserve, _M_realloc_insert, _M_default_append): Use __relocate_a. (reserve, _M_assign_aux, _M_realloc_insert, _M_fill_insert, _M_default_append, _M_range_insert): Move _GLIBCXX_ASAN_ANNOTATE_REINIT after _Destroy. * testsuite/23_containers/vector/modifiers/push_back/49836.cc: Replace CopyConsOnlyType with DelAnyAssign. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/alloc_traits.h trunk/libstdc++-v3/include/bits/allocator.h trunk/libstdc++-v3/include/bits/stl_uninitialized.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/vector.tcc trunk/libstdc++-v3/include/ext/alloc_traits.h trunk/libstdc++-v3/include/ext/malloc_allocator.h trunk/libstdc++-v3/include/ext/new_allocator.h trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/49836.cc
[Bug fortran/87255] Different semantics of OpenMP combined construct and nested constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87255 --- Comment #2 from Jakub Jelinek --- I'm aware of this, but fixing it without actually penalizing performance won't be very easy. Have been also waiting on what will be voted into OpenMP 5.0 here, in the end it says that the expressions are to be evaluated before the outermost composite loop construct, but not before the outermost combined construct, even when at some point the suggestion was to evaluate it before the outermost combined construct, which would make this report invalid.
[Bug fortran/87255] Different semantics of OpenMP combined construct and nested constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87255 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-25 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for gcc8.2 and trunk (9.0).
[Bug fortran/87043] maybe-uninitialized warning for initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87043 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Thomas Koenig --- From the documentation of -Wmaybe-uninitialized: "These warnings are only possible in optimizing compilation, because otherwise GCC does not keep track of the state of variables. " Maybe you could try -Og, this should strike a good balance between optimization and debugging. Closing.
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-10-25 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- I cannot reproduce it on x86_64-apple-darwin17 with various revisions configured with --enable-checking=release or --enable-checking=yes.
[Bug bootstrap/87747] [9 regression] Bootstrap failure if using gcc-4.6 as stage1 compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87747 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |9.0 --- Comment #1 from Richard Biener --- Expanding the || test is probably the fix.
[Bug c++/87748] [8/9 Regression] G++-8 treats SFINAE as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug tree-optimization/87746] [9 Regression] ICE in vect_update_misalignment_for_peel, at tree-vect-data-refs.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87746
--- Comment #6 from Richard Biener ---
Actually much simpler and correct like the following but test coverage for
peeling seems to be low.
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 9185b1bd1c0..20ecbfb45b7 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -1010,20 +1010,10 @@ vect_update_misalignment_for_peel (dr_vec_info
*dr_info,
unsigned int i;
vec same_aligned_drs;
struct data_reference *current_dr;
- int dr_size = vect_get_scalar_dr_size (dr_info);
- int dr_peel_size = vect_get_scalar_dr_size (dr_peel_info);
- stmt_vec_info stmt_info = dr_info->stmt;
stmt_vec_info peel_stmt_info = dr_peel_info->stmt;
- /* For interleaved data accesses the step in the loop must be multiplied by
- the size of the interleaving group. */
- if (STMT_VINFO_GROUPED_ACCESS (stmt_info))
-dr_size *= DR_GROUP_SIZE (DR_GROUP_FIRST_ELEMENT (stmt_info));
- if (STMT_VINFO_GROUPED_ACCESS (peel_stmt_info))
-dr_peel_size *= DR_GROUP_SIZE (peel_stmt_info);
-
- /* It can be assumed that the data refs with the same alignment as dr_peel
- are aligned in the vector loop. */
+ /* It can be assumed that if dr_info has the same alignment as dr_peel,
+ it is aligned in the vector loop. */
same_aligned_drs = STMT_VINFO_SAME_ALIGN_REFS (peel_stmt_info);
FOR_EACH_VEC_ELT (same_aligned_drs, i, current_dr)
{
@@ -1031,8 +1021,8 @@ vect_update_misalignment_for_peel (dr_vec_info *dr_info,
continue;
gcc_assert (!known_alignment_for_access_p (dr_info)
|| !known_alignment_for_access_p (dr_peel_info)
- || (DR_MISALIGNMENT (dr_info) / dr_size
- == DR_MISALIGNMENT (dr_peel_info) / dr_peel_size));
+ || (DR_MISALIGNMENT (dr_info)
+ == DR_MISALIGNMENT (dr_peel_info)));
SET_DR_MISALIGNMENT (dr_info, 0);
return;
}
@@ -1040,10 +1030,8 @@ vect_update_misalignment_for_peel (dr_vec_info *dr_info,
if (known_alignment_for_access_p (dr_info)
&& known_alignment_for_access_p (dr_peel_info))
{
- bool negative = tree_int_cst_compare (DR_STEP (dr_info->dr),
- size_zero_node) < 0;
int misal = DR_MISALIGNMENT (dr_info);
- misal += negative ? -npeel * dr_size : npeel * dr_size;
+ misal += npeel * TREE_INT_CST_LOW (DR_STEP (dr_info->dr));
misal &= DR_TARGET_ALIGNMENT (dr_info) - 1;
SET_DR_MISALIGNMENT (dr_info, misal);
return;
[Bug libstdc++/87749] [6/7/8/9 Regression] std::__cxx11::basic_string move assignment does deep copy unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87749 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-25 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
