https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
--- Comment #7 from Jonathan Wakely ---
(I think GCC is correct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
--- Comment #6 from Jonathan Wakely ---
Reduced:
struct coordinate_matrix {
using index_t = unsigned;
struct convert_to_matrix_coordinate {
index_t column_id;
};
index_t column_id;
// does not work
using value_type2 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
On 12/17/20 5:46 PM, Tom de Vries wrote:
> On 10/15/20 5:05 PM, Tom de Vries wrote:
>> On 10/2/20 3:21 PM, Tom de Vries wrote:
>>> Hi,
>>>
>>> Consider the test-case libgomp.c/pr81778.c added in this commit, with
>>> this core loop (note: CANARY_SIZE set to 0 for simplicity):
>>> ...
>>> int s =
Hi YiFei.
This is OK for both trunk and GCC 10.
Thanks for the fix!
[I see you don't have a copyright transfer contract in place. I believe
this change, and also the patch in 2/2, are small/trivial enough to not
require one, but if you plan to do more contributions in the future we
will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
To be more precise my gcc build is:
```
> gcc-git -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/gcc-git//bin/g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
--- Comment #2 from Alex Coplan ---
FWIW, the testcase starts ICEing with
r11-5171-g1d77928fc49b4f2487fd78db26bbebd00f881414 - I guess it's latent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100203
--- Comment #5 from Jonathan Wakely ---
Previoously reported upstream by Richi:
https://lists.gnu.org/archive/html/bug-dejagnu/2018-07/msg0.html
But apparently not actually fixed.
Christophe Lyon via Gcc-patches writes:
> On Wed, 21 Apr 2021 at 14:05, Richard Sandiford via Gcc-patches
> wrote:
>>
>> Alex Coplan writes:
>> > Hi Richard,
>> >
>> > On 15/04/2021 18:45, Richard Sandiford wrote:
>> >> Looks good in general, but like you say, it's GCC 12 material.
>> >
>> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
--- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Yeah, it compiled for me with a build from two weeks ago, too. I should have
mentioned that :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100206
Bug ID: 100206
Summary: aarch64: UB in varasm.c:output_object_block and
assembly failure
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
Richard Biener changed:
What|Removed |Added
Known to work||10.3.0
--- Comment #1 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100203
--- Comment #4 from Jonathan Wakely ---
Arguably the Bash builtin is behaving as documented. It doesn't mention any
support for process group IDs, and says it returns 0 if at least one signal was
sent, which is true because dejagnu is passing
On Thu, Apr 22, 2021 at 12:30 PM Jakub Jelinek via Gcc-patches
wrote:
>
> On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote:
> > How about this?
> >
> > @item general_regs_only
> > @cindex @code{general_regs_only} function attribute, x86
> > The @code{general_regs_only}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100203
--- Comment #3 from Jakub Jelinek ---
Note that bash documents its behavior:
'kill'
kill [-s SIGSPEC] [-n SIGNUM] [-SIGSPEC] JOBSPEC or PID
kill -l|-L [EXIT_STATUS]
Send a signal specified by SIGSPEC or SIGNUM to the
On Thu, Apr 22, 2021 at 11:02 AM Martin Liška wrote:
>
> On 4/22/21 10:04 AM, Richard Biener wrote:
> > On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
> >>
> >> When -flto=jobserver is used and we cannot detect job server, then we can
> >> still fallbackto -flto=N mode.
> >>
> >> Patch can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100203
--- Comment #2 from Jonathan Wakely ---
This seems to be a bug in the Bash 'kill' builtin.
#!/bin/bash
# pass /usr/bin/kill as $1 to use the command not the bash builtin
kill=${1:-kill}
sleep 60 &
pid1=$!
sleep 60 &
pid2=$!
sh -c "exec >
Alex Coplan writes:
> Hi,
>
> Here is a backport of my fix for PR99216. The only change w.r.t the
> original patch is a bump of lto-streamer.h:LTO_minor_version.
>
> Bootstrapped and regtested on aarch64-linux-gnu, no issues.
>
> OK for GCC 10 branch?
OK, thanks.
Richard
> As discussed in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100205
Bug ID: 100205
Summary: [11 Regression] error: invalid use of non-static data
member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100175
--- Comment #4 from Miklos Karacsony ---
I've tried to save it but every time I re-run the command it compiles without
an error. This ICE comes randomly, and when it does, I am unable to save the
relevant pre-processed source. I know this is
On 4/21/21 7:02 PM, Alexander Monakov wrote:
> On Wed, 21 Apr 2021, Tom de Vries wrote:
>
>>> I don't think implementing futex_wait is possible on nvptx.
>>>
>>
>> Well, I gave it a try, attached below. Can you explain why you think
>> it's not possible, or pinpoint a problem in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85608
Alex Coplan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100203
--- Comment #1 from Jakub Jelinek ---
The multiple pids in $pid is a result of standard_close, which does:
if {[board_info ${host} exists fileid_origid]} {
set oid [board_info ${host} fileid_origid]
set pid [pid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100204
Bug ID: 100204
Summary: aarch64: UB evaluating J constraint
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100203
Bug ID: 100203
Summary: Dejagnu timeouts don't work
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
On Thu, Apr 22, 2021 at 12:05 PM Hongtao Liu wrote:
>
> Hi:
> Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/100093
> * config/i386/i386-options.c (ix86_option_override_internal):
> Clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100202
Bug ID: 100202
Summary: aarch64: UB in insv expander
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100198
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100200
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100199
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin19.6.0 |x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100201
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Prior to this, a BSS declaration such as:
int foo;
static int bar;
Generates:
.global foo
.local foo
.comm foo,4,4
.local bar
.comm bar,4,4
Creating symbols:
b foo
0004 b bar
Both symbols are local. However, libbpf
Libbpf does not treat paddings after functions well. If function
symbols does not cover a whole text section, it will emit error
similar to:
libbpf: sec '.text': failed to find program symbol at offset 56
Each instruction in BPF is a multiple of 8 bytes, so align the
functions to 8 bytes,
Hi:
Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/100093
* config/i386/i386-options.c (ix86_option_override_internal):
Clear MASK_AVX256_SPLIT_UNALIGNED_LOAD/STORE in x_target_flags
when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100200
--- Comment #2 from Alex Coplan ---
Started with r10-3389-g835d50c66aa5bde2f354a6e63a2afa7d2f76a05a for the above
testcase. That commit just introduces a use of aarch64_plus_immediate. The
actual issue must be older.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100201
Martin Liška changed:
What|Removed |Added
Host||x86_64-linux-gnu
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100200
--- Comment #1 from Alex Coplan ---
Backtrace is:
#0 0x4340bc0 in aarch64_plus_immediate(rtx_def*, machine_mode)
/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/predicates.md:129
#1 0x2e0d168 in aarch64_rtx_costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100201
--- Comment #2 from Alex Coplan ---
(In reply to Martin Liška from comment #1)
> Can you please show back-trace (export UBSAN_OPTIONS="print_stacktrace=1")?
I didn't know ubsan did that, thanks! Here is the backtrace:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100201
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100159
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100192
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100201
Bug ID: 100201
Summary: Signed integer overflow in poly-int.h
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On 21/04/21 18:29 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
NOTE - This patch also needs to be backported to gcc-11 in order for
semaphore release() to work correctly on non-futex platforms.
Tested sparc-sun-solaris2.11
For types that track whether or not there extant waiters (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100199
Richard Biener changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100200
Bug ID: 100200
Summary: [10/11/12 Regression] UB evaluating
aarch64_plus_immediate predicate
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
The test did fail when the virtual memory already had a hard limit !=
unlimited.
Committed as r12-57-gfaf7d413a3f3337be1a3ac5cdf33e0e3b87b426e
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100196
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100195
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100193
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
On 4/22/21 10:04 AM, Richard Biener wrote:
> On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
>>
>> When -flto=jobserver is used and we cannot detect job server, then we can
>> still fallbackto -flto=N mode.
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>>
On Wed, Apr 21, 2021 at 06:01:07PM -0700, H.J. Lu via Gcc-patches wrote:
> How about this?
>
> @item general_regs_only
> @cindex @code{general_regs_only} function attribute, x86
> The @code{general_regs_only} function attribute informs the compiler
> that the function uses only general purpose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100199
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100199
Bug ID: 100199
Summary: gfortran.dg/pr68078.f90 FAILs spuriously with ulimit
in place
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
There's an updated version of the patch, Jonathan noticed correctly
the comment related to assert was not correct.
Martin
>From e035fd0549ea17ab4f8d71488f577fd1e4077fd9 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 12 Mar 2021 14:32:07 +0100
Subject: [PATCH] Use STATIC_ASSERT for
On Thu, 22 Apr 2021, 08:47 Martin Liška, wrote:
> On 4/21/21 6:11 PM, Martin Sebor wrote:
> > On 4/21/21 2:15 AM, Martin Liška wrote:
> >> Hello.
> >>
> >> It's addressing the following Clang warning:
> >> cp/lex.c:170:45: warning: result of comparison of constant 64 with
> expression of type
On Thu, Apr 22, 2021 at 4:29 AM Thomas Rodgers
wrote:
>
> From: Thomas Rodgers
>
> NOTE - This patch also needs to be backported to gcc-11 in order for
> semaphore release() to work correctly on non-futex platforms.
>
> Tested sparc-sun-solaris2.11
>
> For types that track whether or not there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100182
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
---
On Thu, Apr 22, 2021 at 3:01 AM H.J. Lu wrote:
>
> On Wed, Apr 21, 2021 at 4:24 PM Martin Sebor wrote:
> >
> > On 4/21/21 2:58 PM, H.J. Lu wrote:
> > > On Wed, Apr 21, 2021 at 10:09 AM Martin Sebor wrote:
> > >>
> > >> On 4/14/21 4:39 PM, H.J. Lu wrote:
> > >>> commit
On Thu, Apr 22, 2021 at 1:22 AM Maciej W. Rozycki wrote:
>
> Hi,
>
> According to the plan discussed in the context of the recent switch to
> MODE_CC of the VAX backend I have been looking into switching the backend
> to LRA as well.
>
> It has turned out quite straightforward itself, with just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100198
Bug ID: 100198
Summary: ICE: unexpected expression 'E' of kind
template_parm_index
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
On Wed, Apr 21, 2021 at 3:08 PM Martin Liška wrote:
>
> When -flto=jobserver is used and we cannot detect job server, then we can
> still fallbackto -flto=N mode.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
I think this behavior needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100176
--- Comment #9 from CVS Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:42f2d16e72f925263a27c8ac8231ad31d99517bf
commit r11-8279-g42f2d16e72f925263a27c8ac8231ad31d99517bf
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100176
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5668843346c74cabf830e46b45fad24db4566fd6
commit r12-56-g5668843346c74cabf830e46b45fad24db4566fd6
Author: Richard Biener
Date:
On Wed, 21 Apr 2021, Tobias Burnus wrote:
> This was brought up by Richard when testing libgomp with the GCC 11
> distribution
> compiler, which has both nvptx and gcn enabled – but no offloading device was
> available.
>
> This lead to fails for:
> *
On 4/21/21 6:11 PM, Martin Sebor wrote:
> On 4/21/21 2:15 AM, Martin Liška wrote:
>> Hello.
>>
>> It's addressing the following Clang warning:
>> cp/lex.c:170:45: warning: result of comparison of constant 64 with
>> expression of type 'enum ovl_op_code' is always true
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100191
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100188
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100196
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
--- Comment #4 from Iain Sandoe ---
(In reply to Ignacio Fernández Galván from comment #3)
> If it helps, this happens in gcc304 from
> https://cfarm.tetaneutral.net/machines/list/, but not in gcc80
gcc304 is the Apple M1 machine. The GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100193
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100185
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
--- Comment #3 from Ignacio Fernández Galván ---
If it helps, this happens in gcc304 from
https://cfarm.tetaneutral.net/machines/list/, but not in gcc80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183
Richard Biener changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
On Wed, 21 Apr 2021 at 14:05, Richard Sandiford via Gcc-patches
wrote:
>
> Alex Coplan writes:
> > Hi Richard,
> >
> > On 15/04/2021 18:45, Richard Sandiford wrote:
> >> Looks good in general, but like you say, it's GCC 12 material.
> >
> > Thanks for the review. The attached patch addresses
On 4/21/21 10:16 PM, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 08:53:54PM +0100, Jonathan Wakely wrote:
What would be IMHO a good idea would be to use configure test for
#include
int t = std::thread::hardware_concurrency ();
and in that case use that as a fallback to the
> Anyway, that's why we have a C++ ISO standard and so
> std::thread::hardware_concurrency function implementation can (and likely
> should) handle all this. Or?
This is a compiler though, i.e. quite low level in the software stack, so the
implementation must be conservative and thus fancy C++
On 4/21/21 9:53 PM, Jonathan Wakely wrote:
> On Wed, 21 Apr 2021 at 20:41, Martin Liška wrote:
>>
>> On 4/21/21 9:15 PM, Jakub Jelinek wrote:
>>> On Wed, Apr 21, 2021 at 08:28:55PM +0200, Jakub Jelinek via Gcc-patches
>>> wrote:
> There's a patch attempt for the problem with
>
> This patch broke bootstrap on AIX.
>
> std::thread is not provided in all instances. GCC is not compiled
> multi-threaded by default.
Right, this will very likely break on Windows too.
--
Eric Botcazou
arm.h has had this error message since 1997, and was never updated to
take softfp into account. Anyway, it seems it was useful long ago, but
it is no longer needed since option parsing has been improved:
-mfloat-abi is handled via arm.opt and updates the var_float_abi
variable. So, the last
On Thu, 22 Apr 2021, Bernd Edlinger wrote:
> Aehm,
>
> forgot to mention,
>
> tested on arm-none-eabi (arm-sim target)
> is it OK for trunk?
OK next week (when RC2 looks good).
Thanks,
Richard.
>
> Thanks
> Bernd.
>
> On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> > As the test case shows,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100175
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
Aehm,
forgot to mention,
tested on arm-none-eabi (arm-sim target)
is it OK for trunk?
Thanks
Bernd.
On 4/22/21 8:37 AM, Bernd Edlinger wrote:
> As the test case shows, the outer mode may have a higher alignment
> requirement than the inner mode here.
>
> 2021-04-22 Bernd Edlinger
>
>
As the test case shows, the outer mode may have a higher alignment
requirement than the inner mode here.
2021-04-22 Bernd Edlinger
PR target/100106
* gimplify-rtx.c (simplify_context::simplify_subreg): Check the
memory alignment for the outer mode.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100187
--- Comment #3 from 康桓瑋 ---
Hey, the __remove_fn helper lambda __pred in ranges_algo.h#L1259 also has this
issue, we need to forward the return type of the operator==.
You can see https://godbolt.org/z/ro34WYGnW for the failure case, thanks.
301 - 388 of 388 matches
Mail list logo
