https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #13 from fiesh at zefix dot tv ---
User99627, a few points:
* My test case does require lto to be present. There's nothing to be gained
from your statement that the bug doesn't require lto, there are test cases for
either case. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:97258480438db77e52f4b3947fa2c075b09d3fe1
commit r13-5617-g97258480438db77e52f4b3947fa2c075b09d3fe1
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #12 from Hongtao.liu ---
> When the VF is not known we usually do not require an epilogue? If
> we don't require one we should avoid creating one.
I may not be very clear in my description， here gdb shows.
(gdb) p vf
$1 = {> = {co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108622
--- Comment #1 from Fangrui Song ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611081.html [PATCH]
x86: Use DW_EH_PE_indirect|DW_EH_PE_pcrel encodings for -fno-pic code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #11 from rguenther at suse dot de ---
On Wed, 1 Feb 2023, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
>
> --- Comment #10 from Hongtao.liu ---
> (In reply to Hongtao.liu from comment #9)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #19 from rguenther at suse dot de ---
On Tue, 31 Jan 2023, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
>
> --- Comment #18 from Tamar Christina ---
> > >
> > > Ack, that also tracks wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #10 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #9)
> >
> >
> > decode_options() {
> > int flag = 1;
> > for (; flag <= 1 << 21; flag <<= 1)
> > ;
> > }
Normally when vf is not constant, it will be preve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471
Jan Kratochvil changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108622
Bug ID: 108622
Summary: x86 -fno-pic: use DW_EH_PE_indirect|DW_EH_PE_pcrel for
personality/ttype encoding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #11 from Andrew Pinski ---
(In reply to Khem Raj from comment #10)
>
> you are right. I should have mentioned that these copying is done by yocto
> builds for working though its notion of multilibs [1]. However, I think if
> we app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #10 from Khem Raj ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Khem Raj from comment #7)
> > > in Yocto we build outside the source tree. And during cross-build it wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Khem Raj from comment #7)
> > in Yocto we build outside the source tree. And during cross-build it will
> > copy aarch64.h into builddir and use it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #8 from Andrew Pinski ---
(In reply to Khem Raj from comment #7)
> in Yocto we build outside the source tree. And during cross-build it will
> copy aarch64.h into builddir and use it from there but then build can not
> find files it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
--- Comment #7 from Khem Raj ---
in Yocto we build outside the source tree. And during cross-build it will copy
aarch64.h into builddir and use it from there but then build can not find files
it includes since its being included from builddir. T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #9 from Hongtao.liu ---
>
>
> decode_options() {
> int flag = 1;
> for (; flag <= 1 << 21; flag <<= 1)
> ;
> }
>
>
>
> compile with gcc -fprofile-generate -mcpu=neoverse-v1 -Ofast opts.i
Reproduced with cross-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
Bug ID: 108621
Summary: [12 regression]: bind(c) pointer array spurious
maybe-uninitialized warning
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105144
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #2 from owent ---
Created attachment 54381
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54381&action=edit
The new report file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
--- Comment #1 from owent ---
Sorry, there are some problem in the source above. I commit another source and
report file.And clang 15 can compile and run successfully(
https://godbolt.org/z/d5M9ca567 ).
## Command and output
```
$ g++ test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108620
Bug ID: 108620
Summary: internal compiler error: in instantiate_type, at
cp/class.cc:8742 when assign the return value of
co_yield to a member of class/struct
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:70d34f2a30a5f1a2a09f547d92243db32d79f3f7
commit r13-5614-g70d34f2a30a5f1a2a09f547d92243db32d79f3f7
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
--- Comment #13 from Andrew Pinski ---
Note it looks like type_traits uses this pattern. Though I am shocked it didn't
show up in testing ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108559
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:b533084d756a2696a3eb6521810e0a0b2182a8e8
commit r13-5611-gb533084d756a2696a3eb6521810e0a0b2182a8e8
Author: Jason Merrill
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
--- Comment #12 from User99627 ---
Here's some feedback.
I asked in Manjaro Forums to make it so that avr-gcc is capped to version
10.1.0. The answer has been "Manjaro uses Arch application tree".
So I created an account to Arch bugzilla and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108106
--- Comment #11 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a9fbc6687faa09bf045c0fcee7960b7fef796fcc
commit r13-5610-ga9fbc6687faa09bf045c0fcee7960b7fef796fcc
Author: H.J. Lu
Date: Tue Jan 31 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #9 from Andrew Pinski ---
(In reply to Kyle Shores from comment #8)
> Thanks for looking into this. I believe that this worked for you, but for
> me, on both my machine and in the docker container, that addition did not
> fix the pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #8 from Kyle Shores ---
Thanks for looking into this. I believe that this worked for you, but for me,
on both my machine and in the docker container, that addition did not fix the
problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108600
--- Comment #4 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> Note that for for instance gdb test-case gdb.ada/ref_param.exp, this
> convention was broken for gcc 7.5.0 (and I don't know how much earlier), and
> my current gu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #11 from Jonathan Wakely ---
And it would be nice to simplify allocator_traits::construct using if-constexpr
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #6 from Andrew Pinski ---
Created attachment 54379
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54379&action=edit
FortranCode
about c++20 mode, and the rebind isn't needed in
C++20 (because std::allocator::rebind doesn't exist, so the default
implementation of rebinding does the right thing for alloc).
(In reply to Andrew Pinski from comment #6)
> With clang and libc++ we get:
>
> /opt/compiler-expl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #8 from gccbugzilla at thepirate42 dot org ---
The same code (with added rebind, https://godbolt.org/z/6fabvnvE7) compiles in
c++17 mode, while in c++20 mode (also with added rebind,
https://godbolt.org/z/ehhzYd5Wo) it doesn't, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #7 from gccbugzilla at thepirate42 dot org ---
(In reply to Andrew Pinski from comment #6)
> With clang and libc++ we get:
>
> /opt/compiler-explorer/clang-trunk-20230131/bin/../include/c++/v1/__memory/
> uninitialized_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #6 from Andrew Pinski ---
With clang and libc++ we get:
/opt/compiler-explorer/clang-trunk-20230131/bin/../include/c++/v1/__memory/uninitialized_algorithms.h:597:3:
error: static assertion failed due to requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #5 from Andrew Pinski ---
(In reply to gccbugzilla from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Once I add:
> >
> > template struct rebind {
> > typedef alloc other;
> > };
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
gccbugzilla at thepirate42 dot org changed:
What|Removed |Added
Resolution|FIXED |---
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
gccbugzilla at thepirate42 dot org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #8 from Tamar Christina ---
In case it helps, here's the reproducer on compiler explorer and the dump file
https://godbolt.org/z/dWvqexjnv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
--- Comment #1 from Andrew Pinski ---
The trunk gives a better error message:
/opt/compiler-explorer/gcc-trunk-20230131/include/c++/13.0.1/bits/alloc_traits.h:70:31:
error: static assertion failed:
allocator_traits::rebind_alloc must be A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
Tamar Christina changed:
What|Removed |Added
Target||aarch64*
Summary|[13 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108619
Bug ID: 108619
Summary: Compilation error if the construct method of the
allocator isn't implemented and the detructor of
value_type is private
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108354
--- Comment #6 from Andrew Pinski ---
Full backtrace:
(gdb) bt
#0 0x0158208f in get_range_query (fun=0x0) at
/home/apinski/src/upstream-gcc/gcc/gcc/value-query.h:143
#1 0x01e4a9f0 in ssa_name_has_boolean_range (op=0x752a687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108354
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> raised STORAGE_ERROR : stack overflow or erroneous memory access
0x015769b4 in get_range_query (fun=) at
/home/apinski/src/upstream-gcc/gcc/gcc/value-qu
gcc/gcc/configure
--prefix=/home/apinski/upstream-gcc
--enable-languages=c,c++,fortran,lto,objc,go,ada
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230131 (experimental) [master 733988099bc] (GCC)
COLLECT_GCC_OPTIONS='-B' '../../' '-c&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #5 from Kyle Shores ---
New C++ source file:
```
#include
#include
#include
#include
#include
#include
extern "C" {
void Finit(void);
void get_names( CFI_cdesc_t * );
}
std::vector extract_names(CFI_cdesc_t* names){
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #4 from Kyle Shores ---
Sure, I'll attempt to remove gtest and cmake. I was merely slimming the example
down from my use case in case it mattered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #3 from Kyle Shores ---
Ah, the specific error message printed at runtime:
Fortran runtime error: Unexpected version 16 (expected 1) in CFI descriptor
passed to dummy argument the_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #2 from Andrew Pinski ---
and use make rather than cmake here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
--- Comment #1 from Andrew Pinski ---
Is there a way to remove the depedency on gtest/gtest.h ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108618
Bug ID: 108618
Summary: ISO C-Fortran Interface fails to pass CFI descriptor
version check when using code coverage flags for
fortran
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108609
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-01-31
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108598
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86960
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102870
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102870
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:b2ec2504af77b35e748067eeb846821d12a6b6b4
commit r13-5608-gb2ec2504af77b35e748067eeb846821d12a6b6b4
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #19 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #18)
> I should say that testcase happens at `-Os -mstrict-align`, at `-O2
> -mstrict-align` it works.
Because for -Os we don't forcibly align arrays - see
AARCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102870
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108617
Andrew Pinski changed:
What|Removed |Added
Depends on||104426
--- Comment #1 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108617
Bug ID: 108617
Summary: nullptr comparision in constexpr not constexpr when
using -fsanitize=returns-nonnull-attribute
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #18 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #17)
> Another testcase which is now affecting us at Marvell in our early firmware:
> ```
> void f(const char*);
>
> void g(void)
> {
> char t[32] = "0l2345678";
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100
--- Comment #17 from Andrew Pinski ---
Another testcase which is now affecting us at Marvell in our early firmware:
```
void f(const char*);
void g(void)
{
char t[32] = "0l2345678";
f(t);
}
```
So I am planning on getting back on this patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573
--- Comment #3 from Jakub Jelinek ---
--- gcc/ree.cc.jj 2023-01-02 09:32:45.327953792 +0100
+++ gcc/ree.cc 2023-01-31 18:36:31.253018233 +0100
@@ -875,7 +875,8 @@ combine_reaching_defs (ext_cand *cand, c
for (df_link *use = use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108616
Bug ID: 108616
Summary: -Wanalyzer-allocation-size false negatives for use of
"alloca"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108597
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:07ef737cf1ab08f5c36786c7ab1ffc596fe52138
commit r12-9093-g07ef737cf1ab08f5c36786c7ab1ffc596fe52138
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107593
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107593
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:07ef737cf1ab08f5c36786c7ab1ffc596fe52138
commit r12-9093-g07ef737cf1ab08f5c36786c7ab1ffc596fe52138
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108597
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108573
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107593
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:623730d954a051941ae6a098f851bef308916ca0
commit r13-5582-g623730d954a051941ae6a098f851bef308916ca0
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108597
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:623730d954a051941ae6a098f851bef308916ca0
commit r13-5582-g623730d954a051941ae6a098f851bef308916ca0
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #23 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #22)
> Use --without-libstdcxx-zoneinfo
I'll make that the default for msp430-elf and avr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108607
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099
Andrew Pinski changed:
What|Removed |Added
CC||mserdarsanli at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
--- Comment #3 from Andrew Pinski ---
signed __int128_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108589
--- Comment #4 from CVS Commits ---
The master branch has been updated by Philipp Tomsich :
https://gcc.gnu.org/g:a39c6ec97906766ad65d15d4856fd41121ee7a45
commit r13-5581-ga39c6ec97906766ad65d15d4856fd41121ee7a45
Author: Philipp Tomsich
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108611
--- Comment #1 from Tobias Burnus ---
I think the code uses to quote some non-normative statement:
"F2018 relaxes the requirement that, in structure constructor, the component
and the expression to initialize it must have the same declared type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:2bb444787ed17a9e786f544cdf51ee2ac6779ab2
commit r13-5580-g2bb444787ed17a9e786f544cdf51ee2ac6779ab2
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #18 from Tamar Christina ---
> >
> > Ack, that also tracks with what I tried before, we don't indeed track ranges
> > for vector ops. The general case can still be handled slightly better (I
> > think)
> > but it doesn't become as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108613
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #10 from Andrew Macleod ---
Fixed in GCC 13, unlikely to be ported to gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108385
--- Comment #9 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:1626ec53e8c1b9c245572417d380e3ed84990cff
commit r13-5579-g1626ec53e8c1b9c245572417d380e3ed84990cff
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108359
--- Comment #7 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:809d661aff99ae0287baf4a52269425de62381e6
commit r13-5578-g809d661aff99ae0287baf4a52269425de62381e6
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108462
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
1 - 100 of 142 matches
Mail list logo
