https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #12 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)
> > {
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
JeanHeyd Meneide changed:
What|Removed |Added
CC||phdofthehouse at gmail dot com
---
On Sat, 2019-12-28 at 03:53 -0500, Eric S. Raymond wrote:
> In moving the history of a project old enough to have used
> more than one version-control system, I think it's good practice
> to mark the strata. I'm even interested in pinning down the
> RCS-to-CVS cutover, if there's enough evidence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093
Bug ID: 93093
Summary: __builtin_source_location reports values for default
arguments not aligned with the Standard
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #11 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)
> > {
> >
Oh my god, this is a low-level mistake, not funny 8-0..
caipenghui
在 2019/12/29 10:50, Andrew Pinski 写道:
On Sat, Dec 28, 2019 at 6:31 PM caipenghui wrote:
hello everyone,
I found that gcc version 9.2.1 20191008,
i to compiles a binary search algorithm program that I write that only
On Sat, Dec 28, 2019 at 6:31 PM caipenghui wrote:
>
> hello everyone,
>
> I found that gcc version 9.2.1 20191008,
>
> i to compiles a binary search algorithm program that I write that only
> checks the function prototype,
>
> but does not check the name after the definition?
>
bsearch is a
hello everyone,
I found that gcc version 9.2.1 20191008,
i to compiles a binary search algorithm program that I write that only
checks the function prototype,
but does not check the name after the definition?
/ * binary bearch * /
#include
int bsearch(int x, int a[], int n);
int main(void)
Le 28/12/2019 à 21:28, Segher Boessenkool a écrit :
On Sat, Dec 28, 2019 at 05:11:47PM +, Richard Earnshaw (lists) wrote >> I
disagree. The review comments will show up as additional commits on
the branch and can be tracked back to such events. Once history gets
flattened into a major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092
Bug ID: 93092
Summary: g++ takes tremendous compilation times
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On 27/12/2019 19:47, Richard Earnshaw (lists) wrote:
> Email addresses from the ChangeLog files are not validated during
> commits, so a number of typos exist in the extracted data. I've
> extracted the 'Author:' entry from a prototype conversion and then piped
> that through sort and uniq -c.
On 28/12/2019 20:11, Segher Boessenkool wrote:
> On Sat, Dec 28, 2019 at 04:34:20PM +, Richard Earnshaw (lists) wrote:
>> On 28/12/2019 14:54, Segher Boessenkool wrote:
>>> On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
On Sat, 28 Dec 2019, Segher Boessenkool wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
--- Comment #2 from John Paul Adrian Glaubitz ---
(In reply to Jakub Jelinek from comment #1)
> The Go FE actually isn't that independent, the same gofrontend is used by
> both GCC and LLVM, the same FE written in C++ in that case has then a
>
Snapshot gcc-9-20191228 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20191228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93091
Bug ID: 93091
Summary: Apparent bugs in "sizeof" and "transfer" intrinsic
functions
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Hi!
On 12/27/19 12:26 AM, John Paul Adrian Glaubitz wrote:
> For this reason, people have been asking for a Rust frontend for GCC similar
> to
> the one for Go. Now, there are actually two independent implementation of a
> Rust
> frontend for GCC [1, 2] being developed and I was wondering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090
Bug ID: 93090
Summary: RFE: Add a frontend for the Rust programming language
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On 12/23/19 12:30 PM, Erick Ochoa wrote:
Hi,
I am working on an LTO pass which drops unused fields on structs. On my
tests, I found that the gimple generated for `sizeof` is a constant. For
example, for the following C code:
```
you also need to pay attention to offsetof.
nathan
--
Nathan
On 12/26/19 6:26 PM, John Paul Adrian Glaubitz wrote:
Hello!
The programming language Rust has become very popular over the past few years
with many projects rewriting parts of their codebase in that language. While
these rewrites often make the code perform faster and potentially safer, using
On Sat, Dec 28, 2019 at 05:11:47PM +, Richard Earnshaw (lists) wrote:
> On 28/12/2019 12:19, Segher Boessenkool wrote:
> > Branch merges do not mesh well with our commit policies, fwiw:
> > everything should normally be posted for public review on the mailing
> > lists. This does not really
On Sat, Dec 28, 2019 at 04:34:20PM +, Richard Earnshaw (lists) wrote:
> On 28/12/2019 14:54, Segher Boessenkool wrote:
> > On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
> >> On Sat, 28 Dec 2019, Segher Boessenkool wrote:
> >>
> >>> On Fri, Dec 27, 2019 at 07:47:02PM +,
‐‐‐ Original Message ‐‐‐
On Monday, December 9, 2019 3:39 AM, Richard Biener
wrote:
> > I'm modifying the code trying to get complex double accepted as a valid
> > type by the vectorizer.
> > This is the first time I'm dealing with GCC source so I ask for some
> > patience.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #8
Joseph Myers :
> Concretely, what I'd suggest is: convert ISO-8859-1 entries in the
> checked-in list to UTF-8, removing anything that thereby becomes a
> duplicate or unnecessary; handle anything whose encoding isn't simply
> ISO-8859-1 or UTF-8 via a hardcoded entry in bugdb.py using hex
On Sat, 28 Dec 2019, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > I've added the list of emails that I posted yesterday to the conversion
> > scripts. I've not written anything to reprocess that yet. I want to
> > leave that until we've completed the general
On Dez 28 2019, Richard Earnshaw (lists) wrote:
> I don't know whether tools that analyse git repos to generate statistics
> about users contributions care about canonicalization of names; they may
> just key off email addresses.
git shortlog supports that via .mailmap.
Andreas.
--
Andreas
Hi Tobias,
Build on x86-64-gnu-linux without offloading and with nvptx offloading.
OK for the trunk?
I can't really say a lot about OpenACC, but the changes do look
reasonable.
So, OK for trunk.
Regards
Thomas
On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
> I've added the list of emails that I posted yesterday to the conversion
> scripts. I've not written anything to reprocess that yet. I want to
> leave that until we've completed the general review of the preferred
> changes we want.
On 28/12/2019 17:14, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
>
>> My suggestion would be that we try to canonicalize all the author
>> entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that
>> would probably need further fixups to detect the
On Sat, 28 Dec 2019, Richard Earnshaw (lists) wrote:
> My suggestion would be that we try to canonicalize all the author
> entries to UTF-8 as that avoids the limitations of ISO-8859-1, but that
> would probably need further fixups to detect the additional names that
> need rewriting.
What I've
On 28/12/2019 12:19, Segher Boessenkool wrote:
> Branch merges do not mesh well with our commit policies, fwiw:
> everything should normally be posted for public review on the mailing
> lists. This does not really work for commits that have been set in
> stone months before.
>
I disagree. The
On 28/12/2019 12:04, Jakub Jelinek wrote:
> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
>> Email addresses from the ChangeLog files are not validated during
>> commits, so a number of typos exist in the extracted data. I've
>> extracted the 'Author:' entry from a
On December 28, 2019 5:31:20 PM GMT+01:00, Richard Sandiford
wrote:
>In this testcase we use an unmasked SVE loop with an Advanced SIMD
>epilogue (because we don't yet support fully-masked downward loops).
>The main loop uses a gather load for the strided access while the
>epilogue loop builds
On December 28, 2019 5:29:20 PM GMT+01:00, Richard Sandiford
wrote:
>The EXTRACT_LAST_REDUCTION handling needs to generate a separate
>comparison instruction that feeds the vector mask argument of the
>IFN_EXTRACT_LAST call. We weren't checking whether that comparison
>was supported, leading to
On Sat, 28 Dec 2019, Segher Boessenkool wrote:
> > This is about extracting attributions from changelogs when unambiguous
> > there, and then correcting mistakes or otherwise making minor variants
> > more uniform.
>
> Yes, and I'm saying you probably shouldn't do that.
Extracting
On 28/12/2019 14:54, Segher Boessenkool wrote:
> On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
>> On Sat, 28 Dec 2019, Segher Boessenkool wrote:
>>
>>> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
1 Author: Segher Boessenkool
*730
In this testcase we use an unmasked SVE loop with an Advanced SIMD
epilogue (because we don't yet support fully-masked downward loops).
The main loop uses a gather load for the strided access while the
epilogue loop builds the access from scalars instead. In both cases
we gimplify expressions
On Sun, 22 Dec 2019, Joseph Myers wrote:
> Two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-5b.git
Two more.
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
The EXTRACT_LAST_REDUCTION handling needs to generate a separate
comparison instruction that feeds the vector mask argument of the
IFN_EXTRACT_LAST call. We weren't checking whether that comparison
was supported, leading to an ICE on the testcase.
Tested on aarch64-linux-gnu and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93036
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089
Bug ID: 93089
Summary: Force mprefer-vector-width=512 in 'e' simd clones
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #3 from Jakub Jelinek ---
Note, the above isn't the smallest possible fix, so perhaps for backporting
instead of the gcc/config/i386/ changes
--- gcc/config/i386/sse.md.jj 2019-12-27 18:16:48.146431083 +0100
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #2 from Jakub Jelinek ---
Created attachment 47556
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47556=edit
gcc10-pr93069.patch
Untested fix.
On Sat, Dec 28, 2019 at 01:05:13PM +, Joseph Myers wrote:
> On Sat, 28 Dec 2019, Segher Boessenkool wrote:
>
> > On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> > > 1 Author: Segher Boessenkool
> > > *730 Author: Segher Boessenkool
> > > 2 Author:
On Sat, Dec 28, 2019 at 12:02 PM Jakub Jelinek wrote:
>
> On Sat, Dec 28, 2019 at 11:48:12AM +0100, Uros Bizjak wrote:
> > On Sat, Dec 28, 2019 at 10:33 AM Jakub Jelinek wrote:
> > >
> > > Hi!
> > >
> > > In i386.md, we have nearbyint2 and rint2 patterns that expand
> > > SF/DF/XF mode patterns
On Sat, 28 Dec 2019, Segher Boessenkool wrote:
> On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> > 1 Author: Segher Boessenkool
> > *730 Author: Segher Boessenkool
> > 2 Author: Segher Boesssenkool
>
> The first and third are only in changelogs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
On Fri, Dec 27, 2019 at 11:35:21AM +, Joseph Myers wrote:
> On Fri, 27 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > I'm not really sure I understand why we don't want merge commits into
> > trunk, especially for large changes. Performing archaeology on a change
> > is just so much easier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2
On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> Email addresses from the ChangeLog files are not validated during
> commits, so a number of typos exist in the extracted data. I've
> extracted the 'Author:' entry from a prototype conversion and then piped
> that through
Ping #1
Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 1/3 is the GCC changes: Documentation and new avr-specific
configure options:
--with-libf7 selects to which level double support from libf7 is added
to libgcc.
--with-double-comparison select what FLOAT_LIB_COMPARE_RETURNS_BOOL
Ping #1
Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 3/3 is the actual libf7 implementation. A great deal of which is
assembly, together with C + inline assembly for higher routines.
Johann
libgcc/config/avr/libf7/
* t-libf7: New file.
* t-libf7-math: New file.
*
Ping #1
Now that the avr backend can support 64-bit floats by means of
configure-options --with-double= and --with-long-double=, this patch
series adds some routines to support it.
It's an ad-hoc, avr-specific implementation in assembly and GNU-C which
is added as a new subfolder in
Ping #1
Am 16.12.19 um 17:40 schrieb Georg-Johann Lay:
Patch 2/3 is the libgcc additions:
--with-libf7 selects which makefile-snips from libf7 to use.
libgcc/
* config.host (tmake_file) [target=avr]: Add t-libf7,
t-libf7-math, t-libf7-math-symbols as specified by --with-libf7=.
*
Ping #1
Now that the avr backend can support 64-bit floats by means of
configure-options --with-double= and --with-long-double=, this patch
series adds some routines to support it.
It's an ad-hoc, avr-specific implementation in assembly and GNU-C which
is added as a new subfolder in
Ping #1.
Hi, this patch turns off -fipa-icf-variables because it generates wrong
code like for PR92606. As there is no target hook that could decide
whether such optimizations are obsolete, disable such optimizations
alltogether until PR92932 (target hook to disable such optimizations
Ping #1
Hi, currently device support in avr-gcc is accomplished by injecting a
specs file my means of -specs=... in dirver self specs.
This patch adds a new avr driver option to omit the addition of
respective -specs option so give the user more freedom.
Ok to apply?
Johann
*
On Fri, Dec 27, 2019 at 07:47:02PM +, Richard Earnshaw (lists) wrote:
> 1 Author: Segher Boessenkool
> *730 Author: Segher Boessenkool
> 2 Author: Segher Boesssenkool
The first and third are only in changelogs. The second even happened
only once, afaics?
These errors only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088
Bug ID: 93088
Summary: [10 Regression] Compile time hog on
gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3
-funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
Product: gcc
On Fri, 27 Dec 2019, Eric S. Raymond wrote:
> > Merge info is not one of those cases.
>
> Sometimes. Some Subversion mergeinfo operations map to Git's
> branch-centric merging. Many do not, corresponding to cherry-picks
> that cannot be expressed in a Git history.
And in the case of merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087
Bug ID: 93087
Summary: Bogus `-Wsuggest-attribute=cold` on function already
marked as `__attribute__((cold))`
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
On Sat, Dec 28, 2019 at 11:48:12AM +0100, Uros Bizjak wrote:
> On Sat, Dec 28, 2019 at 10:33 AM Jakub Jelinek wrote:
> >
> > Hi!
> >
> > In i386.md, we have nearbyint2 and rint2 patterns that expand
> > SF/DF/XF mode patterns to rounding instructions. For pre-sse4.1 that is
> > done using XFmode
On Sat, Dec 28, 2019 at 10:33 AM Jakub Jelinek wrote:
>
> Hi!
>
> In i386.md, we have nearbyint2 and rint2 patterns that expand
> SF/DF/XF mode patterns to rounding instructions. For pre-sse4.1 that is
> done using XFmode and so inappropriate for vectorization, but for sse4.1
> and later we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi!
In i386.md, we have nearbyint2 and rint2 patterns that expand
SF/DF/XF mode patterns to rounding instructions. For pre-sse4.1 that is
done using XFmode and so inappropriate for vectorization, but for sse4.1
and later we can just use the {,v}{round,rndscale}p{s,d} instructions
when we emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066
--- Comment #3 from Andreas Schwab ---
Or use (uintptr_t)-1 instead.
Hi!
The r279710 commit added 4 libcuda calls that weren't used before, added
them properly to libgomp/plugin/cuda-lib.def but didn't add them to the
fallback cuda.h.
The following patch does that. Bootstrapped/regtested on x86_64-linux and
i686-linux, built and tested with x86_64-linux to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Sat Dec 28 09:26:03 2019
New Revision: 279747
URL: https://gcc.gnu.org/viewcvs?rev=279747=gcc=rev
Log:
PR bootstrap/93074
* plugin/cuda/cuda.h (cuDeviceGetName,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066
--- Comment #2 from Jakub Jelinek ---
(In reply to dave.anglin from comment #1)
> Including stdint.h after inttypes.h would avoid the problem
That would be quite difficult, as stdint.h is included by libgomp.h that needs
to be included first.
In moving the history of a project old enough to have used
more than one version-control system, I think it's good practice
to mark the strata. I'm even interested in pinning down the
RCS-to-CVS cutover, if there's enough evidence to establish that.
I've added an issue to the tracker about
73 matches
Mail list logo
