[Bug tree-optimization/98464] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nop_conversion_p, at tree.c:12825 by r11-4637

[linkw at gcc dot gnu.org via Gcc-bugs]

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

Kewen Lin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Kewen Lin  ---
My commit exposed one issue in FRE. The reason why the ICE occurs is that one
SSA_NAME used in loop's nb_iterations is actually in free list.

(unsigned long) _54 - (unsigned long) v$ptr__25

arg:0 
nothrow
def_stmt
version:54 in-free-list>>

I noticed that FRE already has some codes to handle loop's nb_iterations, but
there are some inconsistence which cause FRE unable to replace the one in
loop's nb_iterations but later replace all uses of _54.

When FRE is processing BB 19, it's able to replace _54 with _53 like:

   [local count: 789698041]:
  ...
  if (_26 != v$D4172$_M_impl$D4082$_M_finish$ptr__54)
goto ; [89.00%]

=>

   [local count: 789698041]:
  ...
  if (_26 != __new_finish$ptr__53)
goto ; [89.00%]

since it calls eliminate_stmt which works with def_bb instead of current bb:

sprime = eliminate_avail (gimple_bb (SSA_NAME_DEF_STMT (use)), use)

while rpo_vn_valueize only works with vn_context_bb.

For this particular case, _54's def_bb is BB 13, _53's def_bb is BB 11, it's ok
for dominated_by_p_w_unex check. While vn_context_bb is BB 19,
dominated_by_p_w_unex check returns false for it.

[Bug fortran/98476] OpenMP offload syntax restriction

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The error is correct for OpenMP 4.5, !$omp target data there has the
restriction:
At least one map clause must appear on the directive.
and OpenMP 4.5 is what GCC 10 implements in Fortran mostly.
OpenMP 5.0 and 5.1 changes that restriction to:
At least one map, use_device_addr or use_device_ptr clause must appear on the
directive.
which is what you can see in the C and C++ FEs.
GCC 11 is going to implement the 5.0 behavior here even in Fortran.

[Bug fortran/98476] New: OpenMP offload syntax restriction

[xw111luoye at gmail dot com via Gcc-bugs]

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

Bug ID: 98476
   Summary: OpenMP offload syntax restriction
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xw111luoye at gmail dot com
  Target Milestone: ---

C version code works. The corresponding Fortran version is blocked by the
compiler errror.

C version:
#include 

int main()
{
  int a[1];
  int* b = a;
  a[0] = 0;
  #pragma omp target enter data map(to:b[:1])
  #pragma omp target data use_device_ptr(b)
  {
#pragma omp target is_device_ptr(b)
{
  b[0] = 1;
}
  }
  printf("value before exit data %d\n", b[0]);
  #pragma omp target exit data map(from:b[:1])
  printf("value after exit data %d\n", b[0]);
  return 0;
}


Fortran version, XL fortran compiler works with this case.
program abc
  implicit none
  integer a

  a = 0
  call test(a)

contains
  subroutine test(a)
implicit none
integer a

  !$omp target enter data map(to:a)
  !$omp target data use_device_ptr(a)
  ! Error: TARGET DATA must contain at least one MAP clause at (1)
  ! after adding map(to: a), the second printout is still wrong.
  !$omp target is_device_ptr(a)
a = 1
  !$omp end target
  !$omp end target data
  write(6,*) "before exit data a = ", a
  !$omp target exit data map(from:a)
  write(6,*) "after exit data a = ", a

  endsubroutine
end program

Re: [RFC] [avr] Toolchain Integration for Testsuite Execution (avr cc0 to mode_cc0 conversion)

[Jeff Law via Gcc-patches]

On 12/23/20 9:01 AM, abebeos wrote:
>
>
> On Sun, 13 Dec 2020 at 20:14, abebeos  +abeb...@gmail.com >
> wrote:
>
>
>
> On Fri, 11 Dec 2020 at 20:32, Jeff Law  > wrote:
>
>
>
> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> 
> >
> > works fine.
> >
> > The problem with the avr target is that the testsuite cannot
> be run easily,
> > mainly because of the need for a special simulated-target
> setup, which does
> > not work for avr as documented. This led developers to a
> dead-end with
> > their non-cc0-avr-backends (the non-cc0 backend is needed
> thus avr is not
> > dropped from gcc11).
> >
> > I integrated a toolchain/testsetup to be able to run the gcc
> testsuite
> > against a simulated avr target.
> >
> > I then used this toolchain to test 2 different existent
> > non-cc0-avr-backends (from pipcet and saaadhu, both github).
> >
> > The result is that saaadhu's backend seems to be working
> 100%. It has
> > identical testsuite results with the existing (but
> deprecated) cc0-backend,
> > which means that it can be used "as-is" for inclusion in gcc11.
> >
> > Please note that I did this work in context of a bounty @
> bountysouce, more
> > information within the issue:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35
> 
> I haven't looked at the github repo.  But I do have a couple
> comments here.
>
> First, the author of the changes (pipcet and saaadhu) need to have
> copyright assignments on file with the FSF.  Otherwise we can
> not use
> their work at all.
>
> Second, the work needs to be submitted for inclusion.  I don't
> recall
> seeing an official submission from either of them to gcc-patches.
>
> I'm definitely curious about the testing setup and whether or
> not it can
> be replicated into our Jenkins setup.  
>
>
> Where can I find this Jenkins setup?
>
>
> To close this: assuming " into our Jenkins setup" is some redhat
> internal jenkins setup.
No, it's public.

http://gcc.gnu.org/jenkins

jeff

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[law at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Jeffrey A. Law  ---
So if that bisection is accurate, the only way this could be failing would be
if something with a deprecated attribute is being used.

Maybe some printfs in warn_deprecated_use?  But again, I'm a bit surprised by
the bisection results.

http://3.14.90.209:8080/job/m68k-linux-gnu/

Has the most recent build results from my tester.  As you can see everything
built and regression tested on Dec 9.  Dec 15 had a successful bootstrap, but
glibc failed due to a relatively minor bug in glibc.

[Bug target/98461] Suboptimal codegen for negating a movemask

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 49854 [details]
> gcc11-pr98461.patch
> 
> Untested fix.

+  if (GET_MODE_NUNITS (mode) == 32)

Yes, and i missed this part.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #6 from Steve Kargl  ---
On Wed, Dec 30, 2020 at 12:52:03AM +, xiao@compiler-dev.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98458
> 
> --- Comment #5 from xiao@compiler-dev.com  ---
> (In reply to Paul Thomas from comment #4)
> > Created attachment 49856 [details]
> > Fix for the PR
> > 
> > Thank you for the report on this problem.
> > 
> > The attached patch fixes the problem and regression tests OK. I need to do a
> > bit more thinking about it because I was unable to find a point in general
> > expression simplification where the fix could be applied. Instead, it only
> > seems to work in the simplification of intrinsic functions. Fortunately,
> > this seems to be the only place where it is needed.
> > 
> > Paul
> 
> As a beginner of FORTRAN, I am not sure about the result of implied do-loop
> which contains array section, so add "print" to check. Thanks for your
> attention on this problem.
> 

PRINT has nothing to do with the problem.  I simply
have no interest in fixing the changed and now misleading
subject line.  I've been asked to stop.

My proposed patch fixes the issue in one spot.  Paul's
patch fixes potentially many spots.  Unfortunately, the
handling of implied do-loops is done in an ad hoc fashion,
and is complicated by the potential problem of exhausting
the stack.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

[xiao.liu--- via Gcc-bugs]

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

--- Comment #5 from xiao@compiler-dev.com  ---
(In reply to Paul Thomas from comment #4)
> Created attachment 49856 [details]
> Fix for the PR
> 
> Thank you for the report on this problem.
> 
> The attached patch fixes the problem and regression tests OK. I need to do a
> bit more thinking about it because I was unable to find a point in general
> expression simplification where the fix could be applied. Instead, it only
> seems to work in the simplification of intrinsic functions. Fortunately,
> this seems to be the only place where it is needed.
> 
> Paul

As a beginner of FORTRAN, I am not sure about the result of implied do-loop
which contains array section, so add "print" to check. Thanks for your
attention on this problem.

[Bug c++/98475] New: Class template argument deduction for alias templates fails

[kimhappy at hanyang dot ac.kr via Gcc-bugs]

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

Bug ID: 98475
   Summary: Class template argument deduction for alias templates
fails
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kimhappy at hanyang dot ac.kr
  Target Milestone: ---

Created attachment 49857
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49857=edit
Example case

[Environment]
OS: Arch Linux on Windows 10 x86_64
Kernel: 4.19.128-microsoft-standard

[Compile command]
g++ -std=c++20 -Wall -Wextra

[Output]
test.cpp: In function ‘int main()’:
test.cpp:15:21: internal compiler error: Segmentation fault
   15 | auto o1 = SSS(10);
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Output of g++ -v]
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.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 --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

[Description]
Class template argument deduction for alias templates fails with some cases. I
tested it in various environments, but the results were the same.
In example case that I attached, if I replace T3 with a non-template template
argument or remove the second constructor of SS, it compiles fine.

[Bug target/64243] Passing and returning structures with single member of floating type via SSE registers is wrong on Windows x86-64 ABI

[bart at bartjanssens dot org via Gcc-bugs]

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

Bart Janssens  changed:

   What|Removed |Added

 CC||bart at bartjanssens dot org

--- Comment #3 from Bart Janssens  ---
We are still having this issue, it now manifests in cross-compiled binaries
used in the Julia ecosystem, see:
https://github.com/JuliaPackaging/BinaryBuilder.jl/issues/315

Re: [committed] doc: Remove HSAIL from Language Standards

[Gerald Pfeifer]

On Tue, 29 Dec 2020, Martin Jambor wrote:
>> commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48
>> Author: Gerald Pfeifer 
>> Date:   Mon Dec 28 21:41:55 2020 +0100
>>
>> doc: Remove HSAIL from Language Standards
>> 
>> Support for HSAIL has been deprecated with GCC 10 and their web server
>> has been down for weeks.

Please note the above.

> The HSAIL/BRIG consuming front-end has not been removed, as opposed to
> the HSAIL/BRIG emitting back-end which was, and is still part of the
> compiler, so this should not have been applied, I'm afraid.

This section in the documentation is about language standards and
reference to those standards.  hsafoundation.com literally has been
dead for a while, and there is not (evident) other location where
the standard appears vailable.

Also, wasn't the latest version 1.0.3 whereas our doc snippet still
referred to 1.0.1.

> Given the state of HSAIL, the front-end is probably not very useful
> either and so we may remove it in near term too, but it seems to still
> mostly work and causes no trouble, so at least for now it stayed.
> 
> Can you please revert this?

A simple revert does not appear appropriate, but if you have a strong
preference and see a benefit for our users, we surely can put something 
back in again.  

In that case, should the version updated to 1.0.3?  Apart from that 
and the defunct web site, what are other changes compared to the status 
pre commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48 ?

Can you propose some text / changes taking into account the deprecation
and related developments?  Can be rough, and I'll take care of the patch.

Gerald

Re: [committed] doc: Remove HSAIL from Language Standards

[Martin Jambor]

Hi Gerald,

On Mon, Dec 28 2020, Gerald Pfeifer wrote:
> Pushed.  
>
> There's quite a number of further references in gcc/doc; is anyone
> planning on continuing the deprecation and removing the actual bits?
>
> Gerald
>
>
> commit 7e999bd84f47205dc44b0f2dc90b53b3c888ca48
> Author: Gerald Pfeifer 
> Date:   Mon Dec 28 21:41:55 2020 +0100
>
> doc: Remove HSAIL from Language Standards
> 
> Support for HSAIL has been deprecated with GCC 10 and their web server
> has been down for weeks.
> 
> gcc/
> 2020-12-28  Gerald Pfeifer  
> 
> * doc/standards.texi (HSAIL): Remove section.
>

The HSAIL/BRIG consuming front-end has not been removed, as opposed to
the HSAIL/BRIG emitting back-end which was, and is still part of the
compiler, so this should not have been applied, I'm afraid.

Given the state of HSAIL, the front-end is probably not very useful
either and so we may remove it in near term too, but it seems to still
mostly work and causes no trouble, so at least for now it stayed.

Can you please revert this?

Thanks,

Martin


> diff --git a/gcc/doc/standards.texi b/gcc/doc/standards.texi
> index fc5016028dd..974f9b7e46d 100644
> --- a/gcc/doc/standards.texi
> +++ b/gcc/doc/standards.texi
> @@ -312,14 +312,6 @@ available online, see 
> @uref{http://gcc.gnu.org/readings.html}
>  As of the GCC 4.7.1 release, GCC supports the Go 1 language standard,
>  described at @uref{https://golang.org/doc/go1}.
>  
> -@section HSA Intermediate Language (HSAIL)
> -
> -GCC can compile the binary representation (BRIG) of the HSAIL text format as
> -described in HSA Programmer's Reference Manual version 1.0.1. This
> -capability is typically utilized to implement the HSA runtime API's HSAIL 
> -finalization extension for a gcc supported processor. HSA standards are
> -freely available at @uref{http://www.hsafoundation.com/standards/}.
> -
>  @section D language
>  
>  GCC supports the D 2.0 programming language.  The D language itself is

[Bug tree-optimization/98474] [8/9/10/11 Regression] incorrect results using __uint128_t

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-29
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED

[Bug tree-optimization/98474] [8/9/10/11 Regression] incorrect results using __uint128_t

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|incorrect results using |[8/9/10/11 Regression]
   |__uint128_t |incorrect results using
   ||__uint128_t
 CC||jakub at gcc dot gnu.org
  Component|c++ |tree-optimization
   Target Milestone|--- |8.5

--- Comment #2 from Jakub Jelinek  ---
Started with r5-424-g807e902eea17f3132488c256c963823976b2348c
C testcase that just needs -O2:
__attribute__ ((noipa)) void
foo (__uint128_t *x)
{
  asm volatile ("" : : "r" (x) : "memory");
}

int
main ()
{
  __uint128_t a = ((__uint128_t) 1) << 65;
  __uint128_t b = a;
  __uint128_t n;
  foo ();
  n = b;
  while (n >= a)
n -= a;
  if ((int) (n >> 64) != 0)
__builtin_abort ();
  return 0;
}

Works fine with unsigned long long instead of __uint128_t and 33 instead of 65
and 32 instead of 64, so either a wide-int bug or number of loop iterations
bug.
On the ullong testcase, e.g. profile_estimate prints:
Analyzing # of iterations of loop 1
  exit condition 8589934591 < [n_8, + , 18446744065119617024]
  bounds on difference of bases: -8589934591 ... 18446744065119617024
  result:
# of iterations n_8 / 8589934592, bounded by 2147483647
but on the uint128_t testcase it prints:
Analyzing # of iterations of loop 1
  exit condition 0x1 < [n_8, + ,
0xfffe]
  bounds on difference of bases: -36893488147419103231 ...
-18446744073709551616
  result:
# of iterations n_8 / 0x2, bounded by 0

[Bug c++/98474] incorrect results using __uint128_t

[jeffhurchalla at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Jeff Hurchalla  ---
If I change only the optimization level in the compile command to -O1, then
echo prints the correct result 0.

I have a non-minimal (but still very small) test file on godbolt at
https://godbolt.org/z/4oqnYn
The godbolt link goes to two separate tests which produce the incorrect results
- you can toggle between them with the "#if 1".

There are two interesting things about the godbolt tests:
1. I get correct results when I choose "x86_64 gcc 4.9.3" and incorrect results
when I choose "x86_64 gcc 5.1".  The few earlier versions than 4.9.3 that I
tried were correct also, and the few later versions than 5.1 (including trunk)
that I tried were incorrect also.
2. Using "x86_64 gcc 10.2" (and I'd suspect any version >= 5.1), the tests
print to stdout
"inside 'if'"
but they do not print
"inside 'while'"
This should be impossible.

[Bug c++/98474] New: incorrect results using __uint128_t

[jeffhurchalla at gmail dot com via Gcc-bugs]

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

Bug ID: 98474
   Summary: incorrect results using __uint128_t
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeffhurchalla at gmail dot com
  Target Milestone: ---

g++ version: g++-10 (Ubuntu 10.1.0-2ubuntu1~18.04) 10.1.0
x64 CPU: Intel(R) Core(TM) i5-4570S CPU @ 2.90GH

Compile command used:
g++-10 -O3 -std="gnu++11" -v -save-temps -fsanitize=undefined -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations test.cpp -o
testbug

It compiles cleanly for me, with no warnings or errors.  After compiling, I use
the following commands:
./testbug
echo $?

Echo prints 2 for me, but the result should be 0.
The preprocessed version of test.cpp is the same as the non-preprocessed
version.  It follows here:

__attribute__ ((noinline))
__uint128_t foo(__uint128_t& x)
{
return x;
}

int main()
{
using T = __uint128_t;
T two65 = static_cast(1) << 65;
T two65_copy = two65;

foo(two65_copy);
T n = two65_copy;

while (n >= two65)
n -= two65;

return static_cast(n >> 64);
}

[Bug libstdc++/98466] Debug Mode iterators for unordered containers do not implement N3644

[fdumont at gcc dot gnu.org via Gcc-bugs]

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

François Dumont  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org
   Last reconfirmed||2020-12-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

Re: about -stdlib=libc++ toggle. what about recognize v1 as libc++ if libstdc++ is installed at the same location with libc++?

[Iain Sandoe]

unlvsur unlvsur  wrote:


<3E6B1CF4201340D8BCCB373AE127FCC7.png>

Sent from Mail for Windows 10


The -stdlib= option is an “enabling” change;

As things stand, the packaging of the libc++ headers (and libc++ itself)  
needs intervention by the distribution (e.g. to add a coroutine header or  
to install the library on linux).


I don’t think ‘automagical' adding of the option is appropriate (at least  
not yet).


Iain

[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and on 10- and 9-branches.

Due to a glitch in the commit message for master no automatic commit message
was attached to this PR.  This was manually corrected for the branches.

Thanks for the report!

[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

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

commit r9-9141-gfe37f4aac179e8a7489fa5492dd56dce95f094b2
Author: Harald Anlauf 
Date:   Fri Dec 25 15:40:39 2020 +0100

PR fortran/93685 - ICE in gfc_constructor_append_expr, at
fortran/constructor.c:135

Fix handling of F2018 enhancements to DATA statements that allows
initialization of pointer components to derived types, and adjust error
handling for the CHARACTER case.

gcc/fortran/ChangeLog:

* data.c (gfc_assign_data_value): Restrict use of
create_character_initializer to constant initializers.
* trans-expr.c (gfc_conv_initializer): Ensure that character
initializer is constant, otherwise fall through to get the same
error handling as for non-character cases.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr93685_1.f90: New test.
* gfortran.dg/pr93685_2.f90: New test.

(cherry picked from commit 6e36772ba6a8173318c173508bd3254e4140b726)

[Bug fortran/92736] [9 Regression] Error when using a variable from a module in a submodule and its parent module.

[mehdi.chinoune at hotmail dot com via Gcc-bugs]

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

--- Comment #9 from Chinoune  ---
Since no one is going to backport the fix, should we close it as "won't fix"?

Re: disable some aapcs/vfp*.c test if not arm_fp16_alternative_ok

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:47 PM, Alexandre Oliva  wrote:
> 
> The tests use -mfp16-format=alternative, and so should not be run
> if that option isn't supported.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: What is the type of vector signed + vector unsigned?

[Alexander Monakov via Gcc]

On Tue, 29 Dec 2020, Richard Biener via Gcc wrote:

> >I think clang follows gcc and uses the type of the first operand.
> 
> The desired behavior is the one that OpenCL specifies. If it is implementation
> defined we should document behavior. I agree symmetry is nice but eventually
> the current C behavior is what OpenCL specifies. 

Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the
opposite (the code would fail to compile):

6.2.1
Implicit Conversions

[...]

Implicit conversions between built-in vector data types are disallowed.

Alexander

Re: fix testsuite/g++.dg/init/new26.C for C++-14 and later

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:40 PM, Alexandre Oliva  wrote:
> 
> This test fails during the execution on VxWorks 7 when using
> C++-14 and C++-17.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: g++.dg/tls/pr79288.C: Skip on vxworks_kernel (TLS model not supported)

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:57 PM, Alexandre Oliva  wrote:
> 
> The only TLS model supported in VxWorks kernel mode is local-exec.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: compile gcc.target/arm/{pr78255-2.c, memset-inline-2.c} with -mno-long-calls

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:56 PM, Alexandre Oliva  wrote:
> 
> This change adds -mno-long-calls to the list of compiler options
> to make sure we generate short call code, allowing the assembly
> matching to pass.
> 
> This is added unconditionally to the dg-options (as opposed to using
> dg-additional-options) because this test is already specific to ARM
> targets, and -mno-long-calls is available on all ARM targets.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Fix testsuite/g++.old-deja/g++.mike/p658.C build failure on VxWorks RTP

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:45 PM, Alexandre Oliva  wrote:
> 
> The conflicting definition of OK is present in VxWorks RTP headers too.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Ok to stylize all the #undef in the same way.  This is one happens to use a 
slightly different stye then the others as I recall.

Re: Fix testsuite/g++.dg/opt/20050511-1.C compilation error on VxWorks 7

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:44 PM, Alexandre Oliva  wrote:
> 
> In VxWorks 7, UINT32 is defined in both modes, kernel and rtp.  Adjust
> the work around accordingly.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Fix testsuite/g++.dg/cpp1y/constexpr-66093.C execution failure...

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:44 PM, Alexandre Oliva  wrote:
> 
> The constexpr iteration dereferenced an array element past the end of
> the array.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

How about:

  a[i-1] = i;

instead?  This I think better matches the comment in the code, and preserves 
the expected output as well.

If you like that and that works, Ok for that version.

> from Jerome Lambourg 
> for  gcc/testsuite/ChangeLog
> 
>* g++.dg/cpp1y/constexpr-66093.C: Fix bounds issue.
> ---
> gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C 
> b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> index ad3169210d29a..3d742cfebd83d 100644
> --- a/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> +++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
> @@ -19,7 +19,7 @@ private:
> 
> constexpr A f() {
> A a{};
> -for (int i = 1; i <= n; i++) {
> +for (int i = 0; i < n; i++) {
> a[i] = i;
> }
> return a;

Re: What is the type of vector signed + vector unsigned?

[Richard Biener via Gcc]

On December 29, 2020 6:42:30 PM GMT+01:00, Marc Glisse  
wrote:
>On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:
>
>> Any thoughts on what f should return in the following testcase, given
>the
>> usual GNU behaviour of treating signed >> as arithmetic shift right?
>>
>>typedef int vs4 __attribute__((vector_size(16)));
>>typedef unsigned int vu4 __attribute__((vector_size(16)));
>>int
>>f (void)
>>{
>>  vs4 x = { -1, -1, -1, -1 };
>>  vu4 y = { 0, 0, 0, 0 };
>>  return ((x + y) >> 1)[0];
>>}
>>
>> The C frontend takes the type of x+y from the first operand, so x+y
>> is signed and f returns -1.
>
>Symmetry is an important property of addition in C/C++.
>
>> The C++ frontend applies similar rules to x+y as it would to scalars,
>> with unsigned T having a higher rank than signed T, so x+y is
>unsigned
>> and f returns 0x7fff.
>
>That looks like the most natural choice.
>
>> FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
>
>I think clang follows gcc and uses the type of the first operand.

The desired behavior is the one that OpenCL specifies. If it is implementation 
defined we should document behavior. I agree symmetry is nice but eventually 
the current C behavior is what OpenCL specifies. 

Richard. 

Re: Skip testsuite/g++.old-deja/g++.pt/const2.C on vxworks_kernel

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:43 PM, Alexandre Oliva  wrote:
> 
> Linking in vxworks kernel-mode is partial linking, so missing symbols
> are not detected.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Generally nicer to bunch all like ones ("partial link" for example) together.

Re: Remove VxWorks-specific test directives in g++.dg/warn/miss-format-1.C

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:42 PM, Alexandre Oliva  wrote:
> 
> These are no longer applicable.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Undefine ERROR in g++.dg/tree-ssa/copyprop.C

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:41 PM, Alexandre Oliva  wrote:
> 
> VxWorks headers define ERROR as a macro, which conflicts with the use
> in the test.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: skip testsuite/g++.dg/other/anon5.C on vxworks_kernel targets

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:40 PM, Alexandre Oliva  wrote:
> 
> The vxworks kernel-mode linking is partial linking, so it cannot
> detect missing symbols.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Re: Add conditions on VxWorks versions for gcc.dg/vxworks/initpri?.c

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:37 PM, Alexandre Oliva  wrote:
> 
> Adjust vxworks initpri expectations, given that vxworks7 has switched
> to .init_array.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

I suppose I should say that if the port maintainers want to chime in and 
recommend a different solution or have different idea on how to do things, I'd 
encourage them to chime in.  I'm kicking in only because no one else has yet, 
and thats roughly what I do.

Re: gcc.dg/intmax_t-1.c compiles without error on VxWorks 7 SR06x0

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:36 PM, Alexandre Oliva  wrote:
> 
> This test currently fails on VxWorks 7 SR06x0 targets when in kernel
> mode, because it expects a discrepancy between built-in and system
> intmax_t for all VxWorks targets when in kernel mode.  Fortunately,
> this has now been fixed when targetting VxWorks 7 SR06x0, so this
> commit adjusts the "dg-error" condition to exclude newer versions of
> VxWorks 7.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

fix includes or making the builtin agree with the system is a nicer longer term 
solution.

Re: Fix VxWorks xfail filters on pthread-init-?.c

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:34 PM, Alexandre Oliva  wrote:
> Match xfail on kernel instead of rtp mode.
> 
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?

Ok.

Longer term, would be nice to fix includes the relevant file to have the 
relevant definition.

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

[daniel.santos at pobox dot com via Gcc-bugs]

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

--- Comment #6 from Daniel Santos  ---
(In reply to Jonathan Wakely from comment #5)
> That's why you're asked to provide the output of 'gcc -v' by the
> instructions at https://gcc.gnu.org/bugs/ (because we can't guess that your
> 10.2.0 is different from ours).

You're correct; my apologies.  Sorry for the extra work!

Re: Add conditional include of vxWorks.h for kernel mode

[Mike Stump via Gcc-patches]

On Dec 22, 2020, at 1:14 PM, Alexandre Oliva  wrote:
> 
> In kernel mode, an application must include vxWorks.h before any other
> system header, this patch adds exactly that to the test that were
> failing due to a missing declaration that was found in vxWorks.h.

I'm inclined to rather have a -include vxWorks.h method where you figure out 
when this should be done and add it to the command line flags as necessary, 
that, or have the gcc includes mechanism automatically include the file itself 
when those conditions are present.  Although, yet more possibilities exist, 
like knowing what from that file is necessary, and builtinizing that content so 
that the tests pass anyway.

Thoughts?

[Bug libstdc++/98473] New: std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator

[b.stanimirov at abv dot bg via Gcc-bugs]

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

Bug ID: 98473
   Summary: std::vector::insert(pos, first, last) doesn't
compile for T which has a deleted assignment operator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.stanimirov at abv dot bg
  Target Milestone: ---

Create a class `X` which is copy-constructible but not copy-assignable

```
struct X {
X();
X(const X&);
X& operator=(const X&) = delete; // !!
X(X&&) noexcept;
X& operator=(X&&) noexcept;
int data = 54;
};
```

Have vectors of X `a` and `b`. Try to add all elements of b at the front of a:

```
void add_to_front(std::vector& a, const std::vector& b) {
a.insert(a.begin(), b.begin(), b.end());
}
```

Live demo: https://godbolt.org/z/K1WT8n

It doesn't compile. My guess is that code which will never get invoked, still
needs to compile (or, worse yet, copy assignment does get invoked?!)

The only way to achieve the desired behavior efficiently is to use a custom
vector implementation. There is a stackoverflow question which has some
workarounds *with worse performance*:
https://stackoverflow.com/questions/65489039/how-to-efficiently-insert-multiple-copy-constructible-but-not-copy-assignable-el

This does compile and work on msvc, so a compile-time check for the
copy-assignment code is possible.

As pointed out in the stackoverflow thread, copy-assignability is not listed
here: https://en.cppreference.com/w/cpp/container/vector/insert#Parameters

This looks like a bug in libstdc++ (as opposed to a omission by the standard)

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

[Paul Richard Thomas via Gcc-patches]

Hi Thomas,

Thanks - applied to master in
r11-6365-geeb145317b42d5203056851435457d9189a7303d .

I wonder if this one deserves backporting?

Cheers

Paul




On Tue, 29 Dec 2020 at 09:06, Thomas Koenig  wrote:

>
> Hi Paul,
>
> > Regtests on FC33/x86_64 - OK for master?
>
> OK. Thanks for the patch!
>
> Best regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

[Bug fortran/97612] [F08] Structure constructor of type with nested allocatable array components fails to compile

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-6365-geeb145317b42d5203056851435457d9189a7303d
Author: Paul Thomas 
Date:   Tue Dec 29 17:44:48 2020 +

Fortran: Correct missing structure constructor comps. [PR97612].

2020-12-29  Paul Thomas  

gcc/fortran
PR fortran/97612
* primary.c (build_actual_constructor): Missing allocatable
components are set unallocated using EXPR_NULL. Then missing
components are tested for a default initializer.

gcc/testsuite/
PR fortran/97612
* gfortran.dg/structure_constructor_17.f90: New test.

Re: What is the type of vector signed + vector unsigned?

[Marc Glisse]

On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:


Any thoughts on what f should return in the following testcase, given the
usual GNU behaviour of treating signed >> as arithmetic shift right?

   typedef int vs4 __attribute__((vector_size(16)));
   typedef unsigned int vu4 __attribute__((vector_size(16)));
   int
   f (void)
   {
 vs4 x = { -1, -1, -1, -1 };
 vu4 y = { 0, 0, 0, 0 };
 return ((x + y) >> 1)[0];
   }

The C frontend takes the type of x+y from the first operand, so x+y
is signed and f returns -1.


Symmetry is an important property of addition in C/C++.


The C++ frontend applies similar rules to x+y as it would to scalars,
with unsigned T having a higher rank than signed T, so x+y is unsigned
and f returns 0x7fff.


That looks like the most natural choice.


FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.


I think clang follows gcc and uses the type of the first operand.

--
Marc Glisse

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[Paul Richard Thomas via Gcc-patches]

Hi Thomas,

Thanks for taking a look at the patch. Applied to master as
r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7 .

The branches will follow in a week or so.

Regards

Paul


On Mon, 28 Dec 2020 at 17:10, Thomas Koenig  wrote:

> Hi Paul,
>
> >>
> > Retested on FC33/x86_64 - OK for master, then 9&10 branches in a few
> weeks?
>
> OK.
>
> Thanks a lot for the patch!
>
> Best regards
>
> Thomas
>


-- 
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein

[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-6364-gfeae0af82753e06fbff6103da5fbb3b28e1ddbd7
Author: Paul Thomas 
Date:   Tue Dec 29 17:37:25 2020 +

Fortran: Fix deferred character lengths in array constructors [PR93833].

2020-12-29  Paul Thomas  

gcc/fortran
PR fortran/93833
* trans-array.c (get_array_ctor_var_strlen): If the character
length backend_decl cannot be found, convert the expression and
use the string length. Clear up some minor white space issues
in the rest of the file.

gcc/testsuite/
PR fortran/93833
* gfortran.dg/deferred_character_36.f90 : New test.

[Bug fortran/98458] PRINT the array constructed from implied do-loop throw ICE

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 CC||pault at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
Created attachment 49856
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49856=edit
Fix for the PR

Thank you for the report on this problem.

The attached patch fixes the problem and regression tests OK. I need to do a
bit more thinking about it because I was unable to find a point in general
expression simplification where the fix could be applied. Instead, it only
seems to work in the simplification of intrinsic functions. Fortunately, this
seems to be the only place where it is needed.

Paul

[Bug target/95361] Segfault when generating an epilogue for a partly-shrinked-wrapped SVE frame

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
The original testcase requires support for built-in SVE vector types,
which were only added in GCC 10.  I'm not planning to backport
further unless there's a different testcase that needs the
same fix.

What is the type of vector signed + vector unsigned?

[Richard Sandiford via Gcc]

Any thoughts on what f should return in the following testcase, given the
usual GNU behaviour of treating signed >> as arithmetic shift right?

typedef int vs4 __attribute__((vector_size(16)));
typedef unsigned int vu4 __attribute__((vector_size(16)));
int
f (void)
{
  vs4 x = { -1, -1, -1, -1 };
  vu4 y = { 0, 0, 0, 0 };
  return ((x + y) >> 1)[0];
}

The C frontend takes the type of x+y from the first operand, so x+y
is signed and f returns -1.

The C++ frontend applies similar rules to x+y as it would to scalars,
with unsigned T having a higher rank than signed T, so x+y is unsigned
and f returns 0x7fff.

FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.

[Was looking at this in the context of PR96377.]

Thanks,
Richard

[Bug tree-optimization/98467] gcc optimizes tapping code away

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
-fdelete-null-pointer-checks is generally an option that tells whether it is
possible to have objects at address 0 (-fno-delete-null-pointer-checks) or not.
So the use above seems to be correct.
Anything can happen on UB and NULL pointer dereference is UB, so I don't see
why you expect anything in particular.

[Bug fortran/98472] New: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352

[ruicoelhopedro at hotmail dot com via Gcc-bugs]

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

Bug ID: 98472
   Summary: internal compiler error: in gfc_conv_expr_descriptor,
at fortran/trans-array.c:7352
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ruicoelhopedro at hotmail dot com
  Target Milestone: ---

This occurs during an allocation whose source is the result of an elemental
function in a polymorphic class.
Tested in versions 7.5.0, 9.2.1 and 10.2.0, report below is shown for version
10.2.0




$ cat mwe.f90
module a
type, abstract :: base
contains
procedure(elem_func), deferred, nopass :: add
end type base

type, extends(base) :: derived
contains
procedure, nopass :: add => add_derived
end type derived

abstract interface
elemental function elem_func(x, y) result(out)
integer, intent(in) :: x, y
integer :: out
end function elem_func
end interface

contains
elemental function add_derived(x, y) result(out)
integer, intent(in) :: x, y
integer :: out
out = x + y
end function add_derived
end module a

program main
use a
integer, dimension(:), allocatable :: vec
class(base), allocatable :: instance
allocate(derived :: instance)
allocate(vec, source=instance%add([1, 2], [1, 2]))
end program main




$ gfortran mwe.f90
mwe.f90:32:0:

   32 | allocate(vec, source=instance%add([1, 2], [1, 2]))
  | 
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7352
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.




$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.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 --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

[Bug tree-optimization/98467] gcc optimizes tapping code away

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Bernd Edlinger  ---
I debugged a bit in when we decide this function is const.
That appears to be in gcc/ipa-fnsummary.c:

/* Return true if T is a pointer pointing to memory location that is local
   for the function (that means, dead after return) or read-only.  */

bool
points_to_local_or_readonly_memory_p (tree t)
{
  /* See if memory location is clearly invalid.  */
  if (integer_zerop (t))
return flag_delete_null_pointer_checks;
  if (TREE_CODE (t) == SSA_NAME)
return !ptr_deref_may_alias_global_p (t);
  if (TREE_CODE (t) == ADDR_EXPR)
return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
  return false;
}



And indeed the "problem" can be fixed by using -fno-delete-null-pointer-checks.
>From the documentation in gcc/doc/invoke.texi I would never have guessed
what this option does here:

"@item -fdelete-null-pointer-checks
@opindex fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that
no code or data element resides at address zero.
This option enables simple constant
folding optimizations at all optimization levels.  In addition, other
optimization passes in GCC use this flag to control global dataflow
analyses that eliminate useless checks for null pointers; these assume
that a memory access to address zero always results in a trap, so
that if a pointer is checked after it has already been dereferenced,
it cannot be null."


It is only supposed to remove checks for null-pointer, not the other
way round...

[Bug sanitizer/98206] UBSan: Casting from multiple inheritance base to derived class triggers undefined behavior sanitizer

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 49855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49855=edit
gcc11-pr98206.patch

Untested fix.

[Bug sanitizer/98206] UBSan: Casting from multiple inheritance base to derived class triggers undefined behavior sanitizer

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Jakub Jelinek  ---
Testcase without any headers:
template 
struct Base1
{
  char c1;
};

template 
struct Base2
{
  char c2;
  auto  () const { return static_cast (*this); }
};

struct X : public Base1, public Base2
{
  X (const char *d) : data{d} {}
  const char *data;
};

int
main ()
{
  X x = X{"cheesecake"};
  const char *p = x.get2 ().data;
}

The problem is that ubsan_maybe_instrument_reference is done only during
genericization, but we fold:
(const struct X &) ((const struct Base2 *) this + 18446744073709551615)
to
(const struct X &) this + 18446744073709551615
much earlier than that (during parsing even!), and if it wasn't during parsing,
it would be during fully folding of the function which is also before
genericization.
In fold-const.c, it is the:
  /* Convert (T1)(X p+ Y) into ((T1)X p+ Y), for pointer type, when the new
 cast (T1)X will fold away.  We assume that this happens when X itself
 is a cast.  */
  if (POINTER_TYPE_P (type)
  && TREE_CODE (arg0) == POINTER_PLUS_EXPR
  && CONVERT_EXPR_P (TREE_OPERAND (arg0, 0)))
{
  tree arg00 = TREE_OPERAND (arg0, 0);
  tree arg01 = TREE_OPERAND (arg0, 1);

  return fold_build_pointer_plus_loc
   (loc, fold_convert_loc (loc, type, arg00), arg01);
}
optimization that does that.
So, one way around this is for
!in_gimple_form && sanitize_flags_p (SANITIZE_ALIGNMENT)
to avoid the above optimization if type has higher alignment than the p+ first
operand's type.

[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720

[romain.geissler at amadeus dot com via Gcc-bugs]

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

--- Comment #3 from Romain Geissler  ---
Hi,

While I initially flagged this as a regression in gcc 11, it's indeed a latent
gcc bug which predates gcc 11. What makes it for my specific test case a
regression is because now tuple use [[no_unique_address]] which seems to be
already identified as creating ICEs in issues #96863 and #97804.

Cheers,
Romain

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

[gustavowalbon at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Gustavo Walbon  ---
Michael,

Works with GCC v10.
I backported this patch for the Alpine[1] gcc v10 and then I used the libgcc
package to test. I have used the binutils v2.35.1 with the warning of the GNU
Attribute and the patch doesn't show the warning.


1 -
https://github.com/walbon/aports/commit/f188c0b799df8550c595d6a94ffc6dab0254d11a

Thanks Michael

[Bug rtl-optimization/98289] [8/9/10 Regression] [x86] Suboptimal optimization of stack usage when function call does not occur

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] [x86]
   |[x86] Suboptimal|Suboptimal optimization of
   |optimization of stack usage |stack usage when function
   |when function call does not |call does not occur
   |occur   |
   Target Milestone|8.5 |11.0
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk, no plans to backport.

[Bug target/98461] Suboptimal codegen for negating a movemask

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Created attachment 49854
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49854=edit
gcc11-pr98461.patch

Untested fix.

[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until

[aoliva at gcc dot gnu.org via Gcc-bugs]

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #8 from Alexandre Oliva  ---
On arm-vxworks, that has 32-bit time_t, this also fails.  The initial
gthread_cond_timedwait sleeps for a second or two, then it times out and
returns.  However, the wider C++ types used in the
condition_variable::__wait_until_impl check for a timeout and decide we have
NOT timed out, so the __Predicate version of __wait_until sees the condition
it's waiting for hasn't been met, and attempts to wait again.  But since the
timeout has already been reached, gthread_cond_wait returns immediately, and we
busy-loop.  Since vxworks won't preempt threads, and we're not in a SMP
configuration, the async call never gets a chance to complete, and the test
runs till the rlimit runs out.

While investigating this, I noticed that adding __gthread_yield calls in the
__wait_until_impl loop, the other thread gets enough cycles to complete, and
the test passes, but I thought that would defeat the point of the test, right?

[Bug middle-end/56719] missed optimization: i > 0xffff || i*4 > 0xffff

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 49853
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49853=edit
gcc11-pr56719.patch

Untested patch to implement the #c8 optimization.

[committed 6/6] arc: generate mac(u) insn instead of macd(u) when destination is accl

[Claudiu Zissulescu via Gcc-patches]

Generate MAC(U) instruction instead of MACD(U) when the destination
register is already choosen as ACCL register.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.md (maddsidi4_split): Skip macd gen, use mac insn
instead.
(macd): Update register letters.
(umaddsidi4_split): Skip macdu gen, use macu insn instead.
(macdu): Update register letters.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.md | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index 75c32f6d3e9..b616c7fb82c 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -6176,12 +6176,14 @@ (define_insn_and_split "maddsidi4_split"
   "{
rtx acc_reg = gen_rtx_REG (DImode, ACC_REG_FIRST);
emit_move_insn (acc_reg, operands[3]);
-   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode))
- emit_insn (gen_macd (operands[0], operands[1], operands[2]));
+   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode)
+   && REGNO (operands[0]) != ACCL_REGNO)
+  emit_insn (gen_macd (operands[0], operands[1], operands[2]));
else
  {
   emit_insn (gen_mac (operands[1], operands[2]));
-  emit_move_insn (operands[0], acc_reg);
+  if (REGNO (operands[0]) != ACCL_REGNO)
+emit_move_insn (operands[0], acc_reg);
  }
DONE;
}"
@@ -6192,8 +6194,8 @@ (define_insn "macd"
   [(set (match_operand:DI 0 "even_register_operand"   "=Rcr,r,r")
(plus:DI
 (mult:DI
- (sign_extend:DI (match_operand:SI 1 "register_operand" "%0,c,c"))
- (sign_extend:DI (match_operand:SI 2 "extend_operand" " c,cI,Cal")))
+ (sign_extend:DI (match_operand:SI 1 "register_operand" "%0,r,r"))
+ (sign_extend:DI (match_operand:SI 2 "extend_operand""r,rI,Cal")))
 (reg:DI ARCV2_ACC)))
(set (reg:DI ARCV2_ACC)
(plus:DI
@@ -6276,12 +6278,14 @@ (define_insn_and_split "umaddsidi4_split"
   "{
rtx acc_reg = gen_rtx_REG (DImode, ACC_REG_FIRST);
emit_move_insn (acc_reg, operands[3]);
-   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode))
- emit_insn (gen_macdu (operands[0], operands[1], operands[2]));
+   if (TARGET_PLUS_MACD && even_register_operand (operands[0], DImode)
+   && REGNO (operands[0]) != ACCL_REGNO)
+  emit_insn (gen_macdu (operands[0], operands[1], operands[2]));
else
  {
   emit_insn (gen_macu (operands[1], operands[2]));
-  emit_move_insn (operands[0], acc_reg);
+  if (REGNO (operands[0]) != ACCL_REGNO)
+emit_move_insn (operands[0], acc_reg);
  }
DONE;
}"
@@ -6292,8 +6296,8 @@ (define_insn "macdu"
   [(set (match_operand:DI 0 "even_register_operand"   "=Rcr,r,r")
(plus:DI
 (mult:DI
- (zero_extend:DI (match_operand:SI 1 "register_operand" "%0,c,c"))
- (zero_extend:DI (match_operand:SI 2 "extend_operand" " c,cI,i")))
+ (zero_extend:DI (match_operand:SI 1 "register_operand" "%0,r,r"))
+ (zero_extend:DI (match_operand:SI 2 "extend_operand""r,rI,i")))
 (reg:DI ARCV2_ACC)))
(set (reg:DI ARCV2_ACC)
(plus:DI
-- 
2.26.2

[committed 5/6] arc: flip if-condition predicates in secondary reload hook

[Claudiu Zissulescu via Gcc-patches]

The ARC code contains code which should only work with the old reload
pass. Such code is found in arc_secondary_reload hook, however it was
not properly quarded. Reverse the if-condition predicate such that
req_equiv_mem is called when lra is not in progress.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.c (arc_secondary_reload): Flip if-condition
predicates.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index d0a52ee8b8d..fb672c75ff4 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -901,7 +901,7 @@ arc_secondary_reload (bool in_p,
 
  /* It is a pseudo that ends in a stack location.  This
 procedure only works with the old reload step.  */
- if (reg_equiv_mem (REGNO (x)) && !lra_in_progress)
+ if (!lra_in_progress && reg_equiv_mem (REGNO (x)))
{
  /* Get the equivalent address and check the range of the
 offset.  */
-- 
2.26.2

[committed 4/6] arc: Make use reg_renumber safe.

[Claudiu Zissulescu via Gcc-patches]

The REGNO_OK_FOR_BASE_P is using reg_renumber array. However, it is
not always defined. Use it only when it is defined.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.h (REGNO_OK_FOR_BASE_P): Check if defined
reg_renumber.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index fd6e21adfaa..c3886330f1b 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -588,7 +588,7 @@ extern enum reg_class arc_regno_reg_class[];
|| ((REGNO) == ARG_POINTER_REGNUM)  \
|| ((REGNO) == FRAME_POINTER_REGNUM)
\
|| ((REGNO) == PCL_REG) \
-   || ((unsigned) reg_renumber[REGNO] < 29)\
+   || (reg_renumber && ((unsigned) reg_renumber[REGNO] < 29))  \
|| ((unsigned) (REGNO) == (unsigned) arc_tp_regno)  \
|| (fixed_regs[REGNO] == 0 && IN_RANGE (REGNO, 32, 59)) \
|| (fixed_regs[REGNO] == 0 && (REGNO) == R30_REG))
-- 
2.26.2

[committed 3/6] arc: Update test pattern.

[Claudiu Zissulescu via Gcc-patches]

gcc/testsuite
2020-12-29  Claudiu Zissulescu  

* gcc.target/arc/loop-3.c: Update test pattern.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/testsuite/gcc.target/arc/loop-3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/arc/loop-3.c 
b/gcc/testsuite/gcc.target/arc/loop-3.c
index bf7aec94842..7f55e2f43fa 100644
--- a/gcc/testsuite/gcc.target/arc/loop-3.c
+++ b/gcc/testsuite/gcc.target/arc/loop-3.c
@@ -23,5 +23,5 @@ void fn1(void)
   }
 }
 
-/* { dg-final { scan-assembler "bne_s @.L2" } } */
+/* { dg-final { scan-assembler "bne.*@.L2" } } */
 /* { dg-final { scan-assembler-not "add.eq" } } */
-- 
2.26.2

[committed 2/6] arc: Fix cached to uncached moves.

[Claudiu Zissulescu via Gcc-patches]

We need an temporary register when moving data from a cached memory to
an uncached memory. Fix this issue and add a test for it.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.c (prepare_move_operands): Use a temporary
registers when we have cached mem-to-uncached mem moves.

gcc/testsuite/
2020-12-29  Claudiu Zissulescu  
Vladimir Isaev 

* cc.target/arc/uncached-9.c: New test.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.c  | 12 +--
 gcc/testsuite/gcc.target/arc/uncached-9.c | 39 +++
 2 files changed, 49 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/arc/uncached-9.c

diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 6a9e1fbf824..d0a52ee8b8d 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -9234,13 +9234,21 @@ prepare_move_operands (rtx *operands, machine_mode mode)
}
   if (arc_is_uncached_mem_p (operands[1]))
{
+ rtx tmp = operands[0];
+
  if (MEM_P (operands[0]))
-   operands[0] = force_reg (mode, operands[0]);
+   tmp = gen_reg_rtx (mode);
+
  emit_insn (gen_rtx_SET
-(operands[0],
+(tmp,
  gen_rtx_UNSPEC_VOLATILE
  (mode, gen_rtvec (1, operands[1]),
   VUNSPEC_ARC_LDDI)));
+ if (MEM_P (operands[0]))
+   {
+ operands[1] = tmp;
+ return false;
+   }
  return true;
}
 }
diff --git a/gcc/testsuite/gcc.target/arc/uncached-9.c 
b/gcc/testsuite/gcc.target/arc/uncached-9.c
new file mode 100644
index 000..4caba293bc5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arc/uncached-9.c
@@ -0,0 +1,39 @@
+/* { dg-do run } */
+/* { dg-options "-O2" } */
+
+#include 
+
+struct uncached_st
+{
+  int value;
+} __attribute__((uncached));
+
+struct cached_st
+{
+  int value;
+};
+
+struct uncached_st g_uncached_st =
+  {
+.value = 17
+  };
+
+struct cached_st g_cached_st =
+  {
+.value = 4
+  };
+
+void __attribute__((noinline)) test_struct_copy (void)
+{
+  g_cached_st.value = g_uncached_st.value;
+}
+
+int main (void)
+{
+  test_struct_copy();
+
+  if (g_cached_st.value != g_uncached_st.value)
+abort ();
+
+  return 0;
+}
-- 
2.26.2

[committed 1/6] arc: Don't use predicated vadd2 instructions in mov patterns.

[Claudiu Zissulescu via Gcc-patches]

Update movdi, movdf and mov vectors not to use predicated vadd2
instructions. vadd2 is used as a "fast" move in these patterns. This
fixes a number of failures in dejagnu.

gcc/
2020-12-29  Claudiu Zissulescu  

* config/arc/arc.md (movdi_insn): Update pattern, no predicated
vadd2 usage.
(movdf_insn): Likewise.
* config/arc/simdext.md (movVEC_insn): Likewise.

Signed-off-by: Claudiu Zissulescu 
---
 gcc/config/arc/arc.md | 6 +++---
 gcc/config/arc/simdext.md | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md
index ae08146bcaf..75c32f6d3e9 100644
--- a/gcc/config/arc/arc.md
+++ b/gcc/config/arc/arc.md
@@ -1341,7 +1341,7 @@ (define_insn_and_split "*movdi_insn"
 if (TARGET_PLUS_QMACW
&& even_register_operand (operands[0], DImode)
&& even_register_operand (operands[1], DImode))
-  return \"vadd2\\t%0,%1,0\";
+  return \"vadd2%?\\t%0,%1,0\";
 return \"#\";
 
 case 2:
@@ -1421,7 +1421,7 @@ (define_insn_and_split "*movdf_insn"
 if (TARGET_PLUS_QMACW
&& even_register_operand (operands[0], DFmode)
&& even_register_operand (operands[1], DFmode))
-  return \"vadd2\\t%0,%1,0\";
+  return \"vadd2%?\\t%0,%1,0\";
 return \"#\";
 
 case 4:
@@ -1450,7 +1450,7 @@ (define_insn_and_split "*movdf_insn"
DONE;
   }
   [(set_attr "type" "move,move,move,move,load,store")
-   (set_attr "predicable" "no,no,yes,yes,no,no")
+   (set_attr "predicable" "no,no,no,yes,no,no")
;; ??? The ld/st values could be 16 if it's [reg,bignum].
(set_attr "length" "4,16,8,16,16,16")])
 
diff --git a/gcc/config/arc/simdext.md b/gcc/config/arc/simdext.md
index d2fc309ea87..58651b5fcac 100644
--- a/gcc/config/arc/simdext.md
+++ b/gcc/config/arc/simdext.md
@@ -1413,7 +1413,7 @@ (define_insn_and_split "*mov_insn"
if (TARGET_PLUS_QMACW
&& even_register_operand (operands[0], mode)
   && even_register_operand (operands[1], mode))
- return \"vadd2\\t%0,%1,0\";
+ return \"vadd2%?\\t%0,%1,0\";
return \"#\";
 
  case 2:
@@ -1434,7 +1434,7 @@ (define_insn_and_split "*mov_insn"
DONE;
   }
   [(set_attr "type" "move,multi,load,store")
-   (set_attr "predicable" "yes,no,no,no")
+   (set_attr "predicable" "no,no,no,no")
(set_attr "iscompact"  "false,false,false,false")
])
 
-- 
2.26.2

[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #3 from martin  ---
Sorry for the noise, but as this gives big reductions in compilation time it is
quite important to me (and probably other big module based projects).

I just realised that I mixed up gfc_symtree->name and gfc_symtree->n.sym->name.
The reason why find_symbol traverses the whole tree in the worst case is that
it is ordered by gfc_symtree->name but it looks for gfc_symtree->n.sym->name.

So far I got the impression that either gfc_symtree->name is a unique name
("@xxx") or equal to gfc_symtree->n.sym->name (if n.sym!=NULL). In this case,
the following patch should do the trick and traverse only log(N) of the tree:

diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index 4c6ff22d5c1..8dc59e25d46 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -4659,10 +4659,20 @@ find_symbol (gfc_symtree *st, const char *name,
return st;
 }

+  c = strcmp (name, st->name);
+  if (c < 0)
+retval = find_symbol (st->left, name, module, generic);
+  else if (c > 0)
+retval = find_symbol (st->right, name, module, generic);
+  else
+retval = NULL;
+
+/* original traverse
   retval = find_symbol (st->left, name, module, generic);

   if (retval == NULL)
 retval = find_symbol (st->right, name, module, generic);
+*/

   return retval;
 }

[Bug target/97012] [SVE] Extend PR96357 to other aarch64-sve.md patterns

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Applied to GCC 10 as r10-9111.

[Bug target/95381] [11 Regression]: Bootstrap on m68k fails with ICE: in operator[], at vec.h:867

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #9 from John Paul Adrian Glaubitz  ---
I have bisected this now and it turns out, the regression was introduced by:

commit eede1a6bf3a4f33fa5afef9e4dfc80c4dd89eeb3
Author: Nick Clifton 
Date:   Mon Jun 18 10:39:01 2018 +

Ensure that control characters in user supplied error and warning messages
are escaped.

PR 84195
* tree.c (escaped_string): New class.  Converts an unescaped
string into its escaped equivalent.
(warn_deprecated_use): Use the new class to convert the
deprecation message, if present.
(test_escaped_strings): New self test.
(test_c_tests): Add test_escaped_strings.

From-SVN: r261697

Interestingly, later SVN/git revisions still built fine, with 20191130 being
the last good one:

> https://buildd.debian.org/status/logs.php?pkg=gcc-snapshot=m68k

I am building with the following command line:

../configure --with-gcc-major-version-only --program-prefix= --enable-shared
--enable-linker-build-id --disable-nls --enable-clocale=gnu
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libssp --disable-libitm
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --disable-libphobos --enable-objc-gc=auto
--enable-multiarch --disable-werror --disable-werror --disable-multilib
--enable-checking=yes --build=m68k-linux-gnu --host=m68k-linux-gnu
--target=m68k-linux-gnu --enable-languages=c++,jit --enable-host-shared
--disable-bootstrap && make -j64

from git. No local Debian patches applied.

My suspicion is that either this change triggers a bug in some external library
or a change in an external library made this bug visible.

Any suggestions? The only thing that it's odd on m68k is the 16-bit native
alignment, but I'm not sure whether that's relevant here.

Re: Add missing vxworks filters to lib/target-supports.exp functions

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> Explicitly disable some vxworks-missing features in the testsuite, that
> the current feature tests detect as present.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
>
>
> from Olivier Hainque 
> for  gcc/testsuite/ChangeLog
>
>   * lib/target-supports.exp (check_weak_available,
>   check_fork_available, check_effective_target_lto,
>   check_effective_target_mempcpy): Add vxworks filters.

This comes under Olivier's maintainership, but LGTM.

Richard

> ---
>  gcc/testsuite/lib/target-supports.exp |   21 +
>  1 file changed, 21 insertions(+)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 11343d0192fcb..6b1d13b105da7 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -326,6 +326,12 @@ proc check_weak_available { } {
>   return 0
>  }
>  
> +# VxWorks hardly supports it (vx7 RTPs only)
> +
> +if { [istarget *-*-vxworks*] } {
> + return 0
> +}
> +
>  # ELF and ECOFF support it. a.out does with gas/gld but may also with
>  # other linkers, so we should try it
>  
> @@ -2606,6 +2612,11 @@ proc check_function_available { function } {
>  # Returns true iff "fork" is available on the target system.
>  
>  proc check_fork_available {} {
> +if { [istarget *-*-vxworks*] } {
> + # VxWorks doesn't have fork but our way to test can't
> + # tell as we're doing partial links for kernel modules.
> + return 0
> + }
>  return [check_function_available "fork"]
>  }
>  
> @@ -9295,6 +9306,11 @@ proc check_effective_target_gld { } {
>  # (LTO) support.
>  
>  proc check_effective_target_lto { } {
> +if { [istarget *-*-vxworks*] } {
> + # No LTO on VxWorks, with kernel modules
> + # built with partial links
> + return 0
> +}
>  if { [istarget nvptx-*-*]
>|| [istarget amdgcn-*-*] } {
>   return 0;
> @@ -9514,6 +9530,11 @@ proc check_effective_target_run_expensive_tests { } {
>  # Returns 1 if "mempcpy" is available on the target system.
>  
>  proc check_effective_target_mempcpy {} {
> +if { [istarget *-*-vxworks*] } {
> + # VxWorks doesn't have mempcpy but our way to test fails
> + # to detect as we're doing partial links for kernel modules.
> + return 0
> + }
>  return [check_function_available "mempcpy"]
>  }

[Bug libstdc++/98471] libstdc++ fails to build with clang on windows because of filesystem bug

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target|mingw-w64-x86_64, windows   |mingw-w64-x86_64
   |10. clang12 |
   Host|mingw-w64-x86_64, windows   |
   |10. clang12 |
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-29
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

Version|10.2.0  |11.0
  Known to work|10.1.0  |10.2.0

--- Comment #5 from Jonathan Wakely  ---
That's why you're asked to provide the output of 'gcc -v' by the instructions
at https://gcc.gnu.org/bugs/ (because we can't guess that your 10.2.0 is
different from ours).

Re: -mno-long-calls for mve_libcall tests

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The implicit -mlong-calls used in our vxworks configurations changes
> the call sequences from those expected in the mve_libcall testcases.
>
> This patch brings the test output in line with the expectations, with
> an explicit -mno-long-calls.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/mve/intrinsics/mve_libcall1.c: Pass an
>   explicit -mno-long-calls.
>   * gcc.target/arm/mve/intrinsics/mve_libcall2.c: Likewise.
> ---
>  .../gcc.target/arm/mve/intrinsics/mve_libcall1.c   |2 +-
>  .../gcc.target/arm/mve/intrinsics/mve_libcall2.c   |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c 
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
> index 4fd422c6afe6a..222007f7ee21d 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall1.c
> @@ -1,6 +1,6 @@
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> {""} } */
> -/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto --save-temps" } */
> +/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto -mno-long-calls --save-temps" } */
>  
>  float
>  foo (float a, float b, float c)
> diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c 
> b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c
> index 3fd1329d384a9..42047a33fdfaa 100644
> --- a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c
> +++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_libcall2.c
> @@ -1,6 +1,6 @@
>  /* { dg-require-effective-target arm_v8_1m_mve_ok } */
>  /* { dg-skip-if "Incompatible float ABI" { *-*-* } { "-mfloat-abi=soft" } 
> {""} } */
> -/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto --save-temps" } */
> +/* { dg-additional-options "-march=armv8.1-m.main+mve -mfloat-abi=hard 
> -mthumb -mfpu=auto -mno-long-calls --save-temps" } */
>  
>  double
>  foo (double a, double b, double c)

Re: -mno-long-calls for arm/no_unique_address tests

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The implicit -mlong-calls from our vxworks configurations makes the
> tail-call instructions differ from those expected by the
> no_unique_address tests in gcc.target/arm.
>
> This patch adds -mno-long-calls to the compilation commands, so that
> we generate the expected sequences.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.  The dg-bogus parts shouldn't of course depend on -mlong-calls,
but they shouldn't depend on -O or -foptimize-sibling-calls either.
It seems unlikely that there is any hidden interaction between
-mlong-calls and no_unique_address, and if we find one later, we can
always add tests for it then.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/no_unique_address_1.C: Add -mno-long-calls.
>   * gcc.target/arm/no_unique_address_2.C: Likewise.
> ---
>  gcc/testsuite/g++.target/arm/no_unique_address_1.C |2 +-
>  gcc/testsuite/g++.target/arm/no_unique_address_2.C |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/g++.target/arm/no_unique_address_1.C 
> b/gcc/testsuite/g++.target/arm/no_unique_address_1.C
> index 038aa00a499e9..40fc68b374521 100644
> --- a/gcc/testsuite/g++.target/arm/no_unique_address_1.C
> +++ b/gcc/testsuite/g++.target/arm/no_unique_address_1.C
> @@ -1,5 +1,5 @@
>  /* { dg-require-effective-target arm_arch_v8a_hard_ok } */
> -/* { dg-options "-std=c++11 -O -foptimize-sibling-calls" } */
> +/* { dg-options "-std=c++11 -O -foptimize-sibling-calls -mno-long-calls" } */
>  /* { dg-add-options arm_arch_v8a_hard } */
>  /* { dg-final { check-function-bodies "**" "" "" } } */
>  
> diff --git a/gcc/testsuite/g++.target/arm/no_unique_address_2.C 
> b/gcc/testsuite/g++.target/arm/no_unique_address_2.C
> index 8be5de2539a38..b66b4d004965b 100644
> --- a/gcc/testsuite/g++.target/arm/no_unique_address_2.C
> +++ b/gcc/testsuite/g++.target/arm/no_unique_address_2.C
> @@ -1,5 +1,5 @@
>  /* { dg-require-effective-target arm_arch_v8a_hard_ok } */
> -/* { dg-options "-std=c++17 -O -foptimize-sibling-calls" } */
> +/* { dg-options "-std=c++17 -O -foptimize-sibling-calls -mno-long-calls" } */
>  /* { dg-add-options arm_arch_v8a_hard } */
>  /* { dg-final { check-function-bodies "**" "" "" } } */

Re: -mno-long-calls for arm/headmerge tests

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The headmerge tests pass a constant to conditional calls, so that the
> same constant is always passed to a function, though it's a different
> function depending on which path is taken.
>
> The test checks that the constant appears only once in the assembly
> output, as a means to verify that the insns setting up the argument
> are unified: they appear as separate insns up to jump2, where
> crossjump identifies a common prefix to all conditional paths and
> unifies them.
>
> Alas, with -mlong-calls, that we enable in our arm-vxworks
> configurations, the argument register is loaded after loading the
> callee address into another register.  Since each path calls a
> different function, there's no common initial code sequence for
> crossjump to unify, and the argument register set up remains separate,
> so the test fails.
>
> Though it would surely be desirable for the compiler to perform the
> unification of the argument register setting up, this patch merely
> avoids the effects of -mlong-calls, with an explicit -mno-long-calls.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/headmerge-1.c: Add -mno-long-calls.
>   * gcc.target/arm/headmerge-2.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/headmerge-1.c |2 +-
>  gcc/testsuite/gcc.target/arm/headmerge-2.c |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/headmerge-1.c 
> b/gcc/testsuite/gcc.target/arm/headmerge-1.c
> index 218c6a21ebd27..319ccd254626d 100644
> --- a/gcc/testsuite/gcc.target/arm/headmerge-1.c
> +++ b/gcc/testsuite/gcc.target/arm/headmerge-1.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile }  */
> -/* { dg-options "-O2" }  */
> +/* { dg-options "-O2 -mno-long-calls" }  */
>  /* { dg-final { scan-assembler-times "#120" 1 } } */
>  
>  extern void foo1 (int);
> diff --git a/gcc/testsuite/gcc.target/arm/headmerge-2.c 
> b/gcc/testsuite/gcc.target/arm/headmerge-2.c
> index 17d8e9365c52e..a015eb0f56905 100644
> --- a/gcc/testsuite/gcc.target/arm/headmerge-2.c
> +++ b/gcc/testsuite/gcc.target/arm/headmerge-2.c
> @@ -1,5 +1,5 @@
>  /* { dg-do compile }  */
> -/* { dg-options "-O2" }  */
> +/* { dg-options "-O2 -mno-long-calls" }  */
>  /* { dg-final { scan-assembler-times "120\n" 1 } } */
>  
>  extern void foo1 (int);

Re: -mno-long-calls for expected regalloc in arm/fp16-aapcs-2.c test

[Richard Sandiford via Gcc-patches]

Alexandre Oliva  writes:
> The implicit -mlong-calls used in our arm-vxworks configurations
> changes the register allocation patterns in the arm/fp16-aapcs-2.c
> test: r3 ends up used in the long-call sequence, and we end up using
> ip as a temporary, which doesn't match the expected mov patterns.
>
> This patch adds an explicit -mno-long-calls for the generated code to
> match the expectation.
>
> Regstrapped on x86_64-linux-gnu, also tested on arm-vxworks7r2.
> Ok to install?

OK, thanks.

Richard

> for  gcc/testsuite/ChangeLog
>
>   * gcc.target/arm/fp16-aapcs-2.c: Use -mno-long-calls.
> ---
>  gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c 
> b/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c
> index 51a76fc069353..c34387f57828d 100644
> --- a/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c
> +++ b/gcc/testsuite/gcc.target/arm/fp16-aapcs-2.c
> @@ -1,6 +1,6 @@
>  /* { dg-do compile }  */
>  /* { dg-require-effective-target arm_fp16_ok } */
> -/* { dg-options "-mfloat-abi=softfp -O2" }  */
> +/* { dg-options "-mfloat-abi=softfp -O2 -mno-long-calls" }  */
>  /* { dg-add-options arm_fp16_ieee } */
>  /* { dg-skip-if "incompatible float-abi" { arm*-*-* } { "-mfloat-abi=hard" } 
> } */

[Bug c++/98469] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6350

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-29

--- Comment #1 from Jakub Jelinek  ---
Created attachment 49852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49852=edit
gcc11-pr98469.patch

Untested fix.  Though, can't really reproduce with std::bit_cast, so the
validity of the testcase is questionable.

[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor

[bhavana.kilambi at blackfigtech dot com via Gcc-bugs]

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

--- Comment #12 from Bhavana Kilambi  
---
Created attachment 49851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49851=edit
a tweak to fix the issue

Hi Martin, My sincere apologies for the delay in replying and also for
uploading a faulty patch. I have attached another patch for this issue. It is
more of a tweak than a straight-forward approach to fixing the issue. 
Kindly let me know if this is ok or if any modifications are required. 
It has been tested for regressions on trunk and no failures have been found. 

Thanks

[Bug c++/98441] [11 Regression] member function pointer incorrectly parsed as having trailing return type

[daniel.santos at pobox dot com via Gcc-bugs]

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

--- Comment #4 from Daniel Santos  ---
Created attachment 49850
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49850=edit
Gentoo gcc 10.2.0-r2 patches

(In reply to Jonathan Wakely from comment #3)
> (In reply to Daniel Santos from comment #0)
> > However, it builds on GCC 9 and is alleged to build on MSVC.  The above
> > example is simplified from the original sources:
> 
> Are you sure this fails with 10.2.0? I only see it fail with 11.0 and not
> gcc version 10.2.1 20201125 (but I didn't try a newer build from the gcc-10
> branch).

Well, yes, but this is Gentoo gcc-10.2.0-r2, so includes a patchset (attached).
 In that, 34_all_fundecl-ICE-PR95820.patch contains the following:

It's an unofficial backport of PR95820 where gcc ICEs on
invalid syntax. As creduce frequently end up in these ICEs
as in #730406 let's backport it to gcc-10.

https://gcc.gnu.org/PR95820
https://bugs.gentoo.org/730406
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -12029,14 +12029,11 @@ grokdeclarator (const cp_declarator *declarator,

/* Handle a late-specified return type.  */
tree late_return_type = declarator->u.function.late_return_type;
-   if (funcdecl_p
-   /* This is the case e.g. for
-  using T = auto () -> int.  */
-   || inner_declarator == NULL)
+   if (true)
  {
if (tree auto_node = type_uses_auto (type))
  {
-   if (!late_return_type)
+   if (!late_return_type && funcdecl_p)
  {
if (current_class_type
&& LAMBDA_TYPE_P (current_class_type))

Re: [Patch, fortran] PR97612 [F08] Structure constructor of type with nested allocatable array components fails to compile

[Thomas Koenig via Gcc-patches]

Hi Paul,


Regtests on FC33/x86_64 - OK for master?


OK. Thanks for the patch!

Best regards

Thomas

[Bug c++/98461] Suboptimal codegen for negating a movemask

[denis.yaroshevskij at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Denis Yaroshevskiy  ---
(In reply to Hongtao.liu from comment #3)
> Could you mark this bug as blocks PR98375 

Done?

> ... waiting for Stage 1 of GCC 12 to be applied.)

So. the next gcc should have a fix? Fantastic! Will it also work for 128 bit
registers?

Re: Any possibility to support link with msvc stl just like clang??

[Jonathan Wakely via Gcc]

On Tue, 29 Dec 2020, 05:23 sotrdg sotrdg via Gcc,  wrote:

> That would be fun.
>

First you'd need to patch GCC to understand all the MSVC intrinsics or
patch MS STL to use GCC intrinsics.

Both are open source so it is probably possible, but you should be prepared
do the work yourself, since you're the one asking for it.

Most GCC developers have other priorities.

Re: More consistency for Git log messages?

[Jonathan Wakely via Gcc]

On Mon, 28 Dec 2020, 23:55 Gerald Pfeifer,  wrote:

> Having spent a bit more time with GCC sources (as opposed to wwwdocs)
> recently and looking for prior art to guide me, I noticed there's a
> lot of options to specific the ChangeLog file(s) to use.
>
> And correspondingly a lot of inconsistency.
>
> Right now we seem to allow for
>
>  1. gcc/cp/ChangeLog
>  2. gcc/cp/ChangeLog:
>  3. gcc/cp
>  4. gcc/cp:
>  5. gcc/cp/
>
> and probably more.
>

We also allow not specifying the directory at all, if it can be deduced
from the changed files.



> Can we streamline this a bit and converge on one of the forms 3-5?
>
> Personally I'd suggest 3 (the shortest) or 5 (the directory), but whatever
> ... as long as things become more consistent, which is easier on newbies
> and reading logs (or automatically processing them later on).
>

We already process them automatically.

It's worth noting that some people generate then automatically too, and the
mklog.py hook uses form 2 IIRC.

[Bug c++/98471] New: libstdc++ fails to build with clang on windows because of filesystem bug

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98471
   Summary: libstdc++ fails to build with clang on windows because
of filesystem bug
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 49849
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49849=edit
working patch to fix the issue

#include

int main()
{

}

D:\hg\fast_io\.tmp>clang++ -o filesystem filesystem.cc -Ofast -std=c++20 -s
In file included from filesystem.cc:1:
In file included from D:\msys64\mingw64\include\c++\11.0.0\filesystem:45:
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_path.h:252:15: error: invalid use
of incomplete type
  'std::filesystem::filesystem_error'
throw filesystem_error(
  ^
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_fwd.h:58:9: note: forward
declaration of
  'std::filesystem::filesystem_error'
  class filesystem_error;
^
In file included from filesystem.cc:1:
In file included from D:\msys64\mingw64\include\c++\11.0.0\filesystem:45:
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_path.h:252:9: error: cannot throw
object of incomplete type
  'std::filesystem::filesystem_error'
throw filesystem_error(
^ ~
D:\msys64\mingw64\include\c++\11.0.0\bits/fs_fwd.h:58:9: note: forward
declaration of
  'std::filesystem::filesystem_error'
  class filesystem_error;
^
2 errors generated.