[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
--- Comment #9 from rguenther at suse dot de ---
On April 29, 2019 9:23:21 PM GMT+02:00, "eyalroz at technion dot ac.il"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271
>
>--- Comment #8 from Eyal Rozenberg ---
>(In reply to rguent...@suse.de from comment #5)
>> int foo3()
>> {
>> struct { int x; int y; } s;
>> s.x = 3;
>> char c = 1;
>> return replace_bytes_3(&s.x,c);
>> }
>>
>> Coalescing successful!
>> Merged into 1 stores
>
>This is very interesting! Do you think I could somehow adapt this
>example into
>a workaround, for existing GCC versions, rather than wait for the bug
>fix?
You'd have to experiment with different GCC versions, but yes.
[Bug web/89770] move java-related mailing lists on lists.html to the "Historical lists" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89770 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed.
[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273
--- Comment #24 from Jakub Jelinek ---
(In reply to Alexandre Oliva from comment #23)
> > what are the rules of which ones we can remove? Can we always just keep the
> last? What about location differences? What about possibly interleaving
> DEBUG_BEGIN stmts?
I think Richard's patch only considers debug bind stmts next to each other, any
other stmt like DEBUG BEGIN_STMT, etc. reset the table (i.e. stop the
elimination).
> When you ask about location differences, it's not clear whether you're
> asking about binding values (used in location lists) or source line
> locations. It's not always viable to tell whether binding expressions are
> equivalent, but the last one prevails except at control flow confluences,
> and var-tracking deals with that much later. As for source line locations,
> I don't think they're relevant in debug bind statements.
My understanding is that we completely ignore gimple_location from debug bind
stmts. While debug stmts and later DEBUG_INSNs do have location, the
-fcompare-debug rules should make sure that other stmts/insns location is not
affected by the locations of the debug stmts/insns. And, var-tracking replaces
the DEBUG_INSNs with NOTE_INSN_VAR_LOCATION notes that do not have a locus.
> > my guess that debug temps are always in the same BB as uses is wrong.
>
> they can be bound in one BB and used in another, indeed. they may even be
> bound in multiple BBs and used in multiple other BBs, and then var-tracking
> will attempt to identify shared values in incoming exprs at confluence
> points. we don't do that very much, but we could. even without that, there
> are cases in which we issue temp binds in one block and reference them in
> another, even when we're not sure one reaches the other: var-tracking sorts
> that out eventually.
Besides Richard's eliminate_unnecessary_stmts patch, which you've acked and I'm
going to install soon, there are other patches (GCC 10 only presumably): #c11
and #c16, what do you think about those? The former canonicalizes {CLOBBER}
values of debug stmts to NULL, the latter tries to remove debug stmts for
variables which are not referenced in the function at all and have only NULL
debug binds for them; I believe in such cases the debug insns don't provide
anything over the optimized away vars in the body.
Another thing is if we could also remove DEBUG_EXPR_DECLs by doing analysis
similar to #c16, look through all debug bind stmts, see what DEBUG_EXPR_DECLs
they are refering to, and if there are DEBUG_EXPR_DECLs which are not
referenced in any of them and they aren't referenced in decl_debug_args_lookup
either, just
remove debug bind stmts for those DEBUG_EXPR_DECLs. Similarly, would it be
useful to reset debug bind stmts if they refer to DEBUG_EXPR_DECLs that are
never set (or do it only for some simple cases where we couldn't figure out any
location from the expr)?
[Bug debug/90288] New: -g{no,}as-locview-support missing the leading dash in the documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90288
Bug ID: 90288
Summary: -g{no,}as-locview-support missing the leading dash in
the documentation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
The man pages, as well as the HTML documentation are missing the leading dash
in the -gas-locview-support and -gno-as-locview-support options:
-gno-as-loc-support
Force GCC to generate DWARF2+ line number tables internally, if DWARF2+
line number tables are to be generated.
gas-locview-support
Inform the compiler that the assembler supports "view" assignment and reset
assertion checking in ".loc" directives.
This option will be enabled by default if, at GCC configure time, the
assembler was found to support them.
gno-as-locview-support
Force GCC to assign view numbers internally, if -gvariable-location-views
are explicitly requested.
This can be seen in the online docs as well:
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Debugging-Options.html#Debugging-Options
[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273 --- Comment #25 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 07:40:06 2019 New Revision: 270674 URL: https://gcc.gnu.org/viewcvs?rev=270674&root=gcc&view=rev Log: PR tree-optimization/90273 * tree-ssa-dce.c (eliminate_unnecessary_stmts): Eliminate useless debug stmts. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/tree-ssa-dce.c
[Bug tree-optimization/90271] [missed-optimization] failure to keep variables in registers during "faux" memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90271 --- Comment #10 from Eyal Rozenberg --- (In reply to rguent...@suse.de from comment #9) > You'd have to experiment with different GCC versions, but yes. I was hoping for a more concrete suggestion (which works with multiple GCC versions)...
[Bug debug/90279] DW_AT_location missing for struct-based Variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90279
Jaydeep Chauhan changed:
What|Removed |Added
CC||jaydeepchauhan1494 at gmail
dot co
||m
--- Comment #1 from Jaydeep Chauhan ---
In clang also DW_AT_location attribute is created.
test.cpp:
--
struct StrongType {
explicit StrongType(int val) : m_value(val) { }
int m_value;
};
StrongType Square(StrongType val) {
return StrongType{val.m_value * val.m_value};
}
int EvalDwarfStrong(int var) {
StrongType strongArg{var};
StrongType strongRes = Square(strongArg);
return strongRes.m_value;
}
clang test.cpp -g -S -std=c++11 -Og:
--
...
...
.Linfo_string14:
.asciz "strongArg" # string offset=202
...
...
.byte 14 # Abbrev [14] 0xeb:0xf DW_TAG_variable
.long .Ldebug_loc2# DW_AT_location
.long .Linfo_string14 # DW_AT_name
.byte 1 # DW_AT_decl_file
.byte 11 # DW_AT_decl_line
.long 87 # DW_AT_type
...
...
[Bug c++/89325] [7/8/9/10 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89325
Agner Fog changed:
What|Removed |Added
CC||agner at agner dot org
--- Comment #5 from Agner Fog ---
I have the same problem.
Minimal test case:
#include
struct Test {
float f;
};
Test round(Test const & a) __attribute__
((optimize("-fno-unsafe-math-optimizations")));
Test round(Test const & a) {return a;}
[Bug other/90286] failure in arduino
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90286 --- Comment #3 from Jonathan Wakely --- On Fedora the Arduino IDE uses GCC 7.4, so it's possible to build a newer one. Whoever you got your Arduino toolchain from needs to update it and provide you a newer one. That's not the responsibility of the GCC project, so we can't help you here.
[Bug translation/90274] untranslated string literal in opts.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90274 --- Comment #2 from Martin Liška --- Author: marxin Date: Tue Apr 30 08:33:29 2019 New Revision: 270675 URL: https://gcc.gnu.org/viewcvs?rev=270675&root=gcc&view=rev Log: Wrap a string with _ for translation (PR translation/90274). 2019-04-30 Martin Liska PR translation/90274 * opts.c (print_filtered_help): Wrap string in _(...). Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug middle-end/90258] [9 Regression] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 --- Comment #5 from Martin Liška --- Author: marxin Date: Tue Apr 30 08:35:28 2019 New Revision: 270676 URL: https://gcc.gnu.org/viewcvs?rev=270676&root=gcc&view=rev Log: Subject: Backport r270622 2019-04-30 Martin Liska Backport from mainline 2019-04-27 Martin Liska PR middle-end/90258 * opt-suggestions.c (option_proposer::build_option_suggestions): When get_valid_option_values returns empty values, add the misspelling candidate. 2019-04-30 Martin Liska Backport from mainline 2019-04-27 Martin Liska PR middle-end/90258 * gcc.dg/completion-5.c: New test. * gcc.target/i386/spellcheck-options-5.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/completion-5.c branches/gcc-9-branch/gcc/testsuite/gcc.target/i386/spellcheck-options-5.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/opt-suggestions.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug middle-end/90258] Missing completion for a target option since r264052
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90258 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Summary|[9 Regression] Missing |Missing completion for a |completion for a target |target option since r264052 |option since r264052| Known to fail|9.0 | --- Comment #6 from Martin Liška --- Fixed on all active branches.
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #11 from Thomas De Schampheleire --- It seems the necessary patch is applied now, are these the only changes The target milestone is set 7.5. Do you have any rough idea when that would be released?
[Bug translation/90274] untranslated string literal in opts.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90274 --- Comment #3 from Martin Liška --- Author: marxin Date: Tue Apr 30 08:51:23 2019 New Revision: 270677 URL: https://gcc.gnu.org/viewcvs?rev=270677&root=gcc&view=rev Log: Subject: Backport r270675 2019-04-30 Martin Liska Backport from mainline 2019-04-30 Martin Liska PR translation/90274 * opts.c (print_filtered_help): Wrap string in _(...). Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/opts.c
[Bug translation/90274] untranslated string literal in opts.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90274 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||10.0, 9.0 Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed, closing.
[Bug tree-optimization/89475] Teach ccp about __builtin_bswap{16,32,64}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89475
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 30 09:07:28 2019
New Revision: 270680
URL: https://gcc.gnu.org/viewcvs?rev=270680&root=gcc&view=rev
Log:
PR tree-optimization/89475
* tree-ssa-ccp.c (evaluate_stmt): Handle BUILT_IN_BSWAP{16,32,64}
calls.
* gcc.dg/tree-ssa/pr89475.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr89475.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-store-merging.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c
[Bug c/37369] ice for legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37369 --- Comment #4 from Richard Earnshaw --- Author: rearnsha Date: Tue Apr 30 09:25:31 2019 New Revision: 270683 URL: https://gcc.gnu.org/viewcvs?rev=270683&root=gcc&view=rev Log: PR target/90075 Prefer bsl/bit/bif for copysignf. (backport GCC-8) This patch is to fix the ICE caused in expand pattern of copysignf builtin. This is a back port to r267019 of trunk. gcc: 2019-04-29 Srinath Parvathaneni Backport from mainline 2018-12-11 Richard Earnshaw PR target/37369 * config/aarch64/iterators.md (sizem1): Add sizes for SFmode and DFmode. (Vbtype): Add SFmode mapping. * config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete. (copysign3): New expand pattern. (copysign3_insn): New insn pattern. testsuite: 2019-04-29 Srinath Parvathaneni PR target/90075 * gcc.target/aarch64/pr90075.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/pr90075.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/aarch64/aarch64.md branches/gcc-8-branch/gcc/config/aarch64/iterators.md branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 --- Comment #7 from Richard Earnshaw --- Author: rearnsha Date: Tue Apr 30 09:25:31 2019 New Revision: 270683 URL: https://gcc.gnu.org/viewcvs?rev=270683&root=gcc&view=rev Log: PR target/90075 Prefer bsl/bit/bif for copysignf. (backport GCC-8) This patch is to fix the ICE caused in expand pattern of copysignf builtin. This is a back port to r267019 of trunk. gcc: 2019-04-29 Srinath Parvathaneni Backport from mainline 2018-12-11 Richard Earnshaw PR target/37369 * config/aarch64/iterators.md (sizem1): Add sizes for SFmode and DFmode. (Vbtype): Add SFmode mapping. * config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete. (copysign3): New expand pattern. (copysign3_insn): New insn pattern. testsuite: 2019-04-29 Srinath Parvathaneni PR target/90075 * gcc.target/aarch64/pr90075.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/aarch64/pr90075.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/aarch64/aarch64.md branches/gcc-8-branch/gcc/config/aarch64/iterators.md branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/90140] Compiler incorrectly rejects use of pure functions in DIMENSION attribute of procedure dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90140 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 7.4.0 up to trunk (10.0). From 4.9 up to 6.5.0 the errors are pr90140.f90:38:35: real(wp), dimension(ncol,nlay, this%get_ngas()) :: vmr 1 Error: 'get_ngas' at (1) should be a FUNCTION pr90140.f90:39:37: real(wp), dimension(ncol,nlay,0:this%get_ngas()) :: col_gas 1 Error: 'get_ngas' at (1) should be a FUNCTION The behavior changed between revisions r247817 (2017-05-09, two errors) and r248367 (2017-05-23, three errors) and the change has been back ported to the GCC7 branch. For 4.8.5 I get additional errors Error: Function 'this' at (1) must be PURE Work around: replace this%get_ngas() with get_ngas(this).
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 --- Comment #8 from Richard Earnshaw --- Author: rearnsha Date: Tue Apr 30 09:31:04 2019 New Revision: 270684 URL: https://gcc.gnu.org/viewcvs?rev=270684&root=gcc&view=rev Log: PR target/90075 Prefer bsl/bit/bif for copysignf. (backport GCC-7) This patch is to fix the ICE caused by expand pattern of copysignf builtin. This is a back port to r267019 of trunk. gcc: 2019-04-30 Srinath Parvathaneni PR target/90075 * config/aarch64/iterators.md (V_INT_EQUIV): Add mode for integer equivalent of floating point values. Backport from mainline 2018-12-11 Richard Earnshaw PR target/37369 * config/aarch64/iterators.md (sizem1): Add sizes for SFmode and DFmode. (Vbtype): Add SFmode mapping. * config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete. (copysign3): New expand pattern. (copysign3_insn): New insn pattern. testsuite: 2019-04-30 Srinath Parvathaneni PR target/90075 * gcc.target/aarch64/pr90075.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr90075.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64.md branches/gcc-7-branch/gcc/config/aarch64/iterators.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c/37369] ice for legal C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37369 --- Comment #5 from Richard Earnshaw --- Author: rearnsha Date: Tue Apr 30 09:31:04 2019 New Revision: 270684 URL: https://gcc.gnu.org/viewcvs?rev=270684&root=gcc&view=rev Log: PR target/90075 Prefer bsl/bit/bif for copysignf. (backport GCC-7) This patch is to fix the ICE caused by expand pattern of copysignf builtin. This is a back port to r267019 of trunk. gcc: 2019-04-30 Srinath Parvathaneni PR target/90075 * config/aarch64/iterators.md (V_INT_EQUIV): Add mode for integer equivalent of floating point values. Backport from mainline 2018-12-11 Richard Earnshaw PR target/37369 * config/aarch64/iterators.md (sizem1): Add sizes for SFmode and DFmode. (Vbtype): Add SFmode mapping. * config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete. (copysign3): New expand pattern. (copysign3_insn): New insn pattern. testsuite: 2019-04-30 Srinath Parvathaneni PR target/90075 * gcc.target/aarch64/pr90075.c: New test. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/aarch64/pr90075.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/aarch64/aarch64.md branches/gcc-7-branch/gcc/config/aarch64/iterators.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Earnshaw --- Fixed on gcc-7 and gcc-8
[Bug fortran/90218] [PDT] ICE: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.c:6071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90218 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 8.3.0 up to trunk (10.0).
[Bug c/90289] New: an unnecessary relocation record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90289
Bug ID: 90289
Summary: an unnecessary relocation record
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chen...@agile-china.com
Target Milestone: ---
In the below code. Is it an unnecessary relocation record for function 'f()'?
Is it better to fill "F3 FF FF FF" in CALL instruction directly?
* uname -a
Linux ubuntu 3.13.0-32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:50:54
UTC 2014 i686 i686 i386 GNU/Linux
* gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
* cat test.c
void f() {}
void fun()
{
f();
}
* gcc -c f.c -g -Wall
* objdump -S f.o
:
void f() {}
0: 55 push %ebp
1: 89 e5mov%esp,%ebp
3: 5d pop%ebp
4: c3 ret
0005 :
void fun()
{
5: 55 push %ebp
6: 89 e5mov%esp,%ebp
f();
8: e8 fc ff ff ff call 9
}
* objdump -r f.o
0009 R_386_PC32f
* gcc -shared f.o -o libf.so
* objdump -S libf.so
042c :
void f() {}
42c: 55 push %ebp
42d: 89 e5mov%esp,%ebp
42f: 5d pop%ebp
430: c3 ret
0431 :
void fun()
{
431: 55 push %ebp
432: 89 e5mov%esp,%ebp
f();
434: e8 fc ff ff ff call 435
}
* objdump -R libf.so
0435 R_386_PC32f
[Bug fortran/90290] New: -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 Bug ID: 90290 Summary: -std=f2008 should reject non-constant stop and error stop codes Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thenlich+gccbug at gmail dot com Target Milestone: --- According to Fortran 2008, a stop-code in a stop-stmt or error-stop-stmt must be either scalar-default-char-constant-expr or scalar-int-constant-expr (Fortran 2018: scalar-default-char-expr or scalar-int-expr) The following: program errorstop integer :: ec read *, ec stop ec end program compiles successfully with -std=f2008. It should not: while the program is Fortran 2018 compliant, it is not Fortran 2008 compliant.
[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Dominique d'Humieres --- Confirmed as a very minor offense.
[Bug c++/90291] New: [7/8 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291
Bug ID: 90291
Summary: [7/8 Regression] Inline namespace erroneously extends
another namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: igusarov at mail dot ru
Target Milestone: ---
Compilation of the following code with gcc 7.x and 8.x produces different
results:
inline namespace A
{
inline namesapce B // (1)
{
void foo() {}
}
}
inline namespace B // (2)
{
inline namesapce A
{
void foo() {}
}
}
If compiled with "gcc-7.4 -std=c++11 -c", the object file contains functions
A::B::foo()
B::A::foo()
which I believe is correct.
However, if the same source is compiled with "gcc-8.3 -std=c++11 -c", the
object file contains functions
A::B::foo()
A::B::A::foo()
which I believe is wrong.
It looks like gcc 8.x assumes that the namespace at line (2) doesn't start a
new top-level namespace, but extends the namespace defined at line (1).
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-30 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug target/87833] [9/10 Regression] Intel MIC (emulated) offloading: "relocation [...] can not be used when making a shared object; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87833 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 Summary|Intel MIC (emulated)|[9/10 Regression] Intel MIC |offloading: "relocation |(emulated) offloading: |[...] can not be used when |"relocation [...] can not |making a shared object; |be used when making a |recompile with -fPIC" |shared object; recompile ||with -fPIC" Ever confirmed|0 |1
[Bug rtl-optimization/89721] __builtin_mffs sometimes optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721 --- Comment #5 from Segher Boessenkool --- No, it needs backports. Thanks for reminding me!
[Bug target/65342] [7/8/9/10 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9/10 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #24 from Segher Boessenkool --- (In reply to Alan Modra from comment #10) > > permitted? (i.e. modifying %1, which is an input operand) > > Yes. You're outputting assembly, practically anything goes. But the generate machine code will modify that reg, while the compiler does not know.
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 Ramana Radhakrishnan changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2019-04-30 CC||ramana at gcc dot gnu.org Resolution|WONTFIX |--- Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan --- reopening and taking.
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 --- Comment #4 from Ramana Radhakrishnan --- Author: ramana Date: Tue Apr 30 11:22:11 2019 New Revision: 270686 URL: https://gcc.gnu.org/viewcvs?rev=270686&root=gcc&view=rev Log: [Patch AArch64] Add __ARM_FEATURE_ATOMICS This keeps coming up repeatedly and the ACLE has finally added __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of the latest ACLE release (https://developer.arm.com/docs/101028/latest/5-feature-test-macros) I know it's late for GCC-9 but this is a simple macro which need not wait for another year. Ok for trunk and to backport to all release branches ? Tested with a simple build and a smoke test. PR target/86538 * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define __ARM_FEATURE_ATOMICS Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-c.c
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 --- Comment #5 from Ramana Radhakrishnan --- Author: ramana Date: Tue Apr 30 12:02:30 2019 New Revision: 270689 URL: https://gcc.gnu.org/viewcvs?rev=270689&root=gcc&view=rev Log: [Patch AArch64] Add __ARM_FEATURE_ATOMICS This keeps coming up repeatedly and the ACLE has finally added __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of the latest ACLE release (https://developer.arm.com/docs/101028/latest/5-feature-test-macros) I know it's late for GCC-9 but this is a simple macro which need not wait for another year. Ok for trunk and to backport to all release branches ? Tested with a simple build and a smoke test. Backport from mainline. PR target/86538 * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define __ARM_FEATURE_ATOMICS Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/aarch64/aarch64-c.c
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #84 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 12:07:27 2019 New Revision: 270690 URL: https://gcc.gnu.org/viewcvs?rev=270690&root=gcc&view=rev Log: PR target/89093 * config/aarch64/aarch64.c (aarch64_process_one_target_attr): Don't skip whitespace at the start of target attribute string. * gcc.target/aarch64/pr89093.c: New test. * gcc.target/aarch64/pr63304_1.c: Remove space from target string. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr89093.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
[Bug tree-optimization/89475] Teach ccp about __builtin_bswap{16,32,64}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89475 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for GCC 10.
[Bug middle-end/90263] Calls to mempcpy should use memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263 Martin Liška changed: What|Removed |Added Attachment #46262|0 |1 is obsolete|| --- Comment #19 from Martin Liška --- Created attachment 46265 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46265&action=edit Patch candidate v2 Update patch that should be fine. Tests on x86_64 work except: FAIL: gcc.c-torture/execute/builtins/mempcpy.c execution, -O1 Where the test expects that mempcpy without LHS should be transformed into memcpy.
[Bug middle-end/90283] 519.lbm_r is 7%-10% slower with -Ofast -march=native and both LTO and PGO than with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Created attachment 46266 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46266&action=edit perf annotate - bad - r260348
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||7.3.0 Keywords||wrong-code Last reconfirmed||2019-04-30 CC||nathan at gcc dot gnu.org Ever confirmed|0 |1 Summary|[7/8 Regression] Inline |[8/9/10 Regression] Inline |namespace erroneously |namespace erroneously |extends another namespace |extends another namespace Known to fail||10.0, 8.3.1, 9.0 --- Comment #1 from Jonathan Wakely --- [7/8 Regression] means it's a regression in GCC 7, so is wrong for this bug. It should be [8/9/10 Regression]. This started with r248521 gcc/ Implement DR2061 * name-lookup.c (push_inline_namespaces): New. (push_namespace): Look inside inline namespaces. testsuite/ * g++.dg/cpp0x/dr2061.C: New. * g++.dg/parse/namespace-alias-1.C: Add more test.
[Bug middle-end/90283] 519.lbm_r is 7%-10% slower with -Ofast -march=native and both LTO and PGO than with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283 --- Comment #2 from Martin Liška --- Created attachment 46267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46267&action=edit perf annotate - good - r260347
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291
--- Comment #2 from Jonathan Wakely ---
Testcase without typos:
inline namespace A
{
inline namespace B // (1)
{
void foo() {}
}
}
inline namespace B // (2)
{
inline namespace A
{
void foo() {}
}
}
[Bug middle-end/90283] 519.lbm_r is 7%-10% slower with -Ofast -march=native and both LTO and PGO than with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- The perf comes from an Intel Skylake server machine. The number of fma is very similar: grep fma bad.report.txt | wc -l 126 grep fma good.report.txt | wc -l 128 But the assembly is shuffled quite significantly after the change. Can you Richard Sandiford please take a look?
[Bug debug/90288] -g{no,}as-locview-support missing the leading dash in the documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90288 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-30 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, thanks for reporting.
[Bug debug/90288] -g{no,}as-locview-support missing the leading dash in the documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90288 --- Comment #2 from Martin Liška --- Author: marxin Date: Tue Apr 30 13:31:22 2019 New Revision: 270692 URL: https://gcc.gnu.org/viewcvs?rev=270692&root=gcc&view=rev Log: Add missing dash for 2 options in documentation (PR debug/90288). 2019-04-30 Martin Liska PR debug/90288 * doc/invoke.texi: Add missing dash for gas-locview-support and gno-as-locview-support. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug debug/90288] -g{no,}as-locview-support missing the leading dash in the documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90288 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug c++/90284] -Wunused-value points to the wrong expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90284 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 CC||dmalcolm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed. It's only related to C++, because for C we get: gcc -Wunused-value pr90284.c pr90284.c: In function ‘incorrect_warning’: pr90284.c:3:22: warning: left-hand operand of comma expression has no effect [-Wunused-value] 3 | return (0 ? 0 : 0, 999); | ^ pr90284.c: In function ‘correct_warning’: pr90284.c:8:14: warning: left-hand operand of comma expression has no effect [-Wunused-value] 8 | return (0, 999); | ^ So a possible enhancement. For C++ there was improvement of the second test-case by David in r267272: pr90284.c:8:16: warning: left operand of comma operator has no effect [-Wunused-value] return (0, 999); ^~~ after: pr90284.c:8:13: warning: left operand of comma operator has no effect [-Wunused-value] 8 | return (0, 999); | ^ I'm leaving that to David, hopefully he can fix it.
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761
Jan van Dijk changed:
What|Removed |Added
CC||j.v.dijk at tue dot nl
--- Comment #2 from Jan van Dijk ---
Is it not perfectly fine that your patch works only for _Tp equal to float,
double or long double? Anything else is unspecified per 24.5(2). Does libstdc++
advertise to go beyond the standard and support other scalar types as well?
(And if so: is that policy documented anywhere?)
That said, I think that the correct patch would be:
Index: libstdc++-v3/include/std/complex
===
--- libstdc++-v3/include/std/complex(revision 270684)
+++ libstdc++-v3/include/std/complex(working copy)
@@ -1902,11 +1902,9 @@
std::complex<_Tp>
__complex_proj(const std::complex<_Tp>& __z)
{
- const _Tp __den = (__z.real() * __z.real()
-+ __z.imag() * __z.imag() + _Tp(1.0));
-
- return std::complex<_Tp>((_Tp(2.0) * __z.real()) / __den,
- (_Tp(2.0) * __z.imag()) / __den);
+ if (isinf(__z.real()) || isinf(__z.imag()))
+return std::complex<_Tp>(INFINITY, copysign(0.0, __z.imag()));
+ return __z;
}
#if _GLIBCXX_USE_C99_COMPLEX
Note that the combinations finite,nan and nan,finite should return __z
unmodified. As the OP mentions, this was a problem in glibc as well that was
later fixed, see: https://sourceware.org/ml/libc-alpha/2013-08/msg00374.html
The patch above makes libstdc++ do exactly what is also found in current
glibc's implementation in s_cproj_template.c
[Bug middle-end/90283] 519.lbm_r is 7%-10% slower with -Ofast -march=native and both LTO and PGO than with GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90283 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > The perf comes from an Intel Skylake server machine. > > The number of fma is very similar: > grep fma bad.report.txt | wc -l > 126 > grep fma good.report.txt | wc -l > 128 Grepping for vfm also includes the vfmsubs etc., with the same gap: bad.report.txt:167 good.report.txt:169 The distribution also looks similar: $ sed -n 's/.*\(vfm[^ ]*\).*/\1/p' good.report.txt | sort | uniq -c 61 vfmadd132sd 1 vfmadd132ss 35 vfmadd213sd 30 vfmadd231sd 1 vfmadd231ss 32 vfmsub132sd 1 vfmsub213sd 8 vfmsub231sd $ sed -n 's/.*\(vfm[^ ]*\).*/\1/p' bad.report.txt | sort | uniq -c 60 vfmadd132sd 1 vfmadd132ss 35 vfmadd213sd 29 vfmadd231sd 1 vfmadd231ss 29 vfmsub132sd 1 vfmsub213sd 11 vfmsub231sd > But the assembly is shuffled quite significantly after the change. Can you > Richard Sandiford please take a look? I think I'm going to need more clues why the new code is so much slower in practice. Could someone more familiar with the architecture comment?
[Bug debug/90279] DW_AT_location missing for struct-based Variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90279 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-30 CC||marxin at gcc dot gnu.org, ||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I can confirm that.
[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273 --- Comment #26 from Alexandre Oliva --- I saw the #c11 patch in gcc-patches, and it seemed to have been posted FTR and installed. It looked good, so I didn't comment on it. I agree about the effects of #c16, though I begin to get a feeling that it's working too hard for too little benefit. Ditto trying to optimize debug temps: you will get some savings, sure, but how much benefit for such global analyses? Perhaps we'd get a much bigger bang for the buck introducing vector resets, in which a single gimple bind stmt would reset several decls at once. If that's become as common as it is being made out to be, this could save a significant amount of memory. Though from Jan's comments on compile times, it doesn't look like we've got much slower, which makes me wonder what the new problem really is... Could it be that debug binds have always been there, plentiful but under the radar, and that the real recent regression (assuming there really is one) lies elsewhere? (sorry, I haven't really dug into it myself)
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761 --- Comment #3 from Jonathan Wakely --- (In reply to Jan van Dijk from comment #2) > Is it not perfectly fine that your patch works only for _Tp equal to float, > double or long double? Anything else is unspecified per 24.5(2). Does > libstdc++ advertise to go beyond the standard and support other scalar types > as well? (And if so: is that policy documented anywhere?) Look at the source. defines the full std::complex primary template as well as explicit specializations for std::complex, std::complex and std::complex.
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |10.0 Severity|minor |normal
[Bug target/86538] GCC should define a macro to specify if LSE is enabled or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86538 --- Comment #6 from Ramana Radhakrishnan --- Author: ramana Date: Tue Apr 30 14:57:50 2019 New Revision: 270702 URL: https://gcc.gnu.org/viewcvs?rev=270702&root=gcc&view=rev Log: [Patch AArch64] Add __ARM_FEATURE_ATOMICS This keeps coming up repeatedly and the ACLE has finally added __ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of the latest ACLE release (https://developer.arm.com/docs/101028/latest/5-feature-test-macros) I know it's late for GCC-9 but this is a simple macro which need not wait for another year. Ok for trunk and to backport to all release branches ? Tested with a simple build and a smoke test. Backport from mainline. PR target/86538 * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define __ARM_FEATURE_ATOMICS Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/aarch64/aarch64-c.c
[Bug tree-optimization/90292] New: GCC Fails to hoist loop invariant in nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90292
Bug ID: 90292
Summary: GCC Fails to hoist loop invariant in nested loops
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: giuliano.belinassi at usp dot br
Target Milestone: ---
Both GCC 8.3.0 and 9.0.1 fails to hoist the index calculation for 'i' and 'k'
variables of the following function (matrix multiplication with blocking):
void matrix_dgemm_2(unsigned n, double *restrict _C, double *restrict _A,
double *restrict _B)
{
#define BLOCK_I 128
#define BLOCK_K 8
#define A(i, j) _A[n*(i) + (j)]
#define B(i, j) _B[n*(i) + (j)]
#define C(i, j) _C[n*(i) + (j)]
unsigned ii, kk, i, j, k;
for (ii = 0; ii < n; ii += BLOCK_I)
for (kk = 0; kk < n; kk += BLOCK_K)
for (i = ii; i < ii + BLOCK_I; ++i)
for (k = kk; k < kk + BLOCK_K; ++k)
for (j = 0; j < n; ++j)
C(i, j) += A(i, k) * B(k, j);
}
which then generate the following GIMPLE code on the deepest nested block (-O2)
[local count: 955630225]:
# ivtmp.3_88 = PHI <_1(6), ivtmp.3_87(4)>
_3 = (long unsigned int) ivtmp.3_88;
_4 = _3 * 8;
_5 = _C_34(D) + _4;
_6 = *_5;
_13 = ivtmp.14_81 + ivtmp.3_88;
_14 = (long unsigned int) _13;
_15 = _14 * 8;
_16 = _B_36(D) + _15;
_17 = *_16;
_18 = _11 * _17;
_19 = _6 + _18;
*_5 = _19;
ivtmp.3_87 = ivtmp.3_88 + 1;
if (ivtmp.25_71 != ivtmp.3_87)
goto ; [89.00%]
else
goto ; [11.00%]
If I modify the function code to do the following:
void matrix_dgemm_2(unsigned n, double *restrict _C, double *restrict _A,
double *restrict _B)
{
#define BLOCK_I 128
#define BLOCK_K 8
#define A(i, j) _A[n*(i) + (j)]
#define B(i, j) _B[n*(i) + (j)]
#define C(i, j) _C[n*(i) + (j)]
unsigned ii, kk, i, j, k;
for (ii = 0; ii < n; ii += BLOCK_I)
for (kk = 0; kk < n; kk += BLOCK_K)
for (i = ii; i < ii + BLOCK_I; ++i)
for (k = kk; k < kk + BLOCK_K; ++k)
{
double a = A(i, k);
double* b = &B(k, 0);
double* c = &C(i, 0);
for (j = 0; j < n; ++j)
{
*c = a * (*b);
c++; b++;
}
}
}
Then GCC generates the following deepest block: (-O2)
[local count: 955630224]:
# ivtmp.1_47 = PHI <0(5), ivtmp.1_46(6)>
_11 = MEM[base: b_32, index: ivtmp.1_47, step: 8, offset: 0B];
_12 = _11 * a_30;
MEM[base: c_34, index: ivtmp.1_47, step: 8, offset: 0B] = _12;
ivtmp.1_46 = ivtmp.1_47 + 1;
if (_44 != ivtmp.1_47)
goto ; [89.00%]
else
goto ; [11.00%]
and therefore it will generate faster final code. With a 2048x2048 matrix at
-O2, this modification only gives about 0.3s of speedup, however at -O3
-march=native in a Core(TM) i5-8250U, this modification provides a 2x speedup,
arguably due to vectorization.
[Bug tree-optimization/90292] GCC Fails to hoist loop invariant in nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90292 Alexander Monakov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amonakov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Alexander Monakov --- The compiler cannot perform this hoisting, because the computation 'n*(i) + (j)' happens in 'unsigned int' type, where wrapping overflow matters when pointers are 64-bit. If the testcase is changed to either use 'int' (undefined overflow) or 'unsigned long' (same as pointer size), the desired hoisting is performed, as far as I can tell. Therefore, closing as invalid. (it's not rare that using size_t for array indexes helps optimization, this is one of such examples)
[Bug c/90289] an unnecessary relocation record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90289 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- GCC produces: callf So it is up to the assembler to decide if there is a relocation or not to the "global" symbol f. The assembler comes from the binutils project. NOTE this is most likely not a bug really and done on purpose.
[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273 --- Comment #27 from rguenther at suse dot de --- On April 30, 2019 4:27:25 PM GMT+02:00, "aoliva at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273 > >--- Comment #26 from Alexandre Oliva --- >I saw the #c11 patch in gcc-patches, and it seemed to have been posted >FTR and >installed. It looked good, so I didn't comment on it. > >I agree about the effects of #c16, though I begin to get a feeling that >it's >working too hard for too little benefit. Ditto trying to optimize >debug temps: >you will get some savings, sure, but how much benefit for such global >analyses? > >Perhaps we'd get a much bigger bang for the buck introducing vector >resets, in >which a single gimple bind stmt would reset several decls at once. If >that's >become as common as it is being made out to be, this could save a >significant >amount of memory. > >Though from Jan's comments on compile times, it doesn't look like we've >got >much slower, which makes me wonder what the new problem really is... >Could it >be that debug binds have always been there, plentiful but under the >radar, and >that the real recent regression (assuming there really is one) lies >elsewhere? >(sorry, I haven't really dug into it myself) The recent regression is we no longer throw them away plentiful during CFG cleanup and now they pile up during inlining. I agree full DCE with liveness will be expensive for usually little gain. Not sure if vector resets will improve things much.
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761 --- Comment #4 from Jonathan Wakely --- I think your patch as as good as anything else we'll come up with, apart from using numeric_limits::infinity() instead of INFINITY. Anybody who wants to use std::proj with types other than float, double and long double will have to ensure that std::isinf and std::copysign work. I'll add some tests and commit it shortly, thanks.
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #3 from Nathan Sidwell --- I think I'm going to have to consult core ...
[Bug target/87163] ICE in extract_insn, at recog.c:2305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87163
--- Comment #2 from Peter Bergner ---
This doesn't fail for me using a native build. Martin, can you recheck to see
if this is now fixed? There have been some changes in this area and I do see
that pattern in my dump file with no ICE:
(insn 6 3 7 2 (set (reg:DF 124)
(float_truncate:DF (reg/v:IF 122 [ aD.2830 ]))) "t.i":5:10 529
{truncifdf2_internal1}
(nil))
[Bug c/90293] New: New function attribute: expect_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90293 Bug ID: 90293 Summary: New function attribute: expect_return Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- I have an idea of new function attribute: expect_return. It would allow to specify value usually returned from function, so it could help with optimization in similar way like __builtin_expect() does. Example use: __attribute__((expect_return(false))) bool DebugModeEnabled(); __attribute__((expect_return(false))) bool IsErrorCode(int code);
[Bug c/90293] New function attribute: expect_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90293 --- Comment #1 from Daniel Fruzynski --- One more case: sometimes it may be more handy to specify what will *not* be usually returned, e.g. special invalid value. For such cases another attribute would be needed: __attribute__((expect_not_return(-1))) int CreateSocket();
[Bug debug/90273] [9/10 Regression] GCC runs out of memory building Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90273 --- Comment #28 from Jan Hubicka --- > The recent regression is we no longer throw them away plentiful during CFG > cleanup and now they pile up during inlining. > > I agree full DCE with liveness will be expensive for usually little gain. Not > sure if vector resets will improve things much. One thing to keep in mind that after early opts and in late opts after the initial cleanups post ipa-inline-transforms we likely have a lot of new debug statements brought in by inliner. It would make sense to do something more expensive twice in queue to get rid of them. Especially in early opts we do not want to make too many useless debug statements to hit the LTO stream or get duplicated by subsequent inlining. Honza
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761 --- Comment #5 from Jan van Dijk --- Does the usage of numeric_limits<_Tp> in complex work well for user-defined _Tp? For complex, at present MyType can be required to be constructible from INFINITY to make proj work. Wouldn't using numeric_limits<_Tp> dictate a (forbidden) numeric_limits specialization to provide numeric_limits::infinity()?
[Bug libstdc++/61761] [C++11] std::proj returns incorrect values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61761 --- Comment #6 from Jonathan Wakely --- (In reply to Jan van Dijk from comment #5) > Does the usage of numeric_limits<_Tp> in complex work well for user-defined > _Tp? We can assume it does. > For complex, at present MyType can be required to be constructible > from INFINITY to make proj work. Wouldn't using numeric_limits<_Tp> dictate > a (forbidden) numeric_limits specialization to provide > numeric_limits::infinity()? There's nothing forbidden about specializing numeric_limits.
[Bug c/90293] New function attribute: expect_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90293 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Severity|normal |enhancement --- Comment #2 from Martin Sebor --- I think this could be useful. A related feature I'd like to see is a "binding" attribute that made it possible to express a) ranges of return values and b) relationships involving arguments. E.g., "expect a negative return value if function argument 1 is greater than 255." By binding I mean one that guaranteed the result as opposed to simply expressing a likelihood.
[Bug rtl-optimization/82636] powerpc: Unnecessary copy of __ieee128 parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org Component|middle-end |rtl-optimization --- Comment #6 from Peter Bergner --- I think this may be fixed already. I see for the two test cases: Tulio's: __fmaf128_power9: .LFB0: xsmaddqp4, 2, 3 xxlor 34,36,36 blr ...and Mikes: __fmaf128_power9: .LFB0: .cfi_startproc xsmaddqp 4,2,3 xxlor 34,36,36 blr Tulio and Mike, can you confirm that?
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #85 from Tamar Christina --- Hi Jakub, commit r270690 seems to have caused a regression on gcc.target/aarch64/return_address_sign_3.c
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #86 from Tamar Christina --- for aarch64-none-linux-gnu. I am still building the toolchain to take a look so not able to give more detail.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #87 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 16:30:44 2019 New Revision: 270705 URL: https://gcc.gnu.org/viewcvs?rev=270705&root=gcc&view=rev Log: PR target/89093 * gcc.target/aarch64/return_address_sign_3.c: Remove extra space in target attribute. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/return_address_sign_3.c
[Bug tree-optimization/90292] GCC Fails to hoist loop invariant in nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90292 --- Comment #2 from Giuliano Belinassi --- Just for the sake of completeness, this issue is not addressed by just changing the iterators to 'int'. However, it is in fact solved by changing the iterators to 'unsigned long', 'long', or doing a cast in each macro. GCC even generates faster code if one of these two last changes are made. Also, the statement in matrix_dgemm_2 should be *c += a * (*b); for correctness.
[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 --- Comment #2 from Thomas Henlich --- The road to standards non-compliance hell is paved with very minor offenses... ;-)
[Bug tree-optimization/90292] GCC Fails to hoist loop invariant in nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90292 --- Comment #3 from Alexander Monakov --- When changing iterators to 'int', you also need to change n to int as well, otherwise in 'n*(i) + (j)', i and j are promoted to unsigned anyway.
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 Nathan Sidwell changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from Nathan Sidwell --- I believe GCC is correctly implementing DR2061's proposal, and this change is an expected result of that. I have asked CWG for comment.
[Bug fortran/90294] New: Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 Bug ID: 90294 Summary: Compare with NaN failing Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: siteg at mathalacarte dot com Target Milestone: --- Comparing a double real rdat(i) containing a NaN results in Program received signal SIGFPE, Arithmetic exception. 0x555c2559 in messy_d_m::vec_setup () at Src/messy_bod.F90:1818 1818else if (rdat(i) < 0.0_rk) then
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Fred Krogh from comment #0) > Comparing a double real rdat(i) containing a NaN results in > > Program received signal SIGFPE, Arithmetic exception. > 0x555c2559 in messy_d_m::vec_setup () at Src/messy_bod.F90:1818 > 1818 else if (rdat(i) < 0.0_rk) then What were the options used when compiling the code? What is the code? Can't debug in a vacuum.
[Bug libstdc++/90295] New: Please define ~exception_ptr inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90295
Bug ID: 90295
Summary: Please define ~exception_ptr inline
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael at espindo dot la
Target Milestone: ---
Currently ~exception_ptr is defined out of line. Its definition just calls
_M_release which looks like
if (_M_exception_object)
{
...
}
Which means that there is nothing to do for an exception_ptr that has been
moved, but the user code has no way of knowing that.
If the ~exception_ptr was defined inline as
~exception_ptr() {
if (_M_exception_object)
{
out_of_line_destructor();
}
}
Then the compiler would be able to omit the call to out_of_line_destructor when
it knows _M_exception_object is null.
This comes up in seastar (https://github.com/scylladb/seastar/) where we have a
struct (future_state) that holds a exception_ptr and is frequently moved.
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 --- Comment #2 from Fred Krogh --- Created attachment 46268 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46268&action=edit gfortran -g -o testi testi.f90 gives the error below Look at r > 0 NaN Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG
[Bug web/89770] move java-related mailing lists on lists.html to the "Historical lists" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89770 --- Comment #2 from Eric Gallager --- (In reply to Martin Liška from comment #1) > Fixed. So it is. Thanks!
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 --- Comment #3 from Steve Kargl --- On Tue, Apr 30, 2019 at 05:28:18PM +, siteg at mathalacarte dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 > > --- Comment #2 from Fred Krogh --- > Created attachment 46268 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46268&action=edit > gfortran -g -o testi testi.f90 gives the error below > > Look at r > 0 NaN > Note: The following floating-point exceptions are > signalling: IEEE_INVALID_FLAG I don't understand. The program executed as expected, and upon completion it reported the floating point exception is signalling. See the -ffpe-summary option to suppress the warning. See the F2008 and/or F2018 Fortran Standards for the use of STOP.
[Bug fortran/90290] -std=f2008 should reject non-constant stop and error stop codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90290 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P5 |P4 CC||kargl at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |9.2 Severity|minor |normal --- Comment #3 from kargl at gcc dot gnu.org --- My version gives % gfcx -o z -std=f2008 a.f90 a.f90:4:6: 4 | stop ec | 1 Error: STOP code at (1) must be a scalar default CHARACTER or INTEGER constant expression
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-30 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Note that -std=f95 does not silence the STOP.
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 --- Comment #5 from Steve Kargl --- On Tue, Apr 30, 2019 at 05:54:33PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 > > Dominique d'Humieres changed: > >What|Removed |Added > > Status|UNCONFIRMED |WAITING >Last reconfirmed||2019-04-30 > Ever confirmed|0 |1 > > --- Comment #4 from Dominique d'Humieres --- > Note that -std=f95 does not silence the STOP. > So? The Fortran 95 does not disallow reporting this warning. As it is informational, I do not see any reason for to suppress the warning. The user can always you -Wfpe-summary.
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 --- Comment #6 from Steve Kargl --- On Tue, Apr 30, 2019 at 11:15:38AM -0700, Steve Kargl wrote: > On Tue, Apr 30, 2019 at 05:54:33PM +, dominiq at lps dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 > > > > Dominique d'Humieres changed: > > > >What|Removed |Added > > > > Status|UNCONFIRMED |WAITING > >Last reconfirmed||2019-04-30 > > Ever confirmed|0 |1 > > > > --- Comment #4 from Dominique d'Humieres --- > > Note that -std=f95 does not silence the STOP. > > > > So? The Fortran 95 does not disallow reporting this warning. > As it is informational, I do not see any reason for to suppress > the warning. The user can always you -Wfpe-summary. > BTW, one is suppose to be able to control this behavior in the code itself. stop, .false. stop, quiet=.false. should inhibit the warning. gfortran does not support the QUIET directive.
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 --- Comment #7 from Steve Kargl --- On Tue, Apr 30, 2019 at 11:17:38AM -0700, Steve Kargl wrote: > > BTW, one is suppose to be able to control this behavior in the > code itself. > > stop, .false. > stop, quiet=.false. > > should inhibit the warning. gfortran does not support the > QUIET directive. > This might be 'quiet=.true.' to suppress warnings. I haven't studied the standard closely, yet.
[Bug web/90127] Disable bugzilla [[wiki_links]] and don't confuse r12 register names with r12345 svn revisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127 Frédéric Buclin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Frédéric Buclin --- done
[Bug fortran/90294] Compare with NaN failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90294 --- Comment #8 from Fred Krogh --- My apologies for posting this. In my original code the program just quit at the point of the test. I thought I had more or less reproduced this in a small program. Clearly that is not the case. My code has changed to get around the bug, such change was needed regardless. I have not idea how to get this reproduced in a small program.
[Bug c++/90291] [8/9/10 Regression] Inline namespace erroneously extends another namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90291 --- Comment #5 from Nathan Sidwell --- Igor, was this distilled from real code? what was the intent of such an organization?
[Bug tree-optimization/88074] [7/8 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 --- Comment #34 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:28:56 2019 New Revision: 270712 URL: https://gcc.gnu.org/viewcvs?rev=270712&root=gcc&view=rev Log: Backported from mainline 2019-02-20 Jakub Jelinek PR middle-end/88074 PR middle-end/89415 * toplev.c (do_compile): Double the emin/emax exponents to workaround buggy mpc_norm. * gcc.dg/pr88074-2.c: New test. 2019-02-19 Richard Biener PR middle-end/88074 * toplev.c (do_compile): Initialize mpfr's exponent range based on available float modes. * gcc.dg/pr88074.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88074-2.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88074.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/toplev.c
[Bug middle-end/89415] [9 Regression] gcc.dg/sinatan-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89415 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:28:56 2019 New Revision: 270712 URL: https://gcc.gnu.org/viewcvs?rev=270712&root=gcc&view=rev Log: Backported from mainline 2019-02-20 Jakub Jelinek PR middle-end/88074 PR middle-end/89415 * toplev.c (do_compile): Double the emin/emax exponents to workaround buggy mpc_norm. * gcc.dg/pr88074-2.c: New test. 2019-02-19 Richard Biener PR middle-end/88074 * toplev.c (do_compile): Initialize mpfr's exponent range based on available float modes. * gcc.dg/pr88074.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88074-2.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr88074.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/toplev.c
[Bug middle-end/89412] [7/8 Regression] gcc ICE in simplify_subreg, at simplify-rtx.c:6273 on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89412 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:30:27 2019 New Revision: 270714 URL: https://gcc.gnu.org/viewcvs?rev=270714&root=gcc&view=rev Log: Backported from mainline 2019-02-20 Jakub Jelinek PR middle-end/89412 * expr.c (expand_assignment): If result is a MEM, use change_address instead of simplify_gen_subreg. * gcc.c-torture/compile/pr89412.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89412.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/89091] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89091 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:29:44 2019 New Revision: 270713 URL: https://gcc.gnu.org/viewcvs?rev=270713&root=gcc&view=rev Log: Backported from mainline 2019-02-20 Jakub Jelinek David Malcolm PR middle-end/89091 * fold-const.c (decode_field_reference): Return NULL_TREE if lang_hooks.types.type_for_size returns NULL. Check it before overwriting *exp_. Use return NULL_TREE instead of return 0. * gcc.dg/torture/pr89091.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89091.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/fold-const.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/89405] [8 Regression] ICE in import_export_decl, at cp/decl2.c:2959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89405 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:31:26 2019 New Revision: 270715 URL: https://gcc.gnu.org/viewcvs?rev=270715&root=gcc&view=rev Log: Backported from mainline 2019-02-20 Jakub Jelinek PR c++/89405 * decl.c (maybe_commonize_var): When clearing TREE_PUBLIC and DECL_COMMON, set DECL_INTERFACE_KNOWN. * g++.dg/cpp1z/inline-var5.C: New test. Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/decl.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/inline-var5.C
[Bug c++/89403] [7/8 Regression] ICE in maybe_clone_body, at cp/optimize.c:693
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89403 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:32:14 2019 New Revision: 270716 URL: https://gcc.gnu.org/viewcvs?rev=270716&root=gcc&view=rev Log: Backported from mainline 2019-02-20 Jakub Jelinek PR c++/89403 * decl2.c (c_parse_final_cleanups): Move TREE_ASM_WRITTEN setting for flag_syntax_only from here... * semantics.c (expand_or_defer_fn_1): ... here. * g++.dg/cpp0x/pr89403.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/pr89403.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/decl2.c branches/gcc-8-branch/gcc/cp/semantics.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/89520] [7/8 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in convert_to_integer_1, at convert.c:668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89520 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:33:24 2019 New Revision: 270717 URL: https://gcc.gnu.org/viewcvs?rev=270717&root=gcc&view=rev Log: Backported from mainline 2019-02-28 Jakub Jelinek PR c/89520 * convert.c (convert_to_real_1, convert_to_integer_1): Punt for builtins if they don't have a single scalar floating point argument. Formatting fixes. * gcc.dg/pr89520-1.c: New test. * gcc.dg/pr89520-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89520-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89520-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/convert.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/89521] ICE in expand_builtin_int_roundingfn, at builtins.c:2697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89521 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:34:49 2019 New Revision: 270718 URL: https://gcc.gnu.org/viewcvs?rev=270718&root=gcc&view=rev Log: Backported from mainline 2019-02-28 Jakub Jelinek PR c/89521 * gcc.dg/pr89521-1.c: New test. * gcc.dg/pr89521-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89521-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89521-2.c Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/89590] [7/8 Regression] ICE in maybe_emit_free_warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89590 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:36:17 2019 New Revision: 270719 URL: https://gcc.gnu.org/viewcvs?rev=270719&root=gcc&view=rev Log: Backported from mainline 2019-03-05 Jakub Jelinek PR middle-end/89590 * builtins.c (maybe_emit_free_warning): Punt if free doesn't have exactly one argument. * gcc.dg/pr89590.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr89590.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/builtins.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug target/89587] gcc's rs6000 configuration unconditionally sets MULTIARCH_DIRNAME, even when multiarch is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89587 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:37:12 2019 New Revision: 270720 URL: https://gcc.gnu.org/viewcvs?rev=270720&root=gcc&view=rev Log: Backported from mainline 2019-03-05 Jakub Jelinek PR target/89587 * config/rs6000/t-linux (MULTIARCH_DIRNAME): Set to non-empty only if_multiarch. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/rs6000/t-linux
[Bug c++/87148] [7/8 Regression] backward compatibility issue to take char [] as incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:38:01 2019 New Revision: 270721 URL: https://gcc.gnu.org/viewcvs?rev=270721&root=gcc&view=rev Log: Backported from mainline 2019-03-06 Jakub Jelinek PR c++/87148 * init.c (build_value_init_noctor): Ignore flexible array members. * g++.dg/ext/flexary34.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/flexary34.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/init.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/82075] structured binding fails with empty base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82075 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Apr 30 20:38:32 2019 New Revision: 270722 URL: https://gcc.gnu.org/viewcvs?rev=270722&root=gcc&view=rev Log: Backported from mainline 2019-03-08 Jakub Jelinek PR c++/82075 * g++.dg/cpp1z/decomp49.C: New test. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1z/decomp49.C Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog
