[Bug testsuite/79867] New: [cygwin] LD_LIBRARY_PATH ignored, contaminating (nearly?) all test results

[daniel.santos at pobox dot com]

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.

[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)

[kobalicek.petr at gmail dot com]

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 bootstrap/79814] pass-instances.def:36:14: error: ‘*.gcc::pass_manager::pass_warn_unused_result_1’ is used uninitialized in this function

[pinskia at gcc dot gnu.org]

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 target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute

[danglin at gcc dot gnu.org]

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 target/77850] FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute

[danglin at gcc dot gnu.org]

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 fortran/79866] New: diagnostics: typo in "Variable %s at %L of type EVENT_TYPE"

[roland.illig at gmx dot de]

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,
   >declared_at);

The second LOCK_TYPE should probably be EVENT_TYPE, like in all other
diagnostics of that kind.

[Bug middle-end/77546] [6/7 regression] C++ software renderer performance drop

[tulipawn at gmail dot com]

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 target/78994] -Ofast makes aarch64 C++ benchmark slower for A53

[tulipawn at gmail dot com]

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 target/77468] [7 Regression] C-ray regression on Aarch64

[tulipawn at gmail dot com]

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/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[segher at gcc dot gnu.org]

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 c++/79865] New: Crash when calling member function with template parameter from generic lambda

[gufideg at gmail dot com]

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=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{});
}

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/79233] portable p-bit shift with p <= 64 not optimized on powerpc64

[segher at gcc dot gnu.org]

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 target/79251] PowerPC vec_insert generates store-hit-load if the element number is variable

[segher at gcc dot gnu.org]

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/79395] Compile error with -mcpu=power9 and __builtin_vec_vcmpne_p

[segher at gcc dot gnu.org]

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 fortran/79864] Implicit type conversion on assignment of unallocated array to unallocated array variable segfaults.

[vehre at gcc dot gnu.org]

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 fortran/79864] New: Impl

[vehre at gcc dot gnu.org]

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/79863] Assignment of unallocated array to unallocated array variable leads to access of unallocated memory

[vehre at gcc dot gnu.org]

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/79863] New: Assignment of unallocated array to unallocated array variable leads to access of unallocated memory

[vehre at gcc dot gnu.org]

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 c++/79862] New: Compilation error while building libstdc++

[sbansal at ciena dot com]

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 target/77468] [7 Regression] C-ray regression on Aarch64

[tulipawn at gmail dot com]

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 target/77468] [7 Regression] C-ray regression on Aarch64

[tulipawn at gmail dot com]

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 fortran/79861] New: i18n: add translator comment for "%s !$ACC LOOP loops not perfectly nested at %L"

[roland.illig at gmx dot de]

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, >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 fortran/79844] diagnostics: extra space at end of line

[roland.illig at gmx dot de]

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 ", >where);
gfc_error ("Redundant ERRMSG tag found at %L ", >where);
gfc_error ("Redundant UNTIL_COUNT tag found at %L ",

[Bug ada/66205] gnatbind generates invalid code when finalization is enabled in restricted runtime

[simon at pushface dot org]

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 bootstrap/79814] pass-instances.def:36:14: error: ‘*.gcc::pass_manager::pass_warn_unused_result_1’ is used uninitialized in this function

[rguenther at suse dot de]

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 fortran/79860] New: i18n: single-word translation in "Character-valued %s %qs"

[roland.illig at gmx dot de]

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, >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 fortran/79859] New: diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[roland.illig at gmx dot de]

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 rtl-optimization/61984] use mr. to remove extra cmp instruction on ppc

[segher at gcc dot gnu.org]

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 rtl-optimization/79858] New: Explain to translators what %smode means

[roland.illig at gmx dot de]

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 target/56906] FAIL: g++.dg/opt/vt4.C -std=gnu++* scan-assembler-not _ZTV.A

[segher at gcc dot gnu.org]

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 target/56606] GCC refuses to emit long calls for operator new/delete on PowerPC

[segher at gcc dot gnu.org]

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 c++/79857] New: cgraph_node::verify_node should call internal_error instead of error

[roland.illig at gmx dot de]

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 rtl-optimization/79856] New: rtl_verify_edges: use internal_error instead of error

[roland.illig at gmx dot de]

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/79855] New: params.def: missing period in PARAM_MAX_STORES_TO_MERGE

[roland.illig at gmx dot de]

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 target/54168] ARM: Redundant instructions emitted at -O3

[segher at gcc dot gnu.org]

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 fortran/79854] New: diagnostics: gfc_conv_constant_to_tree should be gfc_internal_error

[roland.illig at gmx dot de]

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 (>ts));

Since the diagnostic mentions an internal function name, it must be a
gfc_internal_error instead of a fatal_error.

[Bug c/79847] diagnostics: missing space in "implicit declaration of function"

[mpolacek at gcc dot gnu.org]

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 c/79847] diagnostics: missing space in "implicit declaration of function"

[mpolacek at gcc dot gnu.org]

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=gcc=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 fortran/79853] New: diagnostics: double space in "Assumed or deferred"

[roland.illig at gmx dot de]

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 fortran/79852] New: diagnostics should not end with exclamation mark

[roland.illig at gmx dot de]

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 lto/79851] New: diagnostics: replace '%s' with %qs in all diagnostics

[roland.illig at gmx dot de]

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 ipa/79850] New: diagnostics: typo in "fields has different layout"

[roland.illig at gmx dot de]

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 ipa/79849] New: diagnostics: typo in "type %qT itself violate the C++ One Definition Rule"

[roland.illig at gmx dot de]

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/79848] New: diagnostics: too complicated %<%s%>

[roland.illig at gmx dot de]

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 c/79813] Hitting seg fault in cc1

[mpolacek at gcc dot gnu.org]

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 c/79847] diagnostics: missing space in "implicit declaration of function"

[mpolacek at gcc dot gnu.org]

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 fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[roland.illig at gmx dot de]

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?