New Swedish PO file for 'gcc' (version 10.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-10.1.0.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
*ping* [patch, fortran] PR 27318, warn if interfaces do not match
Am 14.06.20 um 12:10 schrieb Thomas Koenig: Hello world, this patch solves an PR which just had its 14th birthday, continuing the mission of alerting the user to mismatches where possible. Regression-tested (which led to a few of the extra checks for errors). OK for trunk? Ping? I'd like to get this committed in a few days. (I am getting the feeling that I am the only active reviewer for anything except OpenAcc and OpenMP at the moment. While I can do that, at least at the moment, I think it's a bit unhealthy to have only one person do this, and it also makes it hard to get my own patches in, unless I bend the rules a bit and commit anyway after a previous announcement). Regards Thomas
Re: [PATCHv3] Handle TYPE_PACK_EXPANSION in cxx_incomplete_type_diagnostic
On 6/20/20 2:26 PM, Nicholas Krause wrote:
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for all new patches. v3 Fixes both the test case to compile in
C++11 mode and the message to print out only the type.
Signed-off-by: Nicholas Krause
Changelog:
*gcc/cp/typeck2.c: Add missing case TYPE_PACK_EXPANSION for diagnosing
incomplete parameter pack expansion in cxx_incomplete_type_diagnostic
in order to avoid ICEing here.
*gcc/testsuite/g++.db/template/PR95672.C:Add new testcase for PR95672.
This still doesn't satisfy git gcc-verify. Try using
git gcc-commit-mklog --amend
to add a suitable ChangeLog skeleton. You may need to run
contrib/gcc-git-customization.sh first.
---
gcc/cp/typeck2.c| 6 ++
gcc/testsuite/g++.dg/template/PR95672.C | 3 +++
2 files changed, 9 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/template/PR95672.C
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 5fd3b82fa89..28b32fe0b5a 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -552,6 +552,12 @@ cxx_incomplete_type_diagnostic (location_t loc, const_tree
value,
TYPE_NAME (type));
break;
+case TYPE_PACK_EXPANSION:
+ emit_diagnostic (diag_kind, loc, 0,
+"invalid use of pack expansion %qT",
+ type);
+ break;
+
case TYPENAME_TYPE:
case DECLTYPE_TYPE:
emit_diagnostic (diag_kind, loc, 0,
diff --git a/gcc/testsuite/g++.dg/template/PR95672.C
b/gcc/testsuite/g++.dg/template/PR95672.C
new file mode 100644
index 000..8795c13f365
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/PR95672.C
@@ -0,0 +1,3 @@
+//c++ PR96572
+// {dg-options "-std=c++11"}
+struct g_class : decltype (auto) ... { } ; { dg-error "invalid use of pack
expansion" }
This test still fails.
Jason
Re: PING^2: V5 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386
On Sat, Jun 20, 2020 at 3:40 PM H.J. Lu wrote:
> > > > >> 2) can we automatically deduce option name:
> > > > >>
> > > > >>> + ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO, "-mrdpid")
> > > > >>> + ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO, "-mrdrnd")
> > > > >>
> > > > >> I mean "-m" + "rdrnd" == "-mrdrnd" ?
> > > > >
> > > > > The new option field serves 2 purposes:
> > > > >
> > > > > 1. Not all features have a corresponding command-line option
> > > > >
> > > > > ISA_NAMES_TABLE_ENTRY("cmov", FEATURE_CMOV, P_ZERO, NULL)
> > > > >
> > > > > for (i = 0; i < ARRAY_SIZE (isa_names_table); i++)
> > > > > if (isa_names_table[i].option)
> > > > >
> > > > > 2. Some feature has a different name in the command-line option.
> > > > >
> > > > >ISA_NAMES_TABLE_ENTRY("fxsave", FEATURE_FXSAVE, P_ZERO, "-mfxsr")
> > > >
> > > > I noticed that, one can theoretically use "" for an option that does not
> > > > have a flag. And NULL for these which have option equal to "-m" + name.
> > > > Anyway, that's a nit.
> > > >
> > > > I support the patch!
> > > > Martin
> > > >
> > > > >
> > > > > Here is the updated patch. OK for master?
> > > > >
> > > > > Thanks.
> > > > >
> > > >
> > >
> > > PING:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546522.html
> > >
> >
> > PING.
>
> Hi,
>
> We have patches like
>
> https://gcc.gnu.org/pipermail/gcc-bugs/2020-June/705851.html
>
> queued up because of this prerequisite patch. Are there any objections
> to this patch?
Yes, there are my objections.
As explained before, I support unifying libgcc and core gcc handling,
but _NOT_ unifying with driver-i386.c. Unifying libgcc and core gcc
handling would have benefit to avoid desynchronisation between the two
(which happened multiple times in the past, resulting in various API
issues). OTOH, unifying with driver-i386.c would result in quite messy
approach, because driver-i386 handles more targets beside relatively
recent 64bit Intel and AMD targets, not to mention heuristics to
determine the most appropriate target when standard detection fails
(e.g. emulators).
Uros.
Re: PING^2: V5 [PATCH] x86: Move cpuinfo.h from libgcc to common/config/i386
On Sun, Jun 21, 2020 at 10:18 AM Uros Bizjak wrote:
>
> On Sat, Jun 20, 2020 at 3:40 PM H.J. Lu wrote:
>
> > > > > >> 2) can we automatically deduce option name:
> > > > > >>
> > > > > >>> + ISA_NAMES_TABLE_ENTRY("rdpid", FEATURE_RDPID, P_ZERO,
> > > > > >>> "-mrdpid")
> > > > > >>> + ISA_NAMES_TABLE_ENTRY("rdrnd", FEATURE_RDRND, P_ZERO,
> > > > > >>> "-mrdrnd")
> > > > > >>
> > > > > >> I mean "-m" + "rdrnd" == "-mrdrnd" ?
> > > > > >
> > > > > > The new option field serves 2 purposes:
> > > > > >
> > > > > > 1. Not all features have a corresponding command-line option
> > > > > >
> > > > > > ISA_NAMES_TABLE_ENTRY("cmov", FEATURE_CMOV, P_ZERO, NULL)
> > > > > >
> > > > > > for (i = 0; i < ARRAY_SIZE (isa_names_table); i++)
> > > > > > if (isa_names_table[i].option)
> > > > > >
> > > > > > 2. Some feature has a different name in the command-line option.
> > > > > >
> > > > > >ISA_NAMES_TABLE_ENTRY("fxsave", FEATURE_FXSAVE, P_ZERO, "-mfxsr")
> > > > >
> > > > > I noticed that, one can theoretically use "" for an option that does
> > > > > not
> > > > > have a flag. And NULL for these which have option equal to "-m" +
> > > > > name.
> > > > > Anyway, that's a nit.
> > > > >
> > > > > I support the patch!
> > > > > Martin
> > > > >
> > > > > >
> > > > > > Here is the updated patch. OK for master?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > >
> > > >
> > > > PING:
> > > >
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546522.html
> > > >
> > >
> > > PING.
> >
> > Hi,
> >
> > We have patches like
> >
> > https://gcc.gnu.org/pipermail/gcc-bugs/2020-June/705851.html
> >
> > queued up because of this prerequisite patch. Are there any objections
> > to this patch?
>
> Yes, there are my objections.
>
> As explained before, I support unifying libgcc and core gcc handling,
> but _NOT_ unifying with driver-i386.c. Unifying libgcc and core gcc
> handling would have benefit to avoid desynchronisation between the two
> (which happened multiple times in the past, resulting in various API
> issues). OTOH, unifying with driver-i386.c would result in quite messy
> approach, because driver-i386 handles more targets beside relatively
> recent 64bit Intel and AMD targets, not to mention heuristics to
> determine the most appropriate target when standard detection fails
> (e.g. emulators).
Only the duplicated parts of driver-i386.c should be unified. The only impact
should be removing code duplications. If it isn't the case, it is a bug in my
implementation.
--
H.J.
[PATCHv4] Handle TYPE_PACK_EXPANSION in cxx_incomplete_type_diagnostic
From: Nicholas Krause
This fixs the PR95672 by adding the missing TYPE_PACK_EXPANSION case in
cxx_incomplete_type_diagnostic in order to avoid ICES on diagnosing
incomplete template pack expansion cases. In v2, add the missing required
test case for all new patches. v3 Fixes both the test case to compile in
C++11 mode and the message to print out only the type. v4 fixes the testcase
to only target C++11.
gcc/cp/ChangeLog:
* typeck2.c (cxx_incomplete_type_diagnostic):
gcc/testsuite/ChangeLog:
* g++.dg/template/PR95672.C: New test.
Signed-off-by: Nicholas Krause
---
gcc/cp/typeck2.c| 6 ++
gcc/testsuite/g++.dg/template/PR95672.C | 3 +++
2 files changed, 9 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/template/PR95672.C
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 5fd3b82fa89..28b32fe0b5a 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -552,6 +552,12 @@ cxx_incomplete_type_diagnostic (location_t loc, const_tree
value,
TYPE_NAME (type));
break;
+case TYPE_PACK_EXPANSION:
+ emit_diagnostic (diag_kind, loc, 0,
+"invalid use of pack expansion %qT",
+ type);
+ break;
+
case TYPENAME_TYPE:
case DECLTYPE_TYPE:
emit_diagnostic (diag_kind, loc, 0,
diff --git a/gcc/testsuite/g++.dg/template/PR95672.C
b/gcc/testsuite/g++.dg/template/PR95672.C
new file mode 100644
index 000..fcc3da0a132
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/PR95672.C
@@ -0,0 +1,3 @@
+//c++ PR96572
+// { dg-do compile { target c++11 } }
+struct g_class : decltype (auto) ... { } ; //{ dg-error "invalid use of pack
expansion" }
--
2.20.1
Re: [PATCH] recog: Use parameter packs for operator()
On Thu, 18 Jun 2020, Sebastian Huber wrote: > b952c2cfcd74c284970e1b9bf1fca58f5f69ab23 on 10th of June. I build GCC > roughly once per week. I have daily builds running on i386-unknown-freebsd11.3 (since this is the flavor most likely to trigger issues) and the failure started in the 24 hours leading up to 2020-06-18-16:40UTC. clang 8.0.1 is the system compiler on FreeBSD 11, so we need a way for that to work I'm afraid. I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95805 and included the relevant part of the build log. Gerald
Re: [PATCH] RISC-V: Fix compilation failed for frflags builtin in C++ mode
Hi Jason: Committed, thanks for your review :) > You should also be able to remove > > > #define RISCV_ATYPE_VOID void_type_node That's still used for builtin functions without return value :)
Re: [PATCH] RISC-V: Normalize arch string in driver time
Hi Jim: Thanks for your review, committed with ASM_SPECS clean up. > This has the side effect that we are now passing -march twice to cc1 and as, > but that should be harmless as the last one wins. Yeah, I tried to find a way to remove the duplication but have not found a good solution yet. On Sun, Jun 21, 2020 at 5:37 AM Jim Wilson wrote: > > On Fri, Jun 19, 2020 at 2:53 AM Kito Cheng wrote: > > * config/riscv/riscv.h (DRIVER_SELF_SPECS): New. > > This looks good to me. This has the side effect that we are now > passing -march twice to cc1 and as, but that should be harmless as the > last one wins. I think this makes the riscv_expand_arch call in > ASM_SPECS redundant, but it isn't really hurting anything if we end up > with extra unnecessary calls to riscv_expand_arch so that is an > optional possible cleanup. > > Jim
Re: [PATCH] Treat { 0 } specially for structs with the designated_init attribute.
Hi Martin,
Thanks for your help.
Martin Sebor writes:
> This can be a little confusing and I don't work with the front end
> stuff often enough to remember it so I always have to look it up.
> There's a TYPE_DECL that corresponds to the definition of the type
> that for user-defined types has a source location, otherwise, if T
> it's a TYPE_P(T), it doesn't.
>
> I think the TYPE_NAME(T) macro gets the TYPE_DECL for a type T.
> I find the best way to figure this out is to think of something
> similar to what you're trying to do (like an error or warning in
> this case) and look at/step through the code that implements it.
If I insert an assertion in the code, I find that 'constructor_type' is
indeed a TYPE_P, and TYPE_NAME doesn't work on it. If I try to use
TYPE_NAME, this happens:
$ install/bin/gcc -c -o test.o test.c
test.c:14:17: warning: positional initialization of field ‘foo’ in ‘struct
S’ declared with ‘designated_init’ attribute [-Wdesignated-init]
14 | struct S s2 = { 0, 0 }; /* should warn */
| ^
test.c:14:17: note: (near initialization for ‘s2’)
test.c:14:8: internal compiler error: tree check: expected tree that
contains ‘decl minimal’ structure, have ‘identifier_node’ in pop_init_level, at
c/c-typeck.c:8790
14 | struct S s2 = { 0, 0 }; /* should warn */
|^
[backtrace]
$ cat -n gcc/c/c-typeck.c | grep -E -A 3 '^\s*8790\s'
8790inform (DECL_SOURCE_LOCATION
8791(TYPE_NAME
8792 (constructor_type)),
8793"in definition of %qT", constructor_type);
So it appears that TYPE_NAME is returning an IDENTIFIER_NODE. Strangely,
the gccint documentation says, referring to 'TYPE_NAME':
(Note this macro does _not_ return an 'IDENTIFIER_NODE', as you
might expect, given its name!)
> Unfortunately, attributes don't have locations (yet).
Hmm, well maybe I could implement that. I'm not very familiar with the
GCC source (this is my first patch), but I'll see if I can figure it
out. It would probably be useful for other warnings/errors too.
> The warning could have two notes, one pointing to the member and
> another pointing to its type. It's a judgment call what's more
> important in each case. It's usually straightforward to find the
> enclosing type given a note pointing to a member.
If it's not possible to point to the attribute itself, then this is
probably the next best thing. Still, it would be nice to be able to
point directly to the attribute...
> I was under the impression that GCC silently ignored attributes on
> type declarations and only respected them on definitions. But it's
> also possible it's inconsistent (attribute handling is still a bit
> of a mess).
Yes, actually you're right. I tried defining a struct and then applying
an attribute to a later declaration, and it had no effect. Incidentally,
this seems to me to be confusing behavior, and should probably produce a
warning (or even an error), but that's another issue.
Thanks,
Asher
--
Violence is the last refuge of the incompetent.
-- Salvor Hardin
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Re: drop -aux{dir,base}, revamp -dump{dir,base}
On Jun 19, 2020, Tobias Burnus wrote:
> Done; nvptx compiled but for AMDGCN I got a compile error:
> in one function 'argv_obstack' was lacking a 'cc_' prefix ('cc_argv_obstack'),
> see attached patch (vs. mainline, not vs. either of your patches).
Ah, I see, cut&pasto, different obstacks. Thanks for fixing it.
> And there is an (unfixed) warning:
> config/gcn/mkoffload.c:535:9: warning: unused variable 'dumpbase'
Thanks, I've removed that.
> I additionally did run the test case manually → files.log for the
> produced files.
This is with -save-temps, right? I've arranged to drop the
no-longer-necessary -save-temps from the test runs, but you didn't get
to experience it because of:
> Unfortunately, running the testsuite fails now with a tcl error:
> : error executing dg-final: unknown or ambiguous subcommand "set":
Interesting, in my test run (native only) I didn't trigger that problem.
+++ b/gcc/testsuite/lib/scanoffload.exp
+if [info set offload_target] {
The 'set' above should be 'exists'.
--
Alexandre Oliva, freedom fighterhe/himhttps://FSFLA.org/blogs/lxo/
Free Software Evangelist Stallman was right, but he's left :(
GNU Toolchain Engineer Live long and free, and prosper ethically
Re: [PATCH] PR 83938 Reduce memory consumption in stable_sort/inplace_merge
Gentle remider. On 11/06/20 8:32 am, François Dumont wrote: As we are on patching algos we still have this old one. From the original patch I only kept the memory optimization part as the new performance test was not showing good result for the other part to change pivot value. I also kept the small change in get_temporary_buffer even if I don't have strong feeling about it, it just make sure that we'll try to allocate 1 element as a last chance allocation. Note that there is still place for an improvement. If we miss memory on the heap we then use a recursive implementation which then rely on stack memory. I would be surprise that a system which miss heap memory would have no problem to allocate about the same on the stack so we will surely end up in a stack overflow. I still have this on my todo even if I already made several tries with no satisfying result in terms of performance. Tested under Linux x86_64. Commit message: libstdc++: Limit memory allocation in stable_sort/inplace_merge (PR 83938) Reduce memory consumption in stable_sort/inplace_merge to what is used. Co-authored-by: François Dumont libstdc++-v3/ChangeLog: 2020-06-11 John Chang François Dumont PR libstdc++/83938 * include/bits/stl_tempbuf.h (get_temporary_buffer): Change __len computation in the loop. * include/bits/stl_algo.h: (__inplace_merge): Take temporary buffer length from smallest range. (__stable_sort): Limit temporary buffer length. * testsuite/25_algorithms/inplace_merge/1.cc (test03): Test different pivot positions. * testsuite/performance/25_algorithms/stable_sort.cc: Test stable_sort under different heap memory conditions. * testsuite/performance/25_algorithms/inplace_merge.cc: New. Ok to commit ? François
