[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-28 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059

--- Comment #12 from fdlbxtqi  ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> > std::copy_n(bits.begin(),bits.size(),out);
> > }
> > 
> > https://godbolt.org/z/_yA_Ls
> > See the assembly
> 
> Thanks, I just filed PR 93063 about a subpart that the compiler should be
> able to do without help from the library.

I think the implementation is still problematic since C++ 20 adds the
contiguous_iterator concept. The current implementation looks not to allow
custom 
 contiguous iterators types to be optimized as memmove.

It needs certain kinds of revamping IMO.

[Bug c/12245] [8/9/10 regression] Uses lots of memory when compiling large initialized arrays

2019-12-28 Thread phdofthehouse at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245

JeanHeyd Meneide  changed:

   What|Removed |Added

 CC||phdofthehouse at gmail dot com

--- Comment #75 from JeanHeyd Meneide  ---
I would like to add to this post. I experience severe memory usage and
compilation time consumption that ramps up heavily when dealing with binary
data. I documented much of my struggles here:

https://thephd.github.io/embed-the-details

I am being told that the functionality I am developing is more suited for a bug
report and that this should be compiler QoI. Upon attempting to file this bug,
I decided to throw my own data and woes into the ring here.

Is there a place I should start looking to help out with this? I would like to
start getting closer to the theoretical near-perfect overhead of dealing with
what essentially ends up being a large binary payload, without resorting to
#embed or any special builtins.

[Bug c++/93093] New: __builtin_source_location reports values for default arguments not aligned with the Standard

2019-12-28 Thread phdofthehouse at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093

Bug ID: 93093
   Summary: __builtin_source_location reports values for default
arguments not aligned with the Standard
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: phdofthehouse at gmail dot com
  Target Milestone: ---

Consider the following example from the C++ Standard N4842 (nice website
version: eel.is/c++draft/support.srcloc#cons-4):

===

struct s {
  source_location member = source_location::current();
  int other_member;
  s(source_location loc = source_location::current())
: member(loc) // values of member refer to the location of the
calling function ([dcl.fct.default])
  {}
  s(int blather) :// values of member refer to this location
other_member(blather)
  {}
  s(double)  // values of member refer to this location
  {}
};
void f(source_location a = source_location::current()) {
  source_location b = source_location::current();   // values in b refer to
this line
}

void g() {
  f();   // f's first argument corresponds to this line of code

  source_location c = source_location::current();
  f(c);  // f's first argument gets the same values as c, above
}

===

When source_location is implemented with __builtin_source_location, code like
the above does not report those locations. s{}.member does not refer to the
calling location, s(2.0).member does not refer to the constructor declaration
s, and s(1).member does not refer to that location, and so forth.

Some talking on IRC revealed that this might be because of constant evaluation
/ constant folding, changing how the source location attribute behaves in
instances like these. This also affects the patch at
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01579.html whose tests fail in
both static_assert and regular runtime VERIFYs.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2019-12-28 Thread euloanty at live dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059

--- Comment #11 from fdlbxtqi  ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> > std::copy_n(bits.begin(),bits.size(),out);
> > }
> > 
> > https://godbolt.org/z/_yA_Ls
> > See the assembly
> 
> Thanks, I just filed PR 93063 about a subpart that the compiler should be
> able to do without help from the library.

TBH. I would rather see the library does the optimization instead of the
compiler. I do not trust the compiler can always optimize this stuff.

Re: The gcc compiler detects functions in the C binary search program by default

2019-12-28 Thread caipenghui

Oh my god, this is a low-level mistake, not funny 8-0..


caipenghui

在 2019/12/29 10:50, Andrew Pinski 写道:

On Sat, Dec 28, 2019 at 6:31 PM caipenghui  wrote:

hello everyone,

I found that gcc version 9.2.1 20191008,

i to compiles a binary search algorithm program that I write that only
checks the function prototype,

but does not check the name after the definition?


bsearch is a standard C function.
https://pubs.opengroup.org/onlinepubs/009695399/functions/bsearch.html
http://www.cplusplus.com/reference/cstdlib/bsearch/

Thanks,
Andrew Pinski


/ * binary bearch * /
#include 
int bsearch(int x, int a[], int n);
int main(void)
{
  int a[] = {
  0, 555,
  3, 4, 5,
  6,
  };
  printf("%d\n", bsearch(0, a, sizeof a / sizeof a[0]));
  return 0;
}


int abasjkjkerch(int x, int
a[], int n)
{
  int low;
  int hig;
  int mid;

  low = 0;
  hig = n - 1;
  while (low <= hig) {
  mid = (low + hig) / 2;
  if (x < *(a + mid))
  hig = mid - 1;
  else if (x > *(a + mid))
  low = mid + 1;
  else
  return mid;
  }
  return -1;
}






Re: The gcc compiler detects functions in the C binary search program by default

2019-12-28 Thread Andrew Pinski
On Sat, Dec 28, 2019 at 6:31 PM caipenghui  wrote:
>
> hello everyone,
>
> I found that gcc version 9.2.1 20191008,
>
> i to compiles a binary search algorithm program that I write that only
> checks the function prototype,
>
> but does not check the name after the definition?
>

bsearch is a standard C function.
https://pubs.opengroup.org/onlinepubs/009695399/functions/bsearch.html
http://www.cplusplus.com/reference/cstdlib/bsearch/

Thanks,
Andrew Pinski

> / * binary bearch * /
> #include 
> int bsearch(int x, int a[], int n);
> int main(void)
> {
>  int a[] = {
>  0, 555,
>  3, 4, 5,
>  6,
>  };
>  printf("%d\n", bsearch(0, a, sizeof a / sizeof a[0]));
>  return 0;
> }
>
>
> int abasjkjkerch(int x, int
> a[], int n)
> {
>  int low;
>  int hig;
>  int mid;
>
>  low = 0;
>  hig = n - 1;
>  while (low <= hig) {
>  mid = (low + hig) / 2;
>  if (x < *(a + mid))
>  hig = mid - 1;
>  else if (x > *(a + mid))
>  low = mid + 1;
>  else
>  return mid;
>  }
>  return -1;
> }
>
>


The gcc compiler detects functions in the C binary search program by default

2019-12-28 Thread caipenghui

hello everyone,

I found that gcc version 9.2.1 20191008,

i to compiles a binary search algorithm program that I write that only 
checks the function prototype,


but does not check the name after the definition?

/ * binary bearch * /
#include 
int bsearch(int x, int a[], int n);
int main(void)
{
    int a[] = {
        0, 555,
        3, 4, 5,
        6,
    };
    printf("%d\n", bsearch(0, a, sizeof a / sizeof a[0]));
    return 0;
}


int abasjkjkerch(int x, int 
a[], int n)

{
    int low;
    int hig;
    int mid;

    low = 0;
    hig = n - 1;
    while (low <= hig) {
        mid = (low + hig) / 2;
        if (x < *(a + mid))
            hig = mid - 1;
        else if (x > *(a + mid))
            low = mid + 1;
        else
            return mid;
    }
    return -1;
}




[Bug c++/93092] New: g++ takes tremendous compilation times

2019-12-28 Thread ad...@tho-otto.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092

Bug ID: 93092
   Summary: g++ takes tremendous compilation times
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ad...@tho-otto.de
  Target Milestone: ---

Created attachment 47558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47558&action=edit
preprocessed version of nfosmesa_init.cpp

When compiling the attached, preprocessed file with -O2 (or above), and
generating debug information, cc1plus takes incredible compilation times (>5min
on a 4GHz Intel i7), and also uses incredible amounts of memory (> 16GB).

The attached file is a preprocessed version of a source file from the ARAnyM
project, and the original file contains just a single function.

Tried on openSUSE Tumbleweed:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--enable-plugin --with-bugurl=https://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux)

[Bug other/93090] RFE: Add a frontend for the Rust programming language

2019-12-28 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090

--- Comment #2 from John Paul Adrian Glaubitz  ---
(In reply to Jakub Jelinek from comment #1)
> The Go FE actually isn't that independent, the same gofrontend is used by
> both GCC and LLVM, the same FE written in C++ in that case has then a
> compiler dependent layer for GCC and another one for LLVM.

Right. I think this argument was partially true though for earlier
implementations of the Go frontend in GCC, wasn't it?

> So, is for the bountysource another interface for the rustc FE ok, or are
> you looking for completely independent FE implementation?

I'm fine with either way actually. My main motivation is to have a Rust
compiler that supports more architectures than the one currently developed by
the Rust develeopers.

> And even if yes, can e.g. the runtime library be shared with rustc,
> or does it need to be independent?

If I understand the approach by "sapir" correctly, this is actually what's
being worked on in his gcc-rust frontend:

> https://github.com/sapir/gcc-rust/tree/rust

> Again, talking about Go, I think the go runtime is shared by all of goland,
> gcc-go and gollvm.

Which would be perfectly fine with me.

I didn't want to leave the impression that a completely independent
implementation would be necessary. I just mentioned it because it was brought
up as one of the arguments for having a Rust frondend in GCC within the
community.

I think the approach by "sapir" is actually very promising as it should be able
to keep up with Rust upstream which is currently a rather fast moving target.

[Bug other/93090] RFE: Add a frontend for the Rust programming language

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The Go FE actually isn't that independent, the same gofrontend is used by both
GCC and LLVM, the same FE written in C++ in that case has then a compiler
dependent layer for GCC and another one for LLVM.
So, is for the bountysource another interface for the rustc FE ok, or are you
looking for completely independent FE implementation?  And even if yes, can
e.g. the runtime library be shared with rustc, or does it need to be
independent?
Again, talking about Go, I think the go runtime is shared by all of goland,
gcc-go and gollvm.

[Bug libfortran/93091] New: Apparent bugs in "sizeof" and "transfer" intrinsic functions

2019-12-28 Thread thfanning at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93091

Bug ID: 93091
   Summary: Apparent bugs in "sizeof" and "transfer" intrinsic
functions
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thfanning at gmail dot com
  Target Milestone: ---

Created attachment 47557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47557&action=edit
Code to demonstrate incorrect results.

When actual arguments are passed to a subroutine that accepts polymorphic dummy
arguments, the "sizeof" and "transfer" intrinsic functions can return strange
results. For example:

character(80) :: msg
print *, sizeof(msg) ! prints "80"
print *, size(transfer(msg,[0_c_int8_t]),kind=c_size_t) ! prints "80"
call poly(msg) ! prints "1" and "1"

where

subroutine poly(obj)
class(*) :: obj
print *, sizeof(obj)
print *, size(transfer(obj,[0_c_int8_t]),kind=c_size_t)
end

Also,

integer :: iary(10)
print *, sizeof(iary) ! prints "40"
print *, size(transfer(iary,[0_c_int8_t]),kind=c_size_t) ! prints "40"
call poly1(iary) ! prints "40" and "80"

where

subroutine poly1(obj)
class(*) :: obj(:)
print *, sizeof(obj)
print *, size(transfer(obj,[0_c_int8_t]),kind=c_size_t)
end

See attached file for complete code that demonstrates these problems.

The documentation for "sizeof" states that "The argument shall be of any type,
rank or shape" and further, that "If the argument is polymorphic, the size
according to the dynamic type is returned." Similar statements apply to the
"transfer" intrinsic.

The size for assumed-shape dummy arguments should be known, but inconsistent
results occur as described above. Admittedly, the size for assumed-size dummy
arguments may not be known.

[Bug other/93090] New: RFE: Add a frontend for the Rust programming language

2019-12-28 Thread glaubitz at physik dot fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090

Bug ID: 93090
   Summary: RFE: Add a frontend for the Rust programming language
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
  Target Milestone: ---

This is a request for enhancement to add a frontend for the Rust programming
language to GCC.

Currently, there is only one official implementation of the Rust language which
is the rustc compiler developed by the Rust developers. The goal of this
enhancement request is to add a Rust frontend to GCC as an independent
implementation, analogue to the already existing Go frontend.

The benefits of having an independent implementation of the Rust language in
GCC is that it helps writing a formal specification for the Rust language which
doesn't exist yet as well as making the language available to a wider range of
architectures which are supported by GCC but not LLVM which is what Rust uses
as its backend.

There are currently two ongoing development projects working on such a Rust
frontend for GCC and either of them may be a potential candidate for this
request for enhancement:

> https://github.com/redbrain/gccrs
> https://github.com/sapir/gcc-rust/tree/rust

This bug report was created after a short discussion on the gcc-patches mailing
list with the intention to create a campaign on BountySource.com to help
stimulate the development with a financial incentive to anyone working on a
Rust frontend for GCC:

> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01568.html

I will be using this bug report to create a bounty on BountySource.com.

[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes

2019-12-28 Thread raj.khem at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

Khem Raj  changed:

   What|Removed |Added

 CC||raj.khem at gmail dot com

--- Comment #8 from Khem Raj  ---
with this patch I dont see the ICE I was seeing in quite a few qt apps as
reported in

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

[Bug c++/93036] [9/10 Regression] g++.dg/cpp2a/nontype-class27.C testcase accepted in -std=c++17 mode since r276248

2019-12-28 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93036

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-28
 Ever confirmed|0   |1

[Bug target/93089] New: Force mprefer-vector-width=512 in 'e' simd clones

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089

Bug ID: 93089
   Summary: Force mprefer-vector-width=512 in 'e' simd clones
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

The 'e' mangled simd clones that use 512-bit arguments/return value won't be
really called if the caller isn't preferring 512-bit vectors, so it seems much
better not to emit terrible code in those functions by trying to use only
256-bit vectors in there, which isn't fully possible anyway, as it needs to
extract the arguments from 512-bit vectors and store the result there too.
Unfortunately, we don't even allow prefer-vector-width= in target attribute.

[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069

--- Comment #3 from Jakub Jelinek  ---
Note, the above isn't the smallest possible fix, so perhaps for backporting
instead of the gcc/config/i386/ changes
--- gcc/config/i386/sse.md.jj   2019-12-27 18:16:48.146431083 +0100
+++ gcc/config/i386/sse.md  2019-12-28 16:54:09.536217497 +0100
@@ -8782,7 +8782,8 @@ (define_expand "avx_vextractf128"
 })

 (define_insn "vec_extract_lo_"
-  [(set (match_operand: 0 "nonimmediate_operand" "=v,v,m")
+  [(set (match_operand: 0 ""
+ "=v,v,")
(vec_select:
  (match_operand:V16FI 1 ""
 "v,,v")
@@ -8834,7 +8835,8 @@ (define_split
 })

 (define_insn "vec_extract_lo_"
-  [(set (match_operand: 0 "" "=v,v,m")
+  [(set (match_operand: 0 ""
+ "=v,v,")
(vec_select:
  (match_operand:VI8F_256 1 ""
"v,,v")
@@ -8844,7 +8846,7 @@ (define_insn "vec_extract_lo_ || !(MEM_P (operands[0]) && MEM_P (operands[1])))"
 {
   if ()
-return "vextract64x2\t{$0x0, %1, %0%{%3%}|%0%{%3%}, %1,
0x0}";
+return "vextract64x2\t{$0x0, %1,
%0|%0, %1, 0x0}";
   else
 return "#";
 }
might be better, i.e. insist on _maskm patterns for masked operations into
memory and force non-memory destination for the rest of vector extractions,
plus the %{%3%} instead of  I think can't work properly if zero
masking is needed into register destination.

[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47556&action=edit
gcc10-pr93069.patch

Untested fix.

[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

2019-12-28 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #4 from Martin Jambor  ---
I can't look into this now but couple of lines above there's an exit
intended to prevent this kind of situation (AFAIU from a quick look
now), just below the comment saying:

  /* If the lattice has already been propagated for the call site,
  no need to do that again.  */

Can you have a look why it does not trigger?  Thanks.

[Bug c++/93077] internal compiler error: in hash_operand during GIMPLE pass: fre

2019-12-28 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
(In reply to Jakub Jelinek from comment #1)
> I'm seeing a different ICE:
> pr93077.ii: In function ‘QVector itemVector()’:
> pr93077.ii:50312:36: error: incorrect sharing of tree nodes
> 50312 | static inline QVector itemVector()
>   |^~
> *D.122849
> D.122849->description = QCoreApplication::translate ("QtModulesInfo", "Core
> non-GUI classes used by other modules", 0B, -1); [return slot optimization]

Which probably makes it a duplicate of PR93033.

[Bug rtl-optimization/93088] New: [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp

2019-12-28 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088

Bug ID: 93088
   Summary: [10 Regression] Compile time hog on
gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3
-funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20191222 snapshot (r279712) takes inordinate time to compile
gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops
-fno-tree-dominator-opts -fno-tree-vrp:

% timeout 30 x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191222 -O3
-funroll-loops -fno-tree-dominator-opts -fno-tree-vrp -c pr56348.c
zsh: exit 124   timeout 30 x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191222
-O3-c

perf top shows only these two entries during the compilation:

Overhead  Sha  Symbol
  83.70%  cc1  [.] replace_single_def_regs
  16.30%  cc1  [.] find_reg_equal_equiv_note

[Bug c/93087] New: Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`

2019-12-28 Thread sagebar at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087

Bug ID: 93087
   Summary: Bogus `-Wsuggest-attribute=cold` on function already
marked as `__attribute__((cold))`
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

Created attachment 47555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47555&action=edit
Issue demonstration

Like the title implies, `-Wsuggest-attribute=cold` is emit for functions that
were already given the `__attribute__((cold))` annotation
The attached file demonstrates the issue, and should be compiled as:
```
gcc -c -O* attached-file.c
```
Where `*` can be any one of `` (empty), `1-3` (though not `0`), `g`, `s`,
`fast`
Note that the issue doesn't arise when no `-O*` flag is given at all (or when
`-O0` is given)

[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Indeed, if the destination is memory, {z} is not allowed.

[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org
   Target Milestone|--- |8.4

--- Comment #2 from Jakub Jelinek  ---
Started with r267665 aka PR88720 and PR88726 fix.

[Bug bootstrap/93074] [10 regression] build FAIL with --enable-offload-targets=nvptx-none

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #6 from Jakub Jelinek  ---
Should be fixed now.

[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token

2019-12-28 Thread sch...@linux-m68k.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066

--- Comment #3 from Andreas Schwab  ---
Or use (uintptr_t)-1 instead.

[Bug bootstrap/93074] [10 regression] build FAIL with --enable-offload-targets=nvptx-none

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec 28 09:26:03 2019
New Revision: 279747

URL: https://gcc.gnu.org/viewcvs?rev=279747&root=gcc&view=rev
Log:
PR bootstrap/93074
* plugin/cuda/cuda.h (cuDeviceGetName, cuDriverGetVersion): Declare.
(cuDeviceTotalMem, cuMemGetInfo): Likewise.  Define to *_v2.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/plugin/cuda/cuda.h

[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token

2019-12-28 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066

--- Comment #2 from Jakub Jelinek  ---
(In reply to dave.anglin from comment #1)
> Including stdint.h after inttypes.h would avoid the problem

That would be quite difficult, as stdint.h is included by libgomp.h that needs
to be included first.
An easier workaround might be not to use the UINTPTR_MAX macro at all, I think
we can rely on uintptr_t being unsigned integral type and so instead of
  if (n->aux->attach_count[idx] < UINTPTR_MAX)
we could use
  if (n->aux->attach_count[idx] + 1 != 0)