[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #6 from Roland Illig --- Could you perhaps make all 6 messages in that function follow the same syntax?
[Bug c/79847] diagnostics: missing space in "implicit declaration of function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79847 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-04 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Will fix.
[Bug c/79813] Hitting seg fault in cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79813 Marek Polacek changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Marek Polacek --- Closing out.
[Bug ipa/79848] New: diagnostics: too complicated %<%s%>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79848 Bug ID: 79848 Summary: diagnostics: too complicated %<%s%> Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from ipa-devirt.c: inform (loc_t1, "type name %<%s%> should match type name %<%s%>", name1, name2); All instances of %<%s%> should be replaced with the much simpler %qs, in all files.
[Bug ipa/79849] New: diagnostics: typo in "type %qT itself violate the C++ One Definition Rule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79849 Bug ID: 79849 Summary: diagnostics: typo in "type %qT itself violate the C++ One Definition Rule" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from ipa-devirt.c: inform (loc_t1, "type %qT itself violate the C++ One Definition Rule", t1); The "violate" should probably be "violates".
[Bug ipa/79850] New: diagnostics: typo in "fields has different layout"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79850
Bug ID: 79850
Summary: diagnostics: typo in "fields has different layout"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from ipa-devirt.c:
warn_odr (t1, t2, f1, f2, warn, warned,
G_("fields has different layout "
"in another translation unit"));
The "has" should probably be "have".
[Bug lto/79851] New: diagnostics: replace '%s' with %qs in all diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79851 Bug ID: 79851 Summary: diagnostics: replace '%s' with %qs in all diagnostics Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from lto-streamer.c: fatal_error (input_location, "bytecode stream in file '%s' generated with LTO version " As the German translator, I currently cannot translate '%s' into %qs (which is much easier to type), since GNU Gettext is buggy (https://savannah.gnu.org/bugs/index.php?50455). Therefore, GCC should be consistent in all diagnostics and never use '%s' or "%s" or `%s' or %<%s%>, but instead only %qs. The above is only one instance. Please fix all diagnostics in all files.
[Bug fortran/79852] New: diagnostics should not end with exclamation mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852
Bug ID: 79852
Summary: diagnostics should not end with exclamation mark
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/decl.c:
gfc_error ("%qs at %C is already defined as FINAL procedure!", name);
Having a few diagnostics end with an exclamation mark makes them stick out
although they are nothing special.
All diagnostics in all files (not only Fortran) should not end with punctuation
(except for the occasional "did you mean %qs?").
[Bug fortran/79853] New: diagnostics: double space in "Assumed or deferred"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79853
Bug ID: 79853
Summary: diagnostics: double space in "Assumed or deferred"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/decl.c:
gfc_error ("Assumed or deferred character length variable %qs "
" in constant expression at %L",
There are two spaces between "%qs" and "in", there should only be one.
[Bug c/79847] diagnostics: missing space in "implicit declaration of function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79847 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Sat Mar 4 11:04:50 2017 New Revision: 245893 URL: https://gcc.gnu.org/viewcvs?rev=245893&root=gcc&view=rev Log: PR c/79847 * c-decl.c (implicit_decl_warning): Add missing space. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c
[Bug c/79847] diagnostics: missing space in "implicit declaration of function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79847 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug fortran/79854] New: diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79854 Bug ID: 79854 Summary: diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from fortran/trans-const.c: fatal_error (input_location, "gfc_conv_constant_to_tree(): invalid type: %s", gfc_typename (&expr->ts)); Since the diagnostic mentions an internal function name, it must be a gfc_internal_error instead of a fatal_error.
[Bug target/54168] ARM: Redundant instructions emitted at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54168 Segher Boessenkool changed: What|Removed |Added Target|arm, powerpc*-*-* |arm --- Comment #2 from Segher Boessenkool --- Works fine on powerpc as far as I see.
[Bug c/79855] New: params.def: missing period in PARAM_MAX_STORES_TO_MERGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855 Bug ID: 79855 Summary: params.def: missing period in PARAM_MAX_STORES_TO_MERGE Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- The text for PARAM_MAX_STORES_TO_MERGE is missing the final period. Most other messages have a final period. All messages in params.def should use consistent grammar. Therefore they all need a final period. It should also be trivial to write a little program that checks this automatically, to prevent future bug reports of the same kind.
[Bug rtl-optimization/79856] New: rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 Bug ID: 79856 Summary: rtl_verify_edges: use internal_error instead of error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In cfgrtl.c, the calls to the "error" function contain a level of technical details that is not useful for the GCC user. Therefore these calls should be replaced with internal_error, and the strings should not be marked for translation.
[Bug c++/79857] New: cgraph_node::verify_node should call internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79857 Bug ID: 79857 Summary: cgraph_node::verify_node should call internal_error instead of error Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- In cgraph.c, the method cgraph_node::verify_node contains several calls to "error", having messages with technical detail that is not appropriate for the GCC user. These calls should be replaced with calls to internal_error, and their arguments should not be translated as part of i18n.
[Bug target/56606] GCC refuses to emit long calls for operator new/delete on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56606 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- The targetm.set_default_type_attributes hook is never called for the "new" operator if it isn't declared, and that is the only place we set the longcall attribute.
[Bug target/56906] FAIL: g++.dg/opt/vt4.C -std=gnu++* scan-assembler-not _ZTV.A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56906 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Segher Boessenkool --- Fixed on all open release branches, so let's close this now.
[Bug rtl-optimization/79858] New: Explain to translators what %smode means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79858
Bug ID: 79858
Summary: Explain to translators what %smode means
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from expmed.c:
sorry ("reverse storage order for %smode", GET_MODE_NAME (mode));
What values can the placeholder %s take in the above diagnostic? Is it even a
diagnostic? There should be a /* TRANSLATORS: ... */ comment above that line
explaining this.
Just in case that the %s placeholder can influence the grammar of the sentence
in languages other than English, this diagnostic must be rethought completely.
[Bug rtl-optimization/61984] use mr. to remove extra cmp instruction on ppc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61984 Segher Boessenkool changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Segher Boessenkool --- This is fixed now on at least GCC 6 and trunk.
[Bug fortran/79859] New: diagnostics: argument quoted twice in "No initializer for allocatable compoonent"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859 Bug ID: 79859 Summary: diagnostics: argument quoted twice in "No initializer for allocatable compoonent" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from fortran/primary.c: if (!gfc_notify_std (GFC_STD_F2008, "No initializer for " "allocatable component '%qs' given in the " "structure constructor at %C", comp->name)) The single quotes around %qs are superfluous.
[Bug fortran/79860] New: i18n: single-word translation in "Character-valued %s %qs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79860
Bug ID: 79860
Summary: i18n: single-word translation in "Character-valued %s
%qs"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/resolve.c:
gfc_error ("Character-valued %s %qs at %L must not be"
" assumed length",
module_proc ? _("module procedure") : _("internal function"),
sym->name, &sym->declared_at);
When translating the message from the above code into languages other than
English, the adjective "character-valued" might take a different form depending
on whether the following word is a procedure or a function.
The German translation may look like this:
Die zeichenwertige Prozedur ...
Die zeichenwertige Funktion ...
Das zeichenwertige Unterprogramm ...
So depending on the inserted word the rest of the sentence may change (Die ->
Das). Therefore translations should always come in whole sentences and only use
placeholders in contexts that don't influence the outside grammar of the
sentence.
[Bug bootstrap/79814] pass-instances.def:36:14: error: ‘*.gcc::pass_manager::pass_warn_unused_result_1’ is used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79814
--- Comment #3 from rguenther at suse dot de ---
On March 4, 2017 12:30:21 AM GMT+01:00, "dmalcolm at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79814
>
>--- Comment #2 from David Malcolm ---
>The code in question is:
> do { ((void)(!(
> __null
>== pass_warn_unused_result_1) ? fancy_abort ("./pass-instances.def",
>36,
>__FUNCTION__), 0 : 0)); if ((1) == 1) pass_warn_unused_result_1 =
>make_pass_warn_unused_result (m_ctxt); else {
>((void)(!(pass_warn_unused_result_1) ? fancy_abort
>("./pass-instances.def", 36,
>__FUNCTION__), 0 : 0)); pass_warn_unused_result_1 =
>pass_warn_unused_result_1->clone (); } p = next_pass_1 (p,
>pass_warn_unused_result_1, pass_warn_unused_result_1); } while (0);
>
>i.e. it's complaining about this assertion:
>
> gcc_assert (NULL == PASS ## _ ## NUM); \
>
>within the definition of NEXT_PASS(PASS, NUM) supplied within the
>pass_manager
>ctor: it's asserting that a pointer field within the object is NULL.
>
>pass_manager::operator new ensures that the underlying memory of the
>pass
>manager is zero-initialized, but clearly the warning has no knowledge
>of this.
Well, the C++ frontend inserts CLOBBERs at the beginning of constructors so
either this zeroing is pointless (and likely optimized out) or the frontend
produces wrong-code in doing so.
>Eliminating the assertion fixes the warning, FWIW.
[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205 simon at pushface dot org changed: What|Removed |Added Known to fail||6.1.0 --- Comment #8 from simon at pushface dot org --- Still fails in version 7.0.1 20170302 (experimental) (GCC).
[Bug fortran/79844] diagnostics: extra space at end of line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79844
--- Comment #1 from Roland Illig ---
Same issue, in fortran/match.c:
gfc_error ("Redundant STAT tag found at %L ", &tmp->where);
gfc_error ("Redundant ERRMSG tag found at %L ", &tmp->where);
gfc_error ("Redundant UNTIL_COUNT tag found at %L ",
[Bug fortran/79861] New: i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79861
Bug ID: 79861
Summary: i18n: add translator comment for "%s !$ACC LOOP loops
not perfectly nested at %L"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
from fortran/openmp.c:
gfc_error ("%s !$ACC LOOP loops not perfectly nested at %L",
clause, &c->loc);
As an i18n translator, I have no idea what could be inserted for the "%s".
Therefore a /* TRANSLATORS: ... */ comment should explain this by giving one or
two examples.
[Bug target/77468] [7 Regression] C-ray regression on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468 --- Comment #29 from PeteVine --- I used a different distribution image (binutils 2.25, no --fix-cortex-a53-835769 option) but the results haven't changed (thunderx tuning must have improved though as it stopped offering any benefit over A53): http://openbenchmarking.org/result/1703043-RI-CRAYDEBIA96
[Bug target/77468] [7 Regression] C-ray regression on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468 --- Comment #30 from PeteVine --- Or rather, the difference observed in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468#c7 is still there @ -Ofast, but the Cortex-A53 result is in the same range now. I'll have to investigate the effect of --fix-cortex-a53-835769 that was always passed by default in the other image.
[Bug c++/79862] New: Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 Bug ID: 79862 Summary: Compilation error while building libstdc++ Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sbansal at ciena dot com Target Milestone: --- Dear Team, I am trying to build 4.8.1 libstdc++-v3 library and I am seeing some compilation errors. Please help. Also, I was able to compile libgcc successfully. GCC configuration used as : === $../gcc-4.8/configure \ --build=i686-pc-linux-gnu \ --host=i686-pc-linux-gnu \ --target=powerpc-wrs-vxworks \ --disable-libmudflap \ --disable-libssp \ --disable-libstdcxx-pch \ --disable-sjlj-exceptions \ --disable-symvers \ --disable-fixed-point \ --disable-decimal-float \ --disable-lto \ --disable-hosted-libstdcxx \ --disable-nls \ --disable-libgomp --enable-threads=vxworks \ --enable-poison-system-directories --enable-version-specific-runtime-libs \ --enable-__cxa_atexit \ --enable-languages=c,c++ \ --enable-shared \ --exec-prefix='/opt/cross/x86-linux2' \ --libdir='/opt/cross/lib' \ --program-transform-name='s,^gcc$,cc,;s,$,ppc,' \ --prefix=/opt/cross \ --with-gmp=/opt/cross \ --with-mpfr=/opt/cross \ --with-isl=/opt/cross \ --with-gxx-include-dir=''\''/opt/cross/'\''include/c++/4.8' --with-build-time-tools=/opt/cross/x86-linux2/powerpc-wrs-vxworks/bin --with-cloog=/opt/cross --with-gnu-as \ --with-gnu-ld \ ../../../../gcc-4.8/libstdc++-v3/libsupc++/tinfo.h:25:20: fatal error: typeinfo: No such file or directory I checked but typeinfo file does not physically exist at below location. gcc-4.8/libstdc++-v3/libsupc++/ I also tried to copy this file "typeinfo" from my older toolchain 4.3.3 but it starts to fail further for "exception" file not found. I again copied "exception" file from my older toolchain 4.3.3 but it again fails further at : error: '_GLIBCXX_END_NAMESPACE' does not name a type. Any help in this regard will be appreciated. Thanks. Sumit
[Bug fortran/79863] New: Assignment of unallocated array to unallocated array variable leads to access of unallocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79863 Bug ID: 79863 Summary: Assignment of unallocated array to unallocated array variable leads to access of unallocated memory Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vehre at gcc dot gnu.org Target Milestone: --- The following simple test code: integer, allocatable :: si(:) integer, allocatable :: ssi(:) si = ssi end is IMHO valid Fortran (2003+ at least), but when run in valgrind will show access to unallocated memory. Without valgrind it most of the time executes without error.
[Bug fortran/79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79863 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/79864] New: Impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79864 Bug ID: 79864 Summary: Impl Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vehre at gcc dot gnu.org Target Milestone: ---
[Bug fortran/79864] Implicit type conversion on assignment of unallocated array to unallocated array variable segfaults.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79864 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Depends on||79863 Summary|Impl|Implicit type conversion on ||assignment of unallocated ||array to unallocated array ||variable segfaults. --- Comment #1 from vehre at gcc dot gnu.org --- The following code segfault with current trunk: integer, allocatable :: si(:) integer(kind=1), allocatable :: ssi(:) si = ssi end Note, there is a small difference to pr78963, namely the different integer kind. This bug is not dependent on the specific kind, only the kinds on both sides of the assignment operator have to different to show the issue. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79863 [Bug 79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory
[Bug target/79395] Compile error with -mcpu=power9 and __builtin_vec_vcmpne_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79395 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- Is this fixed now?
[Bug target/79251] PowerPC vec_insert generates store-hit-load if the element number is variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251 --- Comment #2 from Segher Boessenkool --- Perhaps something like: (copy word 1 in vB to word rB in vT; BE) sldi rB,rB,2 lvsl vP,0,rB vperm vT,vT,vT,vP xxinsertw vT,vB,0 lvsr vP,0,rB vperm vT,vT,vT,vP (i.e. rotate the dest vector so that the dest elt becomes elt 0, do the insert, rotate back).
[Bug target/79233] portable p-bit shift with p <= 64 not optimized on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79233 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-04 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Yes, but how can we model this in GCC?
[Bug c++/79865] New: Crash when calling member function with template parameter from generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79865
Bug ID: 79865
Summary: Crash when calling member function with template
parameter from generic lambda
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gufideg at gmail dot com
Target Milestone: ---
Created attachment 40882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40882&action=edit
GCC Version
Inputting this code makes GCC crash on the call of `crashIt`:
#include
struct Subject {
using Types = std::tuple;
};
struct Test {
template
void test() {
test(std::make_index_sequence::value>{});
}
template
void test(std::index_sequence) {
int unpack[] = {(static_cast([&](auto i){
using Type = std::tuple_element_t;
crashIt(); // Here's the crash!
}(std::integral_constant{})), 0)..., 0};
(void)unpack;
}
template
void crashIt() {}
};
int main(){
Test{}.test();
}
Not using a lambda in the expansion of `S` make the code compile.
This code compile fine under Clang 3.9.1.
The complete GCC version is in the attachement.
[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79202 --- Comment #5 from Segher Boessenkool --- Can't this just use a friz? If the cast to int wouldn't fit in an int it is undefined behaviour.
[Bug target/77468] [7 Regression] C-ray regression on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468 --- Comment #31 from PeteVine --- Indeed, that was it! I've probably found the source of my A53 issues: http://openbenchmarking.org/result/1703040-RI-CRAYERRAT99 This means comment #29 exposes a different issue and Cortex A53 codegen still is suboptimal.
[Bug target/78994] -Ofast makes aarch64 C++ benchmark slower for A53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78994 --- Comment #7 from PeteVine --- Not affected by -mno-fix-cortex-a53-843419 which gives the issue full validity. -Ofast pessimizes Cortex A53 codegen somehow and switching to e.g. -mcpu=cortex-a57 fixes it. (tested on trunk)
[Bug middle-end/77546] [6/7 regression] C++ software renderer performance drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546 PeteVine changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from PeteVine --- Passing -mno-fix-cortex-a53-843419 fixes the issue; gcc 6.3 yields a 38.2 score while gcc 7.0.1 an even better 39.5 using the same workaround.
[Bug fortran/79866] New: diagnostics: typo in "Variable %s at %L of type EVENT_TYPE"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79866
Bug ID: 79866
Summary: diagnostics: typo in "Variable %s at %L of type
EVENT_TYPE"
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
in fortran/resolve.c:
gfc_error ("Variable %s at %L of type EVENT_TYPE or with subcomponent of "
"type LOCK_TYPE must be a coarray", sym->name,
&sym->declared_at);
The second LOCK_TYPE should probably be EVENT_TYPE, like in all other
diagnostics of that kind.
[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850 John David Anglin changed: What|Removed |Added Target|powerpc-*-* |powerpc-*-* hppa64-*-* CC||danglin at gcc dot gnu.org --- Comment #2 from John David Anglin --- Same on hppa64-hp-hpux11.11: # ./gcc-dg-compat-scalar-by-value-4-01.exe cc init: cc test: cc testva: F FF FFF F FF FFF F FF FFF F FF FFF cc test2: cs init: cs test: cs testva: F FF FFF F FF FFF F FF FFF F FF FFF cs test2: cf init: cf test: cf testva: . .. ... . .. ... . .. ... . .. ... cf test2: failed ABORT instruction (core dumped)
[Bug target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77850
--- Comment #3 from John David Anglin ---
We currently use genetic code in hppa_gimplify_va_arg_expr:
static tree
hppa_gimplify_va_arg_expr (tree valist, tree type, gimple_seq *pre_p,
gimple_seq *post_p)
{
if (TARGET_64BIT)
{
/* Args grow upward. We can use the generic routines. */
return std_gimplify_va_arg_expr (valist, type, pre_p, post_p);
}
[Bug bootstrap/79814] pass-instances.def:36:14: error: ‘*.gcc::pass_manager::pass_warn_unused_result_1’ is used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79814 --- Comment #4 from Andrew Pinski --- >Well, the C++ frontend inserts CLOBBERs at the beginning of constructors so >either this zeroing is pointless (and likely optimized out) or the frontend >produces wrong-code in doing so. It is pointless. See PR 71885 for the reasons why.
[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79830
--- Comment #4 from Petr ---
I think the test-case can be simplified to the following code. It still suffers
from the same issues as mentioned above.
#include
#if defined(_MSC_VER)
# include
#else
# include
#endif
void transform(double* dst, const double* src, const double* matrix, size_t
length) {
intptr_t i = static_cast(length);
while ((i -= 2) >= 0) {
__m256d s0 = _mm256_loadu_pd(src);
_mm256_storeu_pd(dst, _mm256_add_pd(s0, s0));
dst += 4;
src += 4;
}
if (i & 1) {
__m128d s0 = _mm_loadu_pd(src);
_mm_storeu_pd(dst, _mm_add_pd(s0, s0));
}
}
[Bug testsuite/79867] New: [cygwin] LD_LIBRARY_PATH ignored, contaminating (nearly?) all test results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867 Bug ID: 79867 Summary: [cygwin] LD_LIBRARY_PATH ignored, contaminating (nearly?) all test results Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: daniel.santos at pobox dot com Target Milestone: --- Running the testsuite resulted in 15,308 instances of the error message "cyggfortran-4.dll: cannot open shared object file: No such file or directory" (similar for libatomic). I could see in the log file that LD_LIBRARY_PATH was set correctly and that the file did exist in that path. After much experimentation, wailing, gnashing of teeth and a few emails to the Cygwin list (https://cygwin.com/ml/cygwin/2017-03/msg00059.html) I learned that LD_LIBRARY_PATH is *not* used in Cygwin. (I presume because there's no practical way to get the Windows kernel to use it when loading libraries.) I couldn't even debug it with gdb because the link failure happened before the image's entry point was even called. This means that when we run the testsuite on Cygwin and we're expecting to test using what we have built, but are actually linking in libgcc, libgfortran, libstdc++, etc. from the environment and NOT from the build tree, so that any Cygwin-specific regression in those libraries that arise between a.) the release that is installed and b.) the version being tested will not be exposed by any normal execution of the testsuite. I'm still fairly green with DejaGnu and Tcl/expect, but perhaps the solution is to 1. Add a platform-abstracted mechanism to DejaGnu for altering the executable and library search paths, and 2. Deprecate and replace all usage (reading or modifying) of the LD_LIBRARY_PATH, SHLIB_PATH and PATH environment variables in tests. Then on Cygwin, DejaGnu can internally track the executable and library search paths separately as they are modified and set the PATH environment variable accordingly. It would also be nice to have an interim hack for running tests on Cygwin.
