https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Richard Biener from comment #1)
> >
> > void bar ();
> > void foo (int *a)
> > {
> > int qa = 0;
> > for (int i = 0; i < 3; i++)
> > if (a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
>
> void bar ();
> void foo (int *a)
> {
> int qa = 0;
> for (int i = 0; i < 3; i++)
> if (a[i])
> a[qa++] = 0;
> if (qa > 3)
> bar ();
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Richard Biener changed:
What|Removed |Added
Blocks||85316
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
--- Comment #8 from Richard Biener ---
I have opened PR107986 for the testcase in comment#2 which isn't yet fixed on
trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-12-06
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986
Bug ID: 107986
Summary: [12/13 Regression] Bogus -Warray-bounds diagnostic
with std::sort
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:790ff87f675f28bce5e7e35918ae09c3ece4ec4d
commit r13-4499-g790ff87f675f28bce5e7e35918ae09c3ece4ec4d
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985
Bug ID: 107985
Summary: [13 Regression] ICE in as_a, at value-range.h:393
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107984
Bug ID: 107984
Summary: ICE: in verify_target_availability, at
sel-sched.cc:1553 with -O2 -fselective-scheduling2
-mabi=ms -mavx512vl
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106576
--- Comment #7 from Paul Thomas ---
(In reply to Thomas Koenig from comment #6)
>
> > I hope that you are well and that the lack of time is for a good cause?
>
> Hi Paul,
>
> yes, I'm well, and the lack of time is indeed for a good cause :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107970
--- Comment #1 from Hongtao.liu ---
Mine, let me fix it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
--- Comment #6 from caiyinyu ---
Created attachment 54024
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54024&action=edit
glibc tests build log and fails test result
build log: tmp-tst-math-2022-12-05.log
test results: test-xxx.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107983
--- Comment #1 from James Hilliard ---
Working LLVM btf dump:
$ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug btf dump file
/home/buildroot/bpf-next/tools/testing/selftests/bpf/task_kfunc_success.bpf.linked3.o
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107983
Bug ID: 107983
Summary: btf: bad call relo against
'test_task_acquire_release_current' in section
'tp_btf/task_newtask'
Product: gcc
Version: 13.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #16 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #14)
> > Jonathan, has anyone suggested adding generic init_list constructors to the
> > container classes?
>
> Not that I'm aware of. There might be concerns abou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #6 from David Malcolm ---
Fix for the overzealous reducing is to simply add "__attribute__((nonnull(1,
2)))" to the reproducer here:
__attribute__((nonnull(1, 2)))
void
arranger_object_unsplit (ArrangerObject *r1, ArrangerObject *r2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from David Malc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106325
--- Comment #4 from David Malcolm ---
Created attachment 54023
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54023&action=edit
Reduced reproducer
Attached is a reduced version of the reproducer, which demonstrates the false
+ve on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107982
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
Jakub Jelinek changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107982
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #15 from Jakub Jelinek ---
So, do we want a new attribute on allocator to tell the compiler that it is a
class whose methods don't care about the address of the object and it has
trivial ctor and dtor and it is enough to construct it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107982
Bug ID: 107982
Summary: ICE in in lower_bound, at value-range.h:350
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: midd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #14 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #12)
> Another significant part of the problem is that vector doesn't have
> a generic initializer_list constructor. Adding
>
> template
> _GLIBCXX20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #16 from James Hilliard ---
(In reply to David Faust from comment #15)
> Created attachment 54021 [details]
> [v2] DATASEC entries for extern funcs
>
> v2 fixes an off-by-one bug introduced in the patch which was causing
> libbpf: I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
--- Comment #2 from anlauf at gcc dot gnu.org ---
The following attempt fixes the erroneous output:
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9f86815388c..c4525f67ef3 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
--- Comment #4 from seurer at gcc dot gnu.org ---
These systems are pretty old. So, just ignore it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> I think we should warn but how to warn is going to have to special case the
> macro I think.
But saying that I do think it is valid C2X code if you take the C2X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Summary|va_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
David Faust changed:
What|Removed |Added
Attachment #54017|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #2 from Aaron Ballman ---
(In reply to Andrew Pinski from comment #1)
> Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
> ```
> 7.16.1.4 The va_start macro
> void va_start(va_list ap, ...);
>
>
> Any additiona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107981
--- Comment #2 from Egor Pugin ---
Ignore previous comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107981
--- Comment #1 from Egor Pugin ---
Also see following test cases.
===
ok for gcc
struct a {
operator auto();
};
struct b : a {
using a::operator auto;
};
===
not ok for gcc&clang, ok for msvc
struct a {
operator auto();
};
stru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #13 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #11)
> Even if we don't emit a loop (which I still think is the way to go for
> larger initializers because anything else means just too large code), can't
> there fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
--- Comment #1 from Andrew Pinski ---
Hmm from https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf :
```
7.16.1.4 The va_start macro
void va_start(va_list ap, ...);
Any additional arguments are not used by
the macro and will not be expa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107981
Bug ID: 107981
Summary: 'operator auto' has not been declared in base
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #12 from Jason Merrill ---
Another significant part of the problem is that vector doesn't have a
generic initializer_list constructor. Adding
template
_GLIBCXX20_CONSTEXPR
vector(initializer_list<__elt> __l,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980
Bug ID: 107980
Summary: va_start incorrectly accepts an arbitrary number of
arguments in C2x
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
--- Comment #3 from Andrew Pinski ---
https://sourceware.org/git/?p=glibc.git;a=commit;h=d1d9eaf478b7d3a11a599c120498b79fe5629a61
was the change in glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107922
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
--- Comment #1 from seurer at gcc dot gnu.org ---
Oh, also these:
FAIL: experimental/names.cc (test for excess errors)
FAIL: experimental/names.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979
Bug ID: 107979
Summary: [13 regression] r13-4391-g0ded30b361d2b1 causes excess
errors in 17_intro/names.cc on big endian
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107978
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107968
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-12-05
Ever confirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
--- Comment #1 from Andrew Pinski ---
ncases = tree_to_shwi (range) + 1;
labelvec = XALLOCAVEC (rtx, ncases);
memset (labelvec, 0, ncases * sizeof (rtx));
I think this is a won't fix.
Doctor, it hurts when I bend my arm this way.
Don't b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107978
Bug ID: 107978
Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in dump_ada_declaration, at
c-family/c-ada-spec.cc:2802 with -fdump-ada-spec
ra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221205 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #14 from James Hilliard ---
(In reply to David Faust from comment #13)
> Created attachment 54017 [details]
> DATASEC entries for extern funcs
>
> Applies on top of 54002: updated patch
> Adds emission of DATASEC entries for extern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976
Bug ID: 107976
Summary: ICE: SIGSEGV (stack overflow) in
emit_case_dispatch_table (stmt.cc:783) with large
--param=jump-table-max-growth-ratio-for-speed
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #11 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #10)
> A lot of the problem here is that building a std::string involves building a
> std::allocator temporary to pass to the string constructor, and then
> we need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871
--- Comment #5 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #4)
> Maybe you could legally do:
>
> using difference_type = iterator_t>;
>
> but maybe just don't do that. If things break when you do dumb things, don't
> do those things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107973
--- Comment #2 from Bernd Edlinger ---
Thanks,
I see a very similar warning with
m68k-linux-gnu-gcc but without sanitizer:
crypto/modes/cfb128.c: In function 'CRYPTO_cfb128_encrypt':
crypto/modes/cfb128.c:117:33: error: writing 1 byte into a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
--- Comment #1 from Jakub Jelinek ---
The testcase was guessed from the
https://gcc.gnu.org/pipermail/gcc-regression/2022-December/077258.html
report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Jason Mer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106773
--- Comment #13 from David Faust ---
Created attachment 54017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54017&action=edit
DATASEC entries for extern funcs
Applies on top of 54002: updated patch
Adds emission of DATASEC entries for ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107975
Bug ID: 107975
Summary: [13 Regression] frange ICE since r13-4492
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #5 from Cristian Adam ---
Created attachment 54016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54016&action=edit
gcc long path working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #4 from Cristian Adam ---
The manifest file is being mentioned at
https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #3 from Cristian Adam ---
I've used the manifest tool from Visual C++ (mt.exe) to inject this manifest:
http://schemas.microsoft.com/SMI/2016/WindowsSettings";>
true
with the command line:
mt.exe -nologo -man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
--- Comment #5 from Jakub Jelinek ---
(In reply to caiyinyu from comment #2)
> I tested with latest gcc(commit 102f3cef568), and these fails still exist.
Do the glibc test logs provide some details on what exactly failed, if it is a
wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #14 from Thiago Macieira ---
Created attachment 54015
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54015&action=edit
qfutureinterface.cpp preprocessed [gcc trunk-20221205]
(In reply to Richard Biener from comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
--- Comment #4 from Jakub Jelinek ---
I mean should fix the ICE, nothing else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #8)
> (In reply to Aldy Hernandez from comment #7)
> > (In reply to Richard Biener from comment #6)
> > > (In reply to Jakub Jelinek from comment #0)
> > > > ... but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107969
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #2 from Andrew Pinski ---
GCC just does:
file->fd = open (file->path, O_RDONLY | O_NOCTTY | O_BINARY, 0666);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
--- Comment #1 from Cristian Adam ---
Visual C++ 2022 also suffers from the same problem, see
https://developercommunity.visualstudio.com/t/compiler-cant-find-source-file-in-path/10221576
For some reason clang is working fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107957
--- Comment #1 from Jacek Wieczorek ---
A little correction - I just noticed my mistake. Assembly for rawr() is in fact
correct. Apparently this happens only for variables longer than 16 bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974
Bug ID: 107974
Summary: compiler can't find source file in path that is longer
than 255 characters
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
--- Comment #27 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0d14720f93a8139a7f234b2762c361e8e5da99cc
commit r13-4495-g0d14720f93a8139a7f234b2762c361e8e5da99cc
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #13 from Richard Biener ---
There's been some changes on trunk but the preprocessed source doesn't work
there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #5 from Siddhesh Poyarekar ---
(In reply to rguent...@suse.de from comment #4)
> Does it allow the nesting when nested in a union?
data[] cannot be nested directly in a union (i.e. union { char d; char data[];
} is invalid) but some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2020-06-03 00:00:00 |2022-12-5
--- Comment #19 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #22 from Brjd ---
Maybe not changing now is the correct way for now since I may change it blindly
not knowing completely what I am doing. Let the developers correct it and will
include it in next releases. The compiler is excellent a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #8 from Richard Biener ---
(In reply to Aldy Hernandez from comment #7)
> (In reply to Richard Biener from comment #6)
> > (In reply to Jakub Jelinek from comment #0)
> > > ... but then
> > > comes dom2 and happily replaces
> > > _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #4 from rguenther at suse dot de ---
On Mon, 5 Dec 2022, siddhesh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
>
> --- Comment #2 from Siddhesh Poyarekar ---
> The standard does not allow the nes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #21 from Brjd ---
Created attachment 54012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54012&action=edit
i386-builtins-orig-12.2.0.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #20 from Brjd ---
The test gcc/testsuite/gcc.target/i386/builtin_target.c is patched.
But gcc/config/i386/i386-builtins.cc looks like it is from another version.
I attached it as i386-builtins-orig-12.2.0.cc to compare them and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #13 from Martin Liška ---
> As a hack I've removed them manually:
> FOR_EACH_BB_FN (bb, cfun)
> {
> gimple_stmt_iterator gsi = gsi_after_labels (bb);
> if (!gsi_end_p (gsi) && gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT)
> gsi_rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107973
Martin Liška changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-12-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107966
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107960
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
Richard Biener changed:
What|Removed |Added
Known to fail||12.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d492d50f644811327c5976e2c918ab6d906ed40c
commit r13-4494-gd492d50f644811327c5976e2c918ab6d906ed40c
Author: Richard Biener
Date:
ing treated as errors
this happens with:
gcc version 12.2.1 20221130 (GCC)
gcc version 11.3.1 20221205 (GCC)
gcc version 10.4.1 20221205 (GCC)
but did not happen with:
gcc version 9.5.0 (GCC)
nor does it happen with:
gcc version 13.0.0 20221130 (experimental) (GCC)
It is pretty annoying because t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107972
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
1 - 100 of 155 matches
Mail list logo
