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
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 #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=96963
Pokechu22 changed:
What|Removed |Added
CC||pokechu022+gccbugzilla@gmai
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=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=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=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=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=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=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=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=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 #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=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 #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=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=21976
Andrew Pinski changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #4
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=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=103541
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
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=108639
Andrew Pinski changed:
What|Removed |Added
CC||vsevolod.livinskiy at gmail
dot co
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=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
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=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=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=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=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=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=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=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=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=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=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
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=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=108639
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=108647
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|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=108451
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- 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=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=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=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=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=39796
Andrew Pinski changed:
What|Removed |Added
CC||vhaisman at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62200
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570
--- Comment #5 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:093e2e1b201c0f324e0d8bfe6487aa2d470a13e7
commit r13-5694-g093e2e1b201c0f324e0d8bfe6487aa2d470a13e7
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810
--- Comment #9 from Murugesan Nagarajan ---
I'll update my comment today(Sat 04-Feb-2023 IST) after 09:00 AM IST. Right now
I'm facing network issue due to travelling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
Marek Polacek changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression]
|m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:27ac6a707e7438c3cec79c24f5d53de79493e2f8
commit r13-5693-g27ac6a707e7438c3cec79c24f5d53de79493e2f8
Author: Marek Polacek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:60fca1802a25034f49fa1e3769b3a5656f392e89
commit r13-5692-g60fca1802a25034f49fa1e3769b3a5656f392e89
Author: Marek Polacek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #4 from Andrew Pinski ---
(In reply to David Binderman from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > If I initialize __trans_tmp_13 explictly to 0, the issue goes away
>
> $ fgrep trans_tmp_13 bug880.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #3 from David Binderman ---
(In reply to Andrew Pinski from comment #2)
> If I initialize __trans_tmp_13 explictly to 0, the issue goes away
$ fgrep trans_tmp_13 bug880.c
int64_t __trans_tmp_13;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Sebastian Huber changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
Bug ID: 108661
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in haproxy's sink_rotate_file_backed_ring
Product: gcc
Version: 13.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #7 from Jakub Jelinek ---
Sorry, above doesn't compile, but
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __PRETTY_FUNCTION__;
struct
{
constexpr const char* operator(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108660
Bug ID: 108660
Summary: Wrong location for first statement of for loop
(-Wunused-value)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
Marek Polacek changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #2 from Andrew Pinski ---
If I initialize __trans_tmp_13 explictly to 0, the issue goes away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #5 from Jakub Jelinek ---
Makes me wonder why finish_fname returns the IDENTIFIER_NODE rather than the
VAR_DECL when processing_template_decl, though if I comment that out it ICEs.
When DECL_INITIAL is __FUNCTION__ etc. IDENTIFIER_NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonny Grant from comment #3)
> Is it worth -Wnonnull emitting a warning message that it needs optimization
> to get the needed data flow analysis?
No, there are dozens of warnings that work p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #7 from Jan Dubiec ---
(In reply to Andrew Pinski from comment #6)
[...]
> as sizeof returns size_t.
>
> Does that make sense now?
Yep, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
--- Comment #3 from Sebastian Huber ---
Thanks for the hint, however, adding -pthread or -fprofile-update=atomic
doesn't change anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #6 from Andrew Pinski ---
(In reply to Jan Dubiec from comment #5)
> Regarding gcc/ira-conflicts.cc, I think you are probably right, parentheses
> should fix the issue. But I am not able to understand (without looking into
> docs) ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #5 from Jan Dubiec ---
Andrew, as per your wish, preprocessed lto-plugin\lto-plugin.c is in the
attachment. It was produced using the following command:
gcc -DHAVE_CONFIG_H -I. -I../../../gcc/lto-plugin
-I../../../gcc/lto-plugin/../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #4 from Andrew Pinski ---
(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 AArch64 CAS for atomics. LLVM merged that
> chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #4 from Jan Dubiec ---
Created attachment 54406
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54406&action=edit
Preprocessed lto-plugin\lto-plugin.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
--- Comment #3 from Niall Douglas ---
> AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have
> some statement from the latter, I'm not sure it is enough and we don't have
> anything from VIA. See PR104688 for details.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Scott Boyce from comment #3)
> No its not correct because the
Yes, it is the correct behavior. Please see 18-007r1.pdf, p.57.
7.4.3.1 Integer type
...
Any integer value can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #15 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 54405 [details]
> gcc13-pr108647.patch
>
> Here is what I'm about to test momentarily, though I must say I don't
> understand those operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
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=108647
--- Comment #13 from Aldy Hernandez ---
Created attachment 54404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54404&action=edit
frange changes
These are the analogous changes to range-op-float.cc.
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #1 from David Binderman ---
Created attachment 54403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54403&action=edit
C source code
After 90 minutes reduction, about 12% of the original is left.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #6 from David Spickett ---
Thanks for the link, we'll try to use those when we detect g++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #8 from Scott Boyce ---
Sorry for sending a second message, my test cases have a workaround already
added to the code for the Finalization, but the code posted has issues with
ALLOCATION of derived types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
--- Comment #7 from Scott Boyce ---
(In reply to Jerry DeLisle from comment #6)
Thanks that is excellent news about the finalization.
There also is the issue with the ALLOCATION as well.
Another set of test cases are my Batteries Included Fort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #12 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> So
> --- gcc/range-op.cc.jj2023-02-03 10:51:40.699003658 +0100
> +++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
> @@ -642,7 +642,8 @@ operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
--- Comment #3 from Scott Boyce ---
No its not correct because the
[integer(int64)::
in
INTEGER(INT64), dimension(2), parameter:: arr1 = [integer(int64)::
-3300711175878204139, 8258803693257250632]
is the initialization is indicating that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659
Bug ID: 108659
Summary: Suboptimal 128 bit atomics codegen on AArch64 and x64
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > Unfortunately that would mean for the non-equality cases th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #10 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #9)
> (In reply to Jakub Jelinek from comment #8)
> > Unfortunately that would mean for the non-equality cases that if
> > lhs.undefined_p () we don't return undefin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
--- Comment #1 from Andrew Pinski ---
Try compiling with -pthread too? Otherwise the instrumentation code assumes it
is single threaded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately that would mean for the non-equality cases that if
> lhs.undefined_p () we don't return undefined but false (aka VARYING).
> Another option is to
1 - 100 of 151 matches
Mail list logo
