Define HAVE_ for math long double functions declared in vxworks headers

2019-12-24 Thread Alexandre Oliva
When cross-building for vxworks, test for declarations of long double functions in math.h. We don't normally test for these functions when cross compiling, because link tests don't work, or ever really, but not defining them as available causes replacements to be defined in ways that may cause

[Bug c++/93070] std::__lg (and all functions that use it) generates suboptimal code

2019-12-24 Thread gcc at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93070 John Simon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/93071] std::__lg (and all functions that use it) generates suboptimal code

2019-12-24 Thread gcc at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071 --- Comment #1 from John Simon --- *** Bug 93070 has been marked as a duplicate of this bug. ***

[Bug c++/93071] New: std::__lg (and all functions that use it) generates suboptimal code

2019-12-24 Thread gcc at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071 Bug ID: 93071 Summary: std::__lg (and all functions that use it) generates suboptimal code Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal

[Bug c++/93070] New: std::__lg (and all functions that use it) generates suboptimal code

2019-12-24 Thread gcc at mailinator dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93070 Bug ID: 93070 Summary: std::__lg (and all functions that use it) generates suboptimal code Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal

[Bug target/93069] New: Assembler messages: Error: unsupported masking for `vextracti32x8'

2019-12-24 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069 Bug ID: 93069 Summary: Assembler messages: Error: unsupported masking for `vextracti32x8' Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords:

[Bug target/93062] Failed to generate indirect branch for long branches on riscv

2019-12-24 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug testsuite/93045] gc bug with test "start_unit-test-1.c"

2019-12-24 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93045 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1

[Bug target/93062] Failed to generate indirect branch for long branches on riscv

2019-12-24 Thread wilson at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1

[Bug tree-optimization/83784] Missed optimization with bitfield

2019-12-24 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Andrew

[Bug tree-optimization/83784] Missed optimization with bitfield

2019-12-24 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement

[Bug tree-optimization/93063] Loop distribution and NOP conversions

2019-12-24 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063 --- Comment #1 from Marc Glisse --- Created attachment 47549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47549=edit Untested patch Not ready, at the very least it misses a comment and a test, but it shows where the test needs relaxing.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-24 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #10 from fdlbxtqi --- (In reply to fdlbxtqi from comment #9) > (In reply to Marc Glisse from comment #8) > > (In reply to fdlbxtqi from comment #6) > > > void copy_char_vector_with_iter(std::vector::iterator > > > out,std::vector

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-24 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #9 from fdlbxtqi --- (In reply to Marc Glisse from comment #8) > (In reply to fdlbxtqi from comment #6) > > void copy_char_vector_with_iter(std::vector::iterator > > out,std::vector const& bits) > > { > >

[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression

2019-12-24 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396 --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #4) > Either we can do something in the bswap pass with it as done in this > untested patch, or we could consider match.pd optimization for: > _3 = BIT_FIELD_REF

[Bug ada/93068] New: Professional Dissertation Writing Services

2019-12-24 Thread alicethomas056 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93068 Bug ID: 93068 Summary: Professional Dissertation Writing Services Product: gcc Version: new-ra Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada

The new Subversion reader in reposurgeon is complete for GCC purposes

2019-12-24 Thread Eric S. Raymond
This morning Julian Rivaud and I fully qualified the new Subversion dump stream reader against reposurgeon's test suite. This is the same code Joseph Myers has been using recent versions of to make test conversions of the GCC history that appear correct. We believe reposurgeon is now

[Bug other/93067] diagnostics are not aware of -finput-charset

2019-12-24 Thread lhyatt at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 --- Comment #1 from Lewis Hyatt --- Created attachment 47548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47548=edit testcases

[Bug other/93067] New: diagnostics are not aware of -finput-charset

2019-12-24 Thread lhyatt at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 Bug ID: 93067 Summary: diagnostics are not aware of -finput-charset Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/55791] gcc fails to detect wrong type in sizeof in malloc

2019-12-24 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55791 --- Comment #4 from Eric Gallager --- For reference, clang catches this with its static analyzer: $ clang --analyze 55791.c 55791.c:10:15: warning: Result of 'malloc' is converted to a pointer of type 'char', which is incompatible with sizeof

Re: Test GCC conversion with reposurgeon available

2019-12-24 Thread Segher Boessenkool
On Tue, Dec 24, 2019 at 05:16:54PM +, Joseph Myers wrote: > On Tue, 24 Dec 2019, Segher Boessenkool wrote: > > > That's because that commit also edits ChangeLog entries from other > > > authors. When a commit adds / edits ChangeLog entries for more than one > > > author (the difference

[Bug tree-optimization/93052] Wrong optimizations for pointers: `p == q ? p : q` -> `q`

2019-12-24 Thread ch3root at openwall dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052 --- Comment #5 from Alexander Cherepanov --- 1. It should be noted that the idea of problems arising from `p == q ? p : q` is from Chung-Kil Hur via bug 65752, comment 15. 2. clang bug -- https://bugs.llvm.org/show_bug.cgi?id=44374.

[Bug tree-optimization/93051] Wrong optimizations for pointers: `if (p == q) use p` -> `if (p == q) use q`

2019-12-24 Thread ch3root at openwall dot com
mp; ./a.out result: 1 -- gcc x86-64 version: gcc (GCC) 10.0.0 20191224 (experimental) --

Re: Test GCC conversion with reposurgeon available

2019-12-24 Thread Joseph Myers
On Tue, 24 Dec 2019, Segher Boessenkool wrote: > > That's because that commit also edits ChangeLog entries from other > > authors. When a commit adds / edits ChangeLog entries for more than one > > author (the difference between purely editing an existing entry and adding > > a new one,

[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism

2019-12-24 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #4 from Alexander Monakov --- The attachment is edited to test insertion_sort, and doesn't call accumulate_vector at all - looks like you attached a wrong file?

[Bug tree-optimization/93056] Poor codegen for heapsort in stephanov_vector benchmark

2019-12-24 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org ---

[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism

2019-12-24 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #3 from Jan Hubicka --- Created attachment 47546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47546=edit preprocessed benchmark I am attaching preprocessed source. I used -O3 -march=native -fno-prefetch-loops-arrays (since

Re: [PATCH] V11 patch #5 of 15, Optimize vec_extract of a vector in memory with a PC-relative address

2019-12-24 Thread Segher Boessenkool
Hi! On Fri, Dec 20, 2019 at 06:55:53PM -0500, Michael Meissner wrote: > * config/rs6000/rs6000.c (rs6000_reg_to_addr_mask): New helper > function to identify the address mask of a hard register. Do this as a separate patch please. That refactoring is pre-approved. Please explain in

[PATCH][AARCH64] Set jump-align=4 for neoversen1

2019-12-24 Thread Wilco Dijkstra
Testing shows the setting of 32:16 for jump alignment has a significant codesize cost, however it doesn't make a difference in performance. So set jump-align to 4 to get 1.6% codesize improvement. OK for commit? ChangeLog 2019-12-24 Wilco Dijkstra * config/aarch64/aarch64.c

[PATCH][AARCH64] Enable compare branch fusion

2019-12-24 Thread Wilco Dijkstra
Enable the most basic form of compare-branch fusion since various CPUs support it. This has no measurable effect on cores which don't support branch fusion, but increases fusion opportunities on cores which do. Bootstrapped on AArch64, OK for commit? ChangeLog: 2019-12-24 Wilco Dijkstra

Re: Test GCC conversion with reposurgeon available

2019-12-24 Thread Segher Boessenkool
On Tue, Dec 24, 2019 at 11:50:30AM +, Joseph Myers wrote: > On Mon, 23 Dec 2019, Roman Zhuykov wrote: > > I've never used zhr...@gcc.gnu.org email in ChangeLog files. So, it seems > > odd > > that it is used in r270511 (my first commit as maintainer), but not in next > > That's because that

[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism

2019-12-24 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #2 from Alexander Monakov --- Can you attach preprocessed source and double-check command-line flags? I can't reproduce the problem with lea, and the code does not have explicit prefetch instructions that I get with -O3 -march=bdver1

[Bug libgomp/93066] New: libgomp/target.c:525:46: error: expected expression before ')' token

2019-12-24 Thread danglin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066 Bug ID: 93066 Summary: libgomp/target.c:525:46: error: expected expression before ')' token Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal

[Patch] OpenACC – support "if" + "if_present" clauses with "host_data"

2019-12-24 Thread Tobias Burnus
On the front-end side, adding "if" and "if_present" to the  "acc host_data" directive is simple as other directives already support those clauses. The 'if_present' status has to be passed along the use_device_ptr flag; for this a new flag has been introduced, using the gap in the

[Bug middle-end/93041] GCC 10 removes an infinite loop and causes a null pointer to dereferenced

2019-12-24 Thread msl0000023508 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 --- Comment #4 from WHR --- OK, I'm now fully understood what's happens. If the loop breaks, 'p' must be 0, so the later '**p' will dereference a null pointer. Looks like this is actually a feature...

♡ Hey! Mine helpmate gave your email...

2019-12-24 Thread Floriane
What is up,my honeyboy. I kno you in F-book last few days and I want to see you. My Name Mary I do some page with my cool pics. I`ll Wait your arms. My nick : Gibbs112. Com`om Find me there!

[Bug libgomp/93065] New: libgomp: destructor missing to delete goacc_cleanup_key

2019-12-24 Thread v.narang at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93065 Bug ID: 93065 Summary: libgomp: destructor missing to delete goacc_cleanup_key Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism

2019-12-24 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org ---

[Bug target/93061] Optimising for size -Os causes segfault with AES-NI reference

2019-12-24 Thread mutex at fastmail dot co.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061 Mutex changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

Re: Test GCC conversion with reposurgeon available

2019-12-24 Thread Joseph Myers
On Mon, 23 Dec 2019, Roman Zhuykov wrote: > I've never used zhr...@gcc.gnu.org email in ChangeLog files. So, it seems odd > that it is used in r270511 (my first commit as maintainer), but not in next That's because that commit also edits ChangeLog entries from other authors. When a commit adds

[Bug libgcc/93053] libgcc build failure with old binutils on aarch64

2019-12-24 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #5 from Andrew Pinski --- (In reply to Roman Zhuykov from comment #4) > PS. Cfarm gcc117 and 118 are not available at the moment, and 113-116 have > same hardware and old binutils 2.24. Just compile your own new binutils first.

[Bug libgcc/93053] libgcc build failure with old binutils on aarch64

2019-12-24 Thread zhroma at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #4 from Roman Zhuykov --- Maybe this should be catched earlier in configure scripts? Are there any simple workaround without patching the gcc source? I'm not familiar with different armvN -march option values. Probably it can help

[Bug middle-end/68360] GCC bitfield processing code is very inefficient

2019-12-24 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 --- Comment #5 from Andrew Pinski --- (In reply to Eric Botcazou from comment #4) > > it returns QImode. If it returned SImode as on SPARC, the code would be: SLOW_BYTE_ACCESS set to 0 is the cause there ...

[Bug c++/93064] ICE on C++20 operator<=> use

2019-12-24 Thread jengelh at inai dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064 --- Comment #1 from Jan Engelhardt --- Possibly a duplicate of #92496 (the automatic "Possible duplicates" in the New Bug form was slow to load), but my preconditions are different: I don't have a public data member, nor is a template used like

[Bug c++/93064] New: ICE on C++20 operator<=> use

2019-12-24 Thread jengelh at inai dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064 Bug ID: 93064 Summary: ICE on C++20 operator<=> use Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

Re: Test GCC conversion with reposurgeon available

2019-12-24 Thread Maxim Kuvyrkov
> On Dec 22, 2019, at 4:56 PM, Joseph Myers wrote: > > On Thu, 19 Dec 2019, Joseph Myers wrote: > >> And two more. >> >> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4a.git >> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-4b.git > > Two more. > >

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-24 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #8 from Marc Glisse --- (In reply to fdlbxtqi from comment #6) > void copy_char_vector_with_iter(std::vector::iterator > out,std::vector const& bits) > { > std::copy_n(bits.begin(),bits.size(),out); > } > >

[Bug tree-optimization/93063] New: Loop distribution and NOP conversions

2019-12-24 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063 Bug ID: 93063 Summary: Loop distribution and NOP conversions Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-24 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #7 from Marc Glisse --- (In reply to fdlbxtqi from comment #6) > > > clearly incorrect > > > > Please distinguish between what is wrong (generated code crashes, or returns > > 3 instead of 2), and what is suboptimal. > > Suppose

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-24 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #6 from fdlbxtqi --- > What operation are you doing on vector? None of your testcases seem to use > it. void copy_char_vector_with_iter(std::vector::iterator out,std::vector const& bits) {

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-24 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #5 from Marc Glisse --- We could indeed relax a bit the "same type" condition. We could also make sure that __restrict appears somewhere in the call chain when using copy or uninitialized_*, which lets the compiler merge the 2