[Bug target/93720] [10 Regression] vector creation from two parts of two vectors produces TBL rather than ins

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93720

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-16
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Dmitrij Pochepko from comment #2) 
> It looks like peephole2 can be used to optimize it. I'm currently looking
> into in.

Don't.  Can you attach your current patch?  
My bet is you expand this vec_perm like:
(set (reg:V2DF t1) (reg:V2DF low))
(set (reg:V2DF t) (vec_merge:V2DF
   (vec_duplicate:V2DF
(vec_select:DF (reg:V2DF high)
 (parallel [(const_int 2)])))
  (reg:V2DF t1)
  (const_int 2)))

Since it is only two elements.

[Bug bootstrap/93758] Building x86_64-w64-mingw32-gcc (mingw-w64) on macOS Catalina results in "internal compiler error: Segmentation fault"

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93758

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-16
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Are you building GCC with clang or GCC?
Have you tried building a native GCC 9.2 and then building the cross one?

[Bug c++/93753] internal compiler error: in output_constructor_regular_field, at varasm.c:5255

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93753

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code

--- Comment #1 from Andrew Pinski  ---
This is invalid code.  The variable length field should be detected as not last
field in the struct.

[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||marxin at gcc dot gnu.org
  Component|c   |ipa
   Target Milestone|--- |10.0
Summary|ice in  |[10 Regression] ice in
   |propagate_vals_across_arith |propagate_vals_across_arith
   |_jfunc, at ipa-cp.c:2039|_jfunc, at ipa-cp.c:2039

[Bug middle-end/93764] [10 Regression] lzo 2.10 test suite fails with -O2 and -O3

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93764

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|c   |middle-end
   Target Milestone|--- |10.0
Summary|lzo 2.10 test suite fails   |[10 Regression] lzo 2.10
   |with -O2 and -O3|test suite fails with -O2
   ||and -O3

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93710

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93710

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Marek Polacek  ---
Fixed.

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93710

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:eef65c474e6836cc0470eb84f28895050161fcb8

commit r10-6657-geef65c474e6836cc0470eb84f28895050161fcb8
Author: Marek Polacek 
Date:   Wed Feb 12 14:00:51 2020 -0500

c++: Fix poor diagnostic for array initializer [PR93710]

A small improvement for an error in build_user_type_conversion_1:
instead of

array-init1.C:11:1: error: conversion from ‘long int’ to ‘A’ is ambiguous
   11 | };
  | ^

we will print

array-init1.C:8:3: error: conversion from ‘long int’ to ‘A’ is ambiguous
8 |   0L,
  |   ^~

2020-02-12  Marek Polacek  

PR c++/93710 - poor diagnostic for array initializer.
* call.c (build_user_type_conversion_1): Use cp_expr_loc_or_input_loc
for an error call.

* g++.dg/diagnostic/array-init1.C: New test.

[Bug c/93763] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763

--- Comment #1 from David Binderman  ---
Reduced C code is:

typedef struct a a;
struct a {
  a *b
} d;
e, k, ah, al;
f(aa) {
  if (aa & 1)
goto g;
  f(aa | 2);
g:
  h();
}
l() {
  {
f(072);
i(e, d, 92);
  }
}
ag() {
  { i(e, d, 36); }
}
ai(a *m, a *n, unsigned aa) {
  f(aa);
  j(k, l, ah, 1);
}
j(int c, a m, int aj, int aa) {
  int ak = aa;
  { i(e, d, ak); }
}
i(int c, a *m, unsigned aa) {
  {
{ i(c,
(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*m).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b,
0);
}
  }
  int am = aa;
  ai(ag, al, am);
}

[Bug c/93764] New: lzo 2.10 test suite fails with -O2 and -O3

[kloczko.tomasz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93764

Bug ID: 93764
   Summary: lzo 2.10 test suite fails with -O2 and -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kloczko.tomasz at gmail dot com
  Target Milestone: ---

Gcc 9.2 was OK.
With gcc 10.0.1 from rawhide test suite fails like below

+ /usr/bin/make -O -j48 V=1 VERBOSE=1 check test
/usr/bin/make  check-local
/usr/bin/make  all-am
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/lzo-2.10'
./lzotest/lzotest -mlzo -n2 -q './COPYING'

LZO real-time data compression library (v2.10, Mar 01 2017).
Copyright (C) 1996-2017 Markus Franz Xaver Johannes Oberhumer
All Rights Reserved.

internal error - lzo_init() failed !!!
(this usually indicates a compiler bug - try recompiling
without optimizations, and enable `-DLZO_DEBUG' for diagnostics)
make[1]: *** [Makefile:1701: check-local] Error 1
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/lzo-2.10'
make: *** [Makefile:1373: check-am] Error 2
make: *** Waiting for unfinished jobs
./lzotest/lzotest -mavail -n10 -q './COPYING'

LZO real-time data compression library (v2.10, Mar 01 2017).
Copyright (C) 1996-2017 Markus Franz Xaver Johannes Oberhumer
All Rights Reserved.

internal error - lzo_init() failed !!!
(this usually indicates a compiler bug - try recompiling
without optimizations, and enable `-DLZO_DEBUG' for diagnostics)

[Bug c/93763] New: ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763

Bug ID: 93763
   Summary: ice in propagate_vals_across_arith_jfunc, at
ipa-cp.c:2039
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47849=edit
gzipped C source code

For the attached C code, with compiler flag -O3,
sometime between 20200207 and 20200210, does this:

../results.20200207/bin/gcc
../results.20200210/bin/gcc
during IPA pass: cp
c_code/2_2/@msem.nim.c:43465:1: internal compiler error: in
propagate_vals_acros
s_arith_jfunc, at ipa-cp.c:2039
0x821b89 propagate_vals_across_arith_jfunc
../../trunk.git/gcc/ipa-cp.c:2039
0x19364e5 propagate_vals_across_pass_through
../../trunk.git/gcc/ipa-cp.c:2093
0x19364e5 propagate_scalar_across_jump_function
../../trunk.git/gcc/ipa-cp.c:2171
0x19364e5 propagate_constants_across_call
../../trunk.git/gcc/ipa-cp.c:2867

I will have my usual go at reducing the code.

[Bug debug/93751] -g1 does not behave per manual

[stilor at att dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93751

--- Comment #3 from Alexey Neyman  ---
Well, why not fix it then? :) It should be a fairly low risk change, since it
does not remove any DIEs - I think it is quite unlikely that any user depends
on the *absence* of DIEs. And it aligns DWARF with stabs and other formats, and
with the manual.

Do you see any problem with the proposed patch?

[Bug fortran/93762] New: Truncation of deferred-length string when passing as optional

[chaudhry.ross at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762

Bug ID: 93762
   Summary: Truncation of deferred-length string when passing as
optional
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chaudhry.ross at gmail dot com
  Target Milestone: ---

Created attachment 47848
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47848=edit
Minimal reproducing code

(This issue was first reported on SO here:
https://stackoverflow.com/questions/60229805/truncation-of-deferred-length-string-when-passing-as-optional)

When passing strings declared as deferred-length and optional through several
subroutines, they are truncated. A minimal example is attached, which yields
the following (expected) result on Intel 16.0, Intel 2019_U4, or PGI 15.10:

$ ifort main.f90 && ./a.out 
 at bot of deepest_call, str is "12345"
 at bot of interface_call, str is "12345"
 at bot of main, str is "12345"

However, with gfortran 4.8.5:

$ gfortran --version
GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ gfortran main.f90 && ./a.out 
 at bot of deepest_call, str is "12345"
 at bot of interface_call, str is ""
 at bot of main, str is ""

On the newer version of gfortran I have available (7.2 and 8.2.0), this simple
example segfaults when compiled with no options, but truncates the output when
compiled using checks:

$ gfortran --version
GNU Fortran (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gfortran -g -fbacktrace -Wall -Wextra -std=f2008 -fcheck=all -Og main.f90 &&
./a.out
 at bot of deepest_call, str is "12345"
 at bot of interface_call, str is ""
 at bot of main, str is ""

It seems to me that this is a compiler error spanning a range of GCC versions
(at least 4.8.5 to 8.2.0). So my first purpose for reporting it here is so
people are aware of it.

According to francescalus on the StackOverflow post, the error does not occur
on the very latest 10.0.0. However, I think it would be good to add this
minimal example (or something similar) to the gfortran test suite to prevent
the error from occurring again.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #187 from Peter Bisroev  ---
(In reply to dave.anglin from comment #183)
> On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
> >
> > --- Comment #180 from Peter Bisroev  
> > ---
> > (In reply to dave.anglin from comment #177)
> >> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
> >>> I have tried playing around with weak using aCC, however even though it 
> >>> accepts
> >>> both attribute and pragma (and complains if you misspell "weak"), both 
> >>> compiler
> >>> and linker seem to ignore it. But I might have made some mistake there, 
> >>> will
> >>> double check tonight.
> >> Did you look at .s output?  You could also test a simple program with a 
> >> weak
> >> function
> >> in two objects.
> > Sorry Dave, not 100% sure what kind of test you are talking about. Something
> > like this?
> > --
> > // func0.cpp
> >
> > int func0(int) __attribute__((weak));
> > int func0(int arg) {
> > return arg + 1;
> > }
> >
> > // main.cpp
> >
> > int func0(int) __attribute__((weak));
> > int func0(int arg) {
> > return arg + 10;
> > }
> >
> > int main(int argc, char * argv[]) {
> > return func0(argc);
> > }
> > --
> >
> Yes.  Does it link okay?

Hi Dave,

No it does not link, the error I get is "ld: Duplicate symbol "func0(int)" in
files test0.o and func0.o". However it links perfectly fine when compiled with
GCC.

I have attached the results of the test above and another basic C++ one using
an inline virtual method in attachment 47847. In there you will find three
directories for results with aCC, gcc 4-7-4 and gcc 4.7.4 built with
--enable-comdat.

Additionally, in each directory you will find a build.log of how exactly was
the test built, as well as *.objdump disassembly and other info and *.readelf
dumps.

I have not had a chance to look through these in great detail, will do this
later today, but some things I've noticed (not sure how important they are
yet):
- aCC seems to use PCREL21BI relocations while GCC PCREL21B.
- When objdumping C++ test1 for comdat enabled gcc, I get "objdump: test1
symbol number 48 references nonexistent SHT_SYMTAB_SHNDX section". 

Will come back to this a little later today.

Thanks!
--peter

[Bug c++/93741] [10 regression] ICE in incomplete concept definition

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93741

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-15
 Ever confirmed|0   |1

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #186 from Peter Bisroev  ---
Created attachment 47847
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47847=edit
Basic compiler tests v00

[Bug c++/93761] New: ICE when compiling a standard header as a header unit

[cjdb.ns at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93761

Bug ID: 93761
   Summary: ICE when compiling a standard header as a header unit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cjdb.ns at gmail dot com
  Target Milestone: ---

Attempts to compile `` and `` as header units cause GCC to
segfault. I'm aware that there are fewer headers that can be successfully
compiled as a header unit, but I can't find a ticket to track that it causes an
ICE otherwise.

* Branch: devel/c++-modules

* Hash: 50974764f8eaf583a94b08af27f51d604ede644c

* GCC configured with: ../gcc/configure --disable-nls --disable-multilib
--enable-languages=c,c++ --disable-werror --prefix=/opt/gcc-modules

* GCC built with: CFLAGS='-O3 -g0 -w' CXXFLAGS='-O3 -g0 -w'
LDFLAGS='-fuse-ld=gold'

* System: Ubuntu 18.04 (WSL)

* GCC invocation: /opt/gcc-modules/bin/g++ -std=c++2a -fmodule-header -c -x
c++-header /opt/gcc-modules/include/c++/10.0.1/algorithm

* Output:

```
algorithm.ii:1: internal compiler error: Segmentation fault
1 | # 0 "/opt/gcc-modules/include/c++/10.0.1/algorithm"
  |
0x1068dcf crash_signal
../../gcc/gcc/toplev.c:332
0xa08460 hash_table::find_slot_with_hash(std::pair const&,
unsigned int, insert_option)
../../gcc/gcc/hash-table.h:963
0x9f116a get_module_slot
../../gcc/gcc/cp/module.cc:12397
0x9f11c5 get_module(tree_node*, module_state*, bool)
../../gcc/gcc/cp/module.cc:12422
0x9f4189 module_begin_main_file(cpp_reader*, line_maps*, line_map_ordinary
const*)
../../gcc/gcc/cp/module.cc:18278
0xb79988 cb_file_change
../../gcc/gcc/c-family/c-opts.c:1590
0x1adbf99 _cpp_stack_file
../../gcc/libcpp/files.c:995
0x1ade106 cpp_read_main_file(cpp_reader*, char const*, bool)
../../gcc/libcpp/init.c:689
0xb7b9bb c_common_post_options(char const**)
../../gcc/gcc/c-family/c-opts.c:1128
0x8d23c6 process_options
../../gcc/gcc/toplev.c:1388
0x8d23c6 do_compile
../../gcc/gcc/toplev.c:2199
We are damaged, This is broken.
Logic is lost,
We struggle,
Hunt through the rubble for what once was.
See  for instructions.
```

[Bug c++/93761] ICE when compiling a standard header as a header unit

[cjdb.ns at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93761

--- Comment #1 from Christopher Di Bella  ---
Created attachment 47846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47846=edit
Iterator temp

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #185 from Peter Bisroev  ---
(In reply to dave.anglin from comment #184)
> On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> > So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
> > stage bootstrap went fine (running 'make check' now). Using that tried to
> > bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues
> > when linking cc1plus. For example:
> So, it looks like we have garbage collection for COMDAT functions but not
> for weak functions.

I finished running 'make check' tests for gcc 4.7.4 that was compiled with
--enable-comdat. I get exactly the same results as before, exactly the same
tests pass and fail that you have reviewed previously. So I guess we can say
this build works as good as the one without --enable-comdat.

The difference however is in reduced number of PCREL21B errors as show in my
comment before. Additionally I have tried compiling 8.3.0 with comdat enabled
4.7.4 (just like I tried with 4.9.4). In this case we also get a significantly
reduced number of PCREL21B errors. For example, originally for cc1plus, we went
from 569 errors to 58.

> I think we need to look at branch types - "br.call.sptk.many" versus
> "br.call.dptk.many".  I suspect using
> the latter would fix the PCREL21B relocation issues.
Sorry for my lack of knowledge here, would you be able to explain this a bit
more if you get a chance? I looked up IA-64 arch manual, and the diff between
these two branch types is that '.sptk' one uses static taken prediction
strategy and '.dptk' uses dynamic taken prediction strategy. The mechanics here
make sense to me but I am not sure I understand how they relate to the
relocation issue here.

Thanks!
--peter

[Bug translation/93759] Invalid % in param

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759

--- Comment #2 from Roland Illig  ---
(In reply to Andreas Schwab from comment #1)
> Apparently the problem is that "% p" looks like a valid c-format.

Then there's a bug in either gettext or the GCC definitions of where c-format
strings may appear. The decision for making a string c-format or not must not
be based on the string's value, but on the context where it appears.

[Bug c++/91847] init-capture pack of references requires ... on wrong side

[barry.revzin at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91847

--- Comment #2 from Barry Revzin  ---
In the Prague meeting, this paper
(https://brevzin.github.io/cpp_proposals/2095_lambda_pack_cwg/p2095r0.html) was
adopted into what will become the C++20 standard, which moves the & in the
grammar to the left side of the ellipses. 

So now I can say officially, [&...us=ts]{} is the correct spelling.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 92556, which changed state.

Bug 92556 Summary: [10 Regression] ICE if using dependent name inside lambda 
expression in simple-requirement since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92556

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/92556] [10 Regression] ICE if using dependent name inside lambda expression in simple-requirement since r10-3735-gcb57504a55015891

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92556

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/68061] Can't use [[deprecated]] with requires clause

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68061

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:acff02ef1f4bc951ab7b4e3fdc117e0646d5d8f5

commit r10-6650-gacff02ef1f4bc951ab7b4e3fdc117e0646d5d8f5
Author: Jason Merrill 
Date:   Sat Feb 15 15:11:01 2020 +0100

c++: Add test for PR 68061.

PR c++/68061
* g++.dg/concepts/attrib1.C: New.

[Bug c++/92556] [10 Regression] ICE if using dependent name inside lambda expression in simple-requirement since r10-3735-gcb57504a55015891

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92556

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:1e166191ef330f3491d405bf3eb09b2b796c9b0e

commit r10-6649-g1e166191ef330f3491d405bf3eb09b2b796c9b0e
Author: Jason Merrill 
Date:   Sat Feb 15 14:48:08 2020 +0100

c++: Fix lambda in atomic constraint.

find_template_parameters needs to find the mention of T in the lambda.
Fixing that leaves this as a hard error, which may be surprising but is
consistent with lambdas in other SFINAE contexts like template argument
deduction.

gcc/cp/ChangeLog
2020-02-15  Jason Merrill  

PR c++/92556
* pt.c (any_template_parm_r): Look into lambda body.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #184 from dave.anglin at bell dot net ---
On 2020-02-15 12:56 a.m., peter.bisroev at groundlabs dot com wrote:
> So we made some progress here. I have rebuilt 4.7.4 with --enable-comdat. 3
> stage bootstrap went fine (running 'make check' now). Using that tried to
> bootstrap 4.9.4 again. We are getting a lot less PCREL21B relocation issues
> when linking cc1plus. For example:
So, it looks like we have garbage collection for COMDAT functions but not for
weak functions.

I think we need to look at branch types - "br.call.sptk.many" versus
"br.call.dptk.many".  I suspect using
the latter would fix the PCREL21B relocation issues.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #183 from dave.anglin at bell dot net ---
On 2020-02-15 12:49 a.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #180 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #177)
>> On 2020-02-13 6:01 p.m., peter.bisroev at groundlabs dot com wrote:
>>> I have tried playing around with weak using aCC, however even though it 
>>> accepts
>>> both attribute and pragma (and complains if you misspell "weak"), both 
>>> compiler
>>> and linker seem to ignore it. But I might have made some mistake there, will
>>> double check tonight.
>> Did you look at .s output?  You could also test a simple program with a weak
>> function
>> in two objects.
> Sorry Dave, not 100% sure what kind of test you are talking about. Something
> like this?
> --
> // func0.cpp
>
> int func0(int) __attribute__((weak));
> int func0(int arg) {
> return arg + 1;
> }
>
> // main.cpp
>
> int func0(int) __attribute__((weak));
> int func0(int arg) {
> return arg + 10;
> }
>
> int main(int argc, char * argv[]) {
> return func0(argc);
> }
> --
>
Yes.  Does it link okay?

[Bug c++/92583] [8/9 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:15552

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:d71365427670a791c5b54bfec6e3d41210844a8a

commit r10-6648-gd71365427670a791c5b54bfec6e3d41210844a8a
Author: Jason Merrill 
Date:   Sat Feb 15 14:48:08 2020 +0100

c++: Remove more dead code.

gcc/cp/ChangeLog
2020-02-15  Jason Merrill  

PR c++/92583
* pt.c (any_template_parm_r): Remove CONSTRUCTOR handling.

[Bug c++/90764] [10 Regression] internal compiler error in build_deduction_guide, at cp/pt.c:27162

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90764

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:4d5bb56b1d3e6873a7d08dc8f5f4a4997e51bfde

commit r10-6647-g4d5bb56b1d3e6873a7d08dc8f5f4a4997e51bfde
Author: Jason Merrill 
Date:   Sat Feb 15 14:48:08 2020 +0100

c++: Add testcase for PR 90764.

 PR c++/90764
 * g++.dg/cpp1z/class-deduction69.C: New.

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #182 from dave.anglin at bell dot net ---
On 2020-02-14 11:04 p.m., peter.bisroev at groundlabs dot com wrote:
> However just below this check, configure looks for GNU linker, and if one not
> found, disables COMDAT group support even though the second test passed.
>
> However `--enable-comdat` configure flag seems to override this behavior. I
> will try to recompile 4.7.4 with it to see what happens.
That's useful information.  I'll bet same applies to hppa64.

[Bug tree-optimization/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jakub Jelinek  ---
Fixed for 8.4+/9.3+/10+.

[Bug tree-optimization/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

--- Comment #10 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:e24c48585721fc4122ae10282e32af49aff4c380

commit r8-10025-ge24c48585721fc4122ae10282e32af49aff4c380
Author: Jakub Jelinek 
Date:   Sat Feb 15 12:53:44 2020 +0100

match.pd: Disallow side-effects in GENERIC for non-COND_EXPR to COND_EXPR
simplifications [PR93744]

As the following testcases show (the first one reported, last two
found by code inspection), we need to disallow side-effects
in simplifications that turn some unconditional expression into conditional
one.  From my little understanding of genmatch.c, it is able to
automatically disallow side effects if the same operand is used multiple
times in the match pattern, maybe if it is used multiple times in the
replacement pattern, and if it is used in conditional contexts in the match
pattern, could it be taught to handle this case too?  If yes, perhaps
just the first hunk could be usable for 8/9 backports (+ the testcases).

2020-02-15  Jakub Jelinek  

PR tree-optimization/93744
* match.pd (((m1 >/=/<= m2) * d -> (m1 >/=/<= m2) ? d : 0,
A - ((A - B) & -(C cmp D)) -> (C cmp D) ? B : A,
A + ((B - A) & -(C cmp D)) -> (C cmp D) ? B : A): For GENERIC, make
sure @2 in the first and @1 in the other patterns has no side-effects.

* gcc.c-torture/execute/pr93744-1.c: New test.
* gcc.c-torture/execute/pr93744-2.c: New test.
* gcc.c-torture/execute/pr93744-3.c: New test.

[Bug tree-optimization/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:498055331393d3c32fea5a6142c926b6a7700b8d

commit r9-8241-g498055331393d3c32fea5a6142c926b6a7700b8d
Author: Jakub Jelinek 
Date:   Sat Feb 15 12:53:44 2020 +0100

match.pd: Disallow side-effects in GENERIC for non-COND_EXPR to COND_EXPR
simplifications [PR93744]

As the following testcases show (the first one reported, last two
found by code inspection), we need to disallow side-effects
in simplifications that turn some unconditional expression into conditional
one.  From my little understanding of genmatch.c, it is able to
automatically disallow side effects if the same operand is used multiple
times in the match pattern, maybe if it is used multiple times in the
replacement pattern, and if it is used in conditional contexts in the match
pattern, could it be taught to handle this case too?  If yes, perhaps
just the first hunk could be usable for 8/9 backports (+ the testcases).

2020-02-15  Jakub Jelinek  

PR tree-optimization/93744
* match.pd (((m1 >/=/<= m2) * d -> (m1 >/=/<= m2) ? d : 0,
A - ((A - B) & -(C cmp D)) -> (C cmp D) ? B : A,
A + ((B - A) & -(C cmp D)) -> (C cmp D) ? B : A): For GENERIC, make
sure @2 in the first and @1 in the other patterns has no side-effects.

* gcc.c-torture/execute/pr93744-1.c: New test.
* gcc.c-torture/execute/pr93744-2.c: New test.
* gcc.c-torture/execute/pr93744-3.c: New test.

[Bug tree-optimization/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

--- Comment #8 from Jakub Jelinek  ---
As for the signed zeros, I can't really reproduce it.  Tried with:
__attribute__((noipa)) void
foo (int x)
{
  double a = 0.0;
  double b = -0.0;
  _Bool c = x > 0;
  _Bool d = x > 1;
  double e = c;
  double f = d;
  double g = e * a;
  double h = f * b;
  if (__builtin_copysign (1.0, g) != 1.0
  || __builtin_copysign (1.0, h) != -1.0)
__builtin_abort ();
}

int
main ()
{
  foo (0);
  return 0;
}

The thing is that convert in (convert (cmp $0 $1)) seems to match just
CASE_CONVERT:, but result of a comparison is always integral (or vector
integral) and so there would need to be a FLOAT_EXPR rather than
{NOP,CONVERT}_EXPR to convert it to floating point.
Allowing other comparisons or any boolean results is certainly reasonable, but
would be an enhancement request for GCC 11.

[Bug tree-optimization/93744] [8/9/10 Regression] Different results between gcc-9 and gcc-7

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93744

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:187dd955dbee3939c3a2ca7b6839e7f70125

commit r10-6646-g187dd955dbee3939c3a2ca7b6839e7f70125
Author: Jakub Jelinek 
Date:   Sat Feb 15 12:53:44 2020 +0100

match.pd: Disallow side-effects in GENERIC for non-COND_EXPR to COND_EXPR
simplifications [PR93744]

As the following testcases show (the first one reported, last two
found by code inspection), we need to disallow side-effects
in simplifications that turn some unconditional expression into conditional
one.  From my little understanding of genmatch.c, it is able to
automatically disallow side effects if the same operand is used multiple
times in the match pattern, maybe if it is used multiple times in the
replacement pattern, and if it is used in conditional contexts in the match
pattern, could it be taught to handle this case too?  If yes, perhaps
just the first hunk could be usable for 8/9 backports (+ the testcases).

2020-02-15  Jakub Jelinek  

PR tree-optimization/93744
* match.pd (((m1 >/=/<= m2) * d -> (m1 >/=/<= m2) ? d : 0,
A - ((A - B) & -(C cmp D)) -> (C cmp D) ? B : A,
A + ((B - A) & -(C cmp D)) -> (C cmp D) ? B : A): For GENERIC, make
sure @2 in the first and @1 in the other patterns has no side-effects.

* gcc.c-torture/execute/pr93744-1.c: New test.
* gcc.c-torture/execute/pr93744-2.c: New test.
* gcc.c-torture/execute/pr93744-3.c: New test.

[Bug translation/93759] Invalid % in param

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759

--- Comment #1 from Andreas Schwab  ---
Apparently the problem is that "% p" looks like a valid c-format.

[Bug ipa/93760] wrong grammar in diagnostic

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93760

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-15
 Ever confirmed|0   |1

[Bug other/93756] typo: compatable

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93756

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-15
 Ever confirmed|0   |1

[Bug ipa/93760] wrong grammar in diagnostic

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93760

--- Comment #1 from Andrew Pinski  ---
Should be "while the other does not"

[Bug ipa/93760] New: wrong grammar in diagnostic

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93760

Bug ID: 93760
   Summary: wrong grammar in diagnostic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

From ipa-devirt.c:
> G_("one type needs to be constructed while other not"));

"while other not" is not correct English.

[Bug translation/93759] New: Invalid % in param

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93759

Bug ID: 93759
   Summary: Invalid % in param
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From params.opt:
> Set the estimated probability in percentage for builtin expect. The default 
> value is 90% probability.

This message is marked as c-format, which is wrong. If it were c-format, the %
would have to be written as %%.

[Bug middle-end/93747] straight quotes

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93747

Roland Illig  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #4 from Roland Illig  ---
(In reply to Andrew Pinski from comment #3)
> This is an build only sources.  Never installed or otherwise used.

Then why do I have to translate these strings? I'm assuming that all GCC
developers know a bit of English.

[Bug tree-optimization/93749] internal jargon in publicly visible diagnostic

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93749

--- Comment #3 from Roland Illig  ---
Even though the GCC warnings are suppressed, these strings still show up in the
translatable strings. In the German translation I'm just copying them 1:1,
since that makes sense to me.

I still don't understand why internal errors should be translated at all. See
Bug 80055.

[Bug target/93743] [9/10 Regression] swapped arguments in atan2l

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93743

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|uros at gcc dot gnu.org|
  Component|rtl-optimization|target
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |9.3

--- Comment #3 from Uroš Bizjak  ---
Fixing.

[Bug bootstrap/93758] New: Building x86_64-w64-mingw32-gcc (mingw-w64) on macOS Catalina results in "internal compiler error: Segmentation fault"

[mojca at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93758

Bug ID: 93758
   Summary: Building x86_64-w64-mingw32-gcc (mingw-w64) on macOS
Catalina results in "internal compiler error:
Segmentation fault"
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mojca at macports dot org
  Target Milestone: ---

See:
* https://trac.macports.org/ticket/60091
* https://ports.macports.org/port/i686-w64-mingw32-gcc-nothreads/builds

Since macOS Catalina (10.5) we are apparently no longer able to build
x86_64-w64-mingw32-gcc.

Bootstrapping (make all-gcc && make install-gcc) is performed with clang and
succeeds (but I'm not excluding the chance that there is a bug in the clang
compiler as shipped on Catalina; we had numerous issues which required using
-fno-stack-check).

libtool: compile:  /path/to/build/./gcc/xgcc -B/path/to/build/./gcc/
-L/opt/local/i686-w64-mingw32/lib -L/opt/local/mingw/lib -isystem
/opt/local/i686-w64-mingw32/include -isystem /opt/local/mingw/include
-B/opt/local/i686-w64-mingw32/bin/ -B/opt/local/i686-w64-mingw32/lib/ -isystem
/opt/local/i686-w64-mingw32/include -isystem
/opt/local/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I.
-I/path/to/gcc-9.2.0/libgfortran -iquote/path/to/gcc-9.2.0/libgfortran/io
-I/path/to/gcc-9.2.0/libgfortran/../gcc
-I/path/to/gcc-9.2.0/libgfortran/../gcc/config
-I/path/to/gcc-9.2.0/libgfortran/../libquadmath -I../.././gcc
-I/path/to/gcc-9.2.0/libgfortran/../libgcc -I../libgcc
-I/path/to/gcc-9.2.0/libgfortran/../libbacktrace -I../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules
-ffunction-sections -fdata-sections -g -O2 -MT norm2_r4.lo -MD -MP -MF
.deps/norm2_r4.Tpo -c /path/to/gcc-9.2.0/libgfortran/generated/norm2_r4.c 
-DDLL_EXPORT -DPIC -o .libs/norm2_r4.o
during GIMPLE pass: ccp
/path/to/gcc-9.2.0/libgfortran/generated/norm2_r4.c: In function ‘norm2_r4’:
/path/to/gcc-9.2.0/libgfortran/generated/norm2_r4.c:213:1: internal compiler
error: Segmentation fault: 11

[Bug gcov-profile/93757] New: [GCOV] incorrect coverage for inline function with "a?b:c" expression

[yangyibiao at hust dot edu.cn]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93757

Bug ID: 93757
   Summary: [GCOV] incorrect coverage for inline function with
"a?b:c" expression
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcov -v
gcov (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)

$ cat small.c
static unsigned int oq[10];

static struct us { unsigned int irq; } sp[10];

static __inline__ __attribute__((always_inline)) int bar(int irq)
{
  return ((irq == 2) ? 9 : irq);
}

int main(void)
{
  int i = 0;
  struct us *s = sp;

  for (; i < 10; i++, s++)
 s->irq = bar(oq[i]);

  return 0;
}

$ gcc -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:static unsigned int oq[10];
-:2:
-:3:static struct us { unsigned int irq; } sp[10];
-:4:
-:5:static __inline__ __attribute__((always_inline)) int bar(int irq)
-:6:{
10*:7:  return ((irq == 2) ? 9 : irq);
-:8:}
-:9:
1:   10:int main(void)
-:   11:{
1:   12:  int i = 0;
1:   13:  struct us *s = sp;
-:   14:  
11:   15:  for (; i < 10; i++, s++)
20:   16: s->irq = bar(oq[i]);
-:   17:
1:   18:  return 0;
-:   19:}


###
We can find that Line #16 is wrongly marked as executed 20 times. 
When inline attribute is removed for function 'bar', the coverage is correct.

[Bug other/93756] New: typo: compatable

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93756

Bug ID: 93756
   Summary: typo: compatable
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

Found in:
- gcc/config/rx/elf.opt
- libphobos/src/std/algorithm/iteration.d

[Bug bootstrap/78756] Missing prefix in the name of gfortran.info

[mojca at macports dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756

Mojca Miklavec  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Mojca Miklavec  ---
I didn't know I was able to close the ticket myself.

I'll mark it as invalid for now since we have a relatively simple workaround.

[Bug translation/93755] New: nested quotes in command line options errors

[roland.illig at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93755

Bug ID: 93755
   Summary: nested quotes in command line options errors
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From rs6000.c:
> error ("%qs requires VSX support", "%<-mfloat128%>");

The parameter does not need the % since it is already wrapped in %qs.

There is probably no automatic test case for this, as this would have been
obvious to see.

In general it might be a good idea during development to check whether the
parameters contain these quotes. But again, since there is no automatic test
for this combination of options, this bug would go unnoticed.

Another idea is to use a static analysis tool for this kind of bugs.

[Bug c++/93589] Template instantiation creates a conversion warning when it should not

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93589

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #6)
> Oops, I meant to say the warning was just suppressed for the += case, see PR
> 40752.

Rather, it was suppressed for the simple case where the RHS has a suitable
type.  As Jonathan says, (CHAR_BIT * static_cast(i)) has type int (it
would be unsigned without the cast).  And then the << expression has type int. 
And then the | expression has type int.

Before the patch for 40752, we would warn based just on the type of the |
expression.  Now we also look at the type of the << expression, see that it is
also int, and warn.  You can avoid the warning by breaking up the expression
more:

#define CHAR_BIT 8
void print_byte_order( short )
{
   short val = 0;
   unsigned i = 1;
   short pat1 = (CHAR_BIT * static_cast(i));
   short pat2 = pat1 << (CHAR_BIT * static_cast(i));
   val |= pat2;
}

or adding another cast as in comment #1.

Perhaps I should adjust the 40752 patch to work recursively.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565

--- Comment #23 from Andreas Schwab  ---
gcc.target/aarch64/pr93565.c fails with -mabi=ilp32.