https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108662
Bug ID: 108662
Summary: Cast between incompatible function types in
libiberty/physmem.c under MinGW-W64/MSYS2 on Windows
10
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #16 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:10bd26d6efe88a8cf03a6a325351bc470a910cab
commit r13-5695-g10bd26d6efe88a8cf03a6a325351bc470a910cab
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #13 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:e261fcefb71e1270673f0457fcc73711f13d3079
commit r13-5696-ge261fcefb71e1270673f0457fcc73711f13d3079
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:76f7f0eddcb7c418d1ec3dea3e2341ca99097301
commit r13-5697-g76f7f0eddcb7c418d1ec3dea3e2341ca99097301
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e753080ab8abd4021381699bc7e857f5b4a083c4
commit r13-5698-ge753080ab8abd4021381699bc7e857f5b4a083c4
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663
Bug ID: 108663
Summary: Accepts invalid bug with pdtXXX
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: accepts-invalid, ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 108647, which changed state.
Bug 108647 Summary: [13 Regression] ICE in upper_bound, at value-range.h:950
with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
--- Comment #2 from Marek Polacek ---
Very interesting. We're in store_init_value, initializing x with
&TARGET_EXPR }>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) & >>>;, (const struct
X &) &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #6 from Andrew Pinski ---
(In reply to Wilco from comment #5)
> To me a far worse issue is that this difference for 128-bit atomics means
> that LLVM and GCC are binary incompatible. AFAIK isn't an option to make
> them compatible ei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #7 from Niall Douglas ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Niall Douglas from comment #3)
> > You may be interested in reading https://reviews.llvm.org/D110069. It wanted
> > to have LLVM generate a 128 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108664
Bug ID: 108664
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in coreutils's cksum.c: cksum_slice8
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108663
--- Comment #1 from Steve Kargl ---
> $ gfortran-13-20221218 -c z1.f90 # missing error
> $
> $ gfortran-13-20230115 -c z1.f90
> z1.f90:12:7:
>
>12 |use m, only: t, pdtt, s
> | 1
> internal compiler error: in check_complete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108665
Bug ID: 108665
Summary: Depenency checking: Run-time loop reversal instead of
creating a temporary
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #8 from Wilco ---
(In reply to Niall Douglas from comment #7)
> (In reply to Andrew Pinski from comment #4)
> > (In reply to Niall Douglas from comment #3)
> > > You may be interested in reading https://reviews.llvm.org/D110069. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #9 from Jakub Jelinek ---
(In reply to Wilco from comment #8)
> Yes that sounds like a reasonable approach.
I don't think so. Not all variables on which __atomic_* intrinsics are used
are actually _Atomic, the vars can be embedded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108666
Bug ID: 108666
Summary: -Wanalyzer-use-of-uninitialized-value false positives
seen in coreutils's sum.c: bsd_sum_stream
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667
Bug ID: 108667
Summary: Spurious "maybe used uninitialized
[-Wmaybe-uninitialized]" warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810
--- Comment #11 from Murugesan Nagarajan ---
Hi Andrew,
Thank you for your comment. I'll check this after 09:00 AM.
Regards,
N.Murugesan
Google:
murugesan openssl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #10 from Niall Douglas ---
(In reply to Jakub Jelinek from comment #9)
> (In reply to Wilco from comment #8)
> > Yes that sounds like a reasonable approach.
>
> I don't think so. Not all variables on which __atomic_* intrinsics are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #11 from Wilco ---
(In reply to Niall Douglas from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > (In reply to Wilco from comment #8)
> > > Yes that sounds like a reasonable approach.
> >
> > I don't think so. Not a
ol*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:2277
0x1394723 dom_opt_dom_walker::before_dom_children(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-dom.cc:1682
0x2087717 dom_walker::walk(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/domwalk.cc:311
gcc version 13.0.1 20230203 (093e2e1b201c0f324e0d8bfe6487aa2d470a13e7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Andrew Pinski changed:
What|Removed |Added
CC||vsevolod.livinskiy at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108668
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 108668, which changed state.
Bug 108668 Summary: [13 Regression] ICE in decompose, at wide-int.h:984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108668
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107079
--- Comment #3 from Marek Polacek ---
The cxx_constant_init call actually takes decl=x so we should probably use
that.
value = cxx_constant_init (value, decl);
However, in cxx_eval_outermost_constant_expr type is const struct X & and so we
don'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
Bug ID: 108669
Summary: [diagnostic] std::vector of incomplete type has member
referenced
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59284
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21976
Andrew Pinski changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667
--- Comment #1 from Andrew Pinski ---
This is partly caused by not inlining everything as main is marked as called
once.
If instead I call main, main1, the warning goes away and the following call is
inlined now:
std::_Function_handler >::_M_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
--- Comment #1 from Andrew Pinski ---
What I thought would be a reduced testcase is correctly rejected:
#include
struct B;
template
struct v
{
static_assert(std::is_destructible::value);
};
struct A {
v _;
};
A a{}; // <--here
str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #5 from Jakub Jelinek ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
--- Comment #2 from Jonathan Wakely ---
(In reply to Luke Dalessandro from comment #0)
> This should run afoul of the second half of
> https://eel.is/c++draft/vector#overview-4. "T shall be complete before any
> member of the resulting specializ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108667
--- Comment #2 from Alvaro Begue ---
Yes, this is a reduction of real code. I'm writing a signal class and I wrote a
small test for it. It worked fine when compiling unoptimized, but the optimized
version gave me this odd warning.
Would it be i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108669
--- Comment #3 from Luke Dalessandro ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Luke Dalessandro from comment #0)
> > This should run afoul of the second half of
> > https://eel.is/c++draft/vector#overview-4. "T shall be co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108670
Bug ID: 108670
Summary: Bogus narrowing conversion warning with designated
initializers for bitfield in union
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108671
Bug ID: 108671
Summary: spurious "defined but not used" warning with static
call back function
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Khem Raj changed:
What|Removed |Added
CC||raj.khem at gmail dot com
--- Comment #19 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108672
Bug ID: 108672
Summary: [13 Regression] g++.dg/modules/xtreme-header-2_a.H,
_b.C, _c.C
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810
--- Comment #12 from Murugesan Nagarajan ---
Thank you for sharing comment at:
>> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=4e4e3ffd10f53e
Move stream initialization into compiled library
I am facing my issue to have my proper environment:
0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #6 from Jerry DeLisle ---
I had to go back in the Standard to deepen my understanding. Yes simplifying
it would help. I think what we need to do is acknowledge that we should match
'(' and if found, recursively call the gfc_match_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #20 from Jakub Jelinek ---
How could these changes result in
../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’ (operand
types are ‘hb_filter_iter_t::item_t>, bool (hb_hashmap_t::item_t::*)() const, const&, 0>’ an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963
Pokechu22 changed:
What|Removed |Added
CC||pokechu022+gccbugzilla@gmai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #21 from Jakub Jelinek ---
Seems it is r13-5684-g59e0376f607805ef9b67fd7b0a4a3084ab3571a5 aka PR107461
change. So, please file a separate bugreport, it has nothing to do with this
PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
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=108647
--- Comment #22 from Khem Raj ---
(In reply to Jakub Jelinek from comment #20)
> How could these changes result in
> ../harfbuzz-6.0.0/src/hb-map.hh:295:5: error: no match for ‘operator|’
> (operand types are ‘hb_filter_iter_t unsigned int, true
101 - 151 of 151 matches
Mail list logo
