https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
--- Comment #4 from Andreas Schwab ---
missing_languages=`echo "$missing_languages" |
sed -e ':loop' -e "s/,$language,/,/" -e 't loop'`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128
--- Comment #9 from Jakub Jelinek ---
(In reply to Mike Hommey from comment #7)
> Forget my last comment, it came from the use of a sysroot with an older
> glibc. I wonder why the sysroot path didn't appear in those messages...
You need to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
Richard Biener changed:
What|Removed |Added
Summary|[12/13 Regression] GCC |[12 Regression] GCC 12.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #17 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:c5df8392c5848c0462558f41cdf6eab31db301cf
commit r13-4137-gc5df8392c5848c0462558f41cdf6eab31db301cf
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107744
Bug ID: 107744
Summary: Error in constant evaluation of dynamic_cast
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107743
Bug ID: 107743
Summary: expmed: extract_bit_field_1: maybe-uninitialized
warning
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
--- Comment #6 from Hongyu Wang ---
(In reply to Jiu Fu Guo from comment #4)
> (In reply to Hongyu Wang from comment #2)
> > Created attachment 53897 [details]
> > A patch
> >
> > Sorry for introducing these fails. Here is the patch.
> >
> > I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107713
--- Comment #5 from CVS Commits ---
The master branch has been updated by LuluCheng :
https://gcc.gnu.org/g:f0024bfb228f94e60e06dc32a4983e40a9b90be5
commit r13-4136-gf0024bfb228f94e60e06dc32a4983e40a9b90be5
Author: Jinyang He
Date: Thu Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
--- Comment #5 from Jiu Fu Guo ---
> -munroll-only-small-loops does not turn on or off -funroll-loops, and it
> should not, so that it does what it says, if nothing else.
Yes, and -funroll-loops would win over -munroll-only-small-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
--- Comment #15 from Andrew Pinski ---
Looking at the -fdump-tree-optimized for generic-match.cc (-O2 -g) in terms of
lines, we get:
832068 before
718872 after
That is 17% less lines. That is nice improvments. Majority is debugging info
for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
--- Comment #14 from Andrew Pinski ---
Compile time using the same base compiler (without the patch and with
--enable-checking=yes)
Without the patch:
apinski@xeond:~/src/upstream-gcc/gcc/objdir/gcc$ time make -j16 generic-match.o
CXXFLAGS="-O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski changed:
What|Removed |Added
Attachment #8839|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45749
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
--- Comment #3 from Andrew Pinski ---
So there are two issues but I don't know how to solve the second part of the
issue.
The first issue is there is a missing g for the flags of the s command of the
sed command here:
missing_languages=`echo "$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
Andrew Pinski changed:
What|Removed |Added
Keywords||build, diagnostic
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128
--- Comment #8 from Andrew Pinski ---
(In reply to Mike Hommey from comment #7)
> Forget my last comment, it came from the use of a sysroot with an older
> glibc. I wonder why the sysroot path didn't appear in those messages...
Can you file a n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128
--- Comment #7 from Mike Hommey ---
Forget my last comment, it came from the use of a sysroot with an older glibc.
I wonder why the sysroot path didn't appear in those messages...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107742
Bug ID: 107742
Summary: class mismatch in passed procedure
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107128
Mike Hommey changed:
What|Removed |Added
CC||mh+gcc at glandium dot org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
--- Comment #1 from David Blaikie ---
Oh, some context - discovered while investigating a related clang bug:
https://github.com/llvm/llvm-project/issues/58819 - so don't check clang for an
example of what's right here, it has different bugs, tho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
Bug ID: 107741
Summary: Missed member variable name in mangling of externally
visible lambdas used in inline initialization of
static members
Product: gcc
Versio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
--- Comment #4 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > I wonder if this is because doing
> > constexpr const int *v1 = &array[3];
> >
> > is valid and well defined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:b9b78b4de3c7dcc6868c4af831b2d213fda21b04
commit r10-11087-gb9b78b4de3c7dcc6868c4af831b2d213fda21b04
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> I wonder if this is because doing
> constexpr const int *v1 = &array[3];
>
> is valid and well defined.
It's not, but &array.data()[3] is.
I agree that's p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:90824f6c57e1ac7b94c558b4c99721b412df75ef
commit r11-10381-g90824f6c57e1ac7b94c558b4c99721b412df75ef
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:14faa5f585f6025df1e04c8c8b34340ff5e4d494
commit r12-8916-g14faa5f585f6025df1e04c8c8b34340ff5e4d494
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104066
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:7b3b2f50953c5143d4b14b59d322d8a793f411dd
commit r13-4135-g7b3b2f50953c5143d4b14b59d322d8a793f411dd
Author: Marek Polacek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
--- Comment #1 from Andrew Pinski ---
I thought this was fixed at one point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
--- Comment #2 from Andrew Pinski ---
I wonder if this is because doing
constexpr const int *v1 = &array[3];
is valid and well defined.
Even clang gives two different error messages:
:3:21: error: constexpr variable 'v1' must be initialized b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
Mark Abraham changed:
What|Removed |Added
CC||mark.j.abraham at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
--- Comment #3 from Andrew Pinski ---
>phi-opt1 is the "early phi-opt" which tries not to do it here.
Let me expand on that, it tries not to insert a cast here to do the conversion
from bool to int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107705
--- Comment #2 from Andrew Pinski ---
diff --git a/gcc/function.cc b/gcc/function.cc
index 361aa5f7ed1..9c8773bbc59 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -2090,6 +2090,9 @@ aggregate_value_p (const_tree exp, const_tree fntype)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107740
Bug ID: 107740
Summary: if-to-switch conversion happens for simple predicate
function when compiled with gcc but not with g++
Product: gcc
Version: 13.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107307
--- Comment #2 from Andrew Pinski ---
Simple fix:
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f06ce3cc77a..bd772c15bec 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -3319,7 +3319,9 @@ gimplify_compound_lval (tree *expr_p, gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764
--- Comment #4 from Andrew Pinski ---
Actually the fix is just check the return value of gimplify_expr to make sure
it was not GS_ERROR.
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index f06ce3cc77a..9b74f957308 100644
--- a/gcc/gimplify.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107739
Bug ID: 107739
Summary: --enable-languages= duplicates yield odd error
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106764
--- Comment #3 from Andrew Pinski ---
At the point where the CALL_EXPR is built:
Breakpoint 5, build_function_call_vec (loc=258624, arg_loc=...,
function=, params=0x0, origtypes=0x0,
orig_fundecl=) at
/home/apinski/src/upstream-gcc/gcc/gcc/c/c-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #11 from Andrew Pinski ---
(In reply to David Binderman from comment #10)
> (In reply to Andrew Pinski from comment #9)
> > Fixed.
>
> Thanks for that.
>
> Would it ok to manually check all uses of sbitmap, to make sure they
> ini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
--- Comment #5 from Andrew Pinski ---
(In reply to mfarca from comment #4)
> Thanks for creating the issue for improving documentation.
>
> Could you then clarify if call to the incorrect address is a bug or not?
> instructions are allowed to b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107738
--- Comment #1 from Andrew Pinski ---
I know there are other related bugs where people mess up the top-level
inline-asm too but I can't find them right now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
--- Comment #4 from mfarca ---
Thanks for creating the issue for improving documentation.
Could you then clarify if call to the incorrect address is a bug or not?
instructions are allowed to be under `.rodata` section as this section is still
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #10 from David Binderman ---
(In reply to Andrew Pinski from comment #9)
> Fixed.
Thanks for that.
Would it ok to manually check all uses of sbitmap, to make sure they initialise
bits appropriately, or would it be better to define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884
--- Comment #2 from CVS Commits ---
The master branch has been updated by Bernhard Reutner-Fischer
:
https://gcc.gnu.org/g:19be89d79ee149e812ccc6027956cefb7f3e1016
commit r13-4133-g19be89d79ee149e812ccc6027956cefb7f3e1016
Author: Bernhard Reutn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107738
Bug ID: 107738
Summary: Top-level inline-asm is not well documented
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: documentation, inline-asm
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
--- Comment #2 from mfarca ---
> Toplevel inline-asm will be emitted without any knowledge of the current
> section.
So this is a limitation of gcc I guess? as clang does have the knowledge on
which is which.
The main issue still persists as c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
Bug ID: 107737
Summary: seemly looking off code in gimplify_call_expr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107736
Bug ID: 107736
Summary: call to a function, generated by inline asm, is off by
one byte
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
--- Comment #8 from Andrew Pinski ---
So clang emits one or the other warning for the code but not both.
You can defect the warning in clang by doing:
```
extern void g( int);
void f(float a)
{
double b = a;
if (b == 0.1234)
g( 1);
}
``
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:ee892832ea19b21a3420ef042e582204fac852a2
commit r13-4132-gee892832ea19b21a3420ef042e582204fac852a2
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #4 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:4e306222f442f8d4c6fc6da997ab756a5e43e36e
commit r13-4131-g4e306222f442f8d4c6fc6da997ab756a5e43e36e
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
Andrew Pinski changed:
What|Removed |Added
Summary|valgrind error for |[13 Regression] valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
David Malcolm changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107711
--- Comment #11 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f9ed1d24ee46f5ca759c35a1f51fa163d7529ea6
commit r13-4130-gf9ed1d24ee46f5ca759c35a1f51fa163d7529ea6
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #6 from David Binderman ---
I am trying a bisect with git hash b4fca4fc70dc76cf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #5 from David Binderman ---
I have reduced one of the test cases downto this code:
float val1f[][2], val2f[][2], chkf[][2];
foof_i;
foof() {
int j;
foof_i = 0;
for (; foof_i < 8; foof_i++) {
float tmp = val1f[foof_i][j] *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
Stam Markianos-Wright changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714
Stam Markianos-Wright changed:
What|Removed |Added
Last reconfirmed||2022-11-17
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #3 from Christophe Lyon ---
and patching test_dfp_17.c like so:
- ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _Decimal64. */
+ ANON(_Decimal32, f1, STACK+36) /* Note: no promotion to _Decimal64. */
makes it pass on aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-11-17
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #3 from Aldy Hernandez ---
(In reply to Andrey Alekseenko from comment #2)
> @Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
> issue for me.
No problem. Thank your for reporting and for reducing. It make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #2 from Andrey Alekseenko ---
@Aldy Hernandez, thank you. Can confirm that your patch fully resolves the
issue for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
--- Comment #1 from Aldy Hernandez ---
Created attachment 53920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53920&action=edit
untested
[PR tree-optimization/107732] [range-ops] Handle attempt to abs() negatives.
The threader is creati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #18 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #17)
> On Thu, 17 Nov 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> >
> > --- Comment #16 from Andrew Macle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90134
--- Comment #4 from Arseny Solokha ---
(In reply to Andrew Pinski from comment #3)
> This code is all undefined anyways .
Yes, but what about unmodified tests from libstdc++? I occasionally hit this
ICE on them too, as shown in comment 2. I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107633
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107732
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-11-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107735
Bug ID: 107735
Summary: Inconsistent error messages for std::array out of
bound
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #10 from Richard Biener ---
Interestingly the following variant of the testcase falls back to
VMAT_ELEMENTWISE but does have the same problem there fixed up by later
folding, but it will segfault when using -O2 -mavx2 -fno-vect-cost-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #9 from bartoldeman at users dot sourceforge.net ---
I ended up using -mprefer-vector-width=128 as a workaround myself (via
__attribute__((target("prefer-vector-width=128", so there is still some AVX
vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
--- Comment #8 from Richard Biener ---
Peeling for gaps also isn't a good fix here. One could envision a case with
even three iterations ahead load with
for(i = 0; i < n; i++) {
dot[0] += x[ix] * y[ix] ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #17 from rguenther at suse dot de ---
On Thu, 17 Nov 2022, amacleod at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
>
> --- Comment #16 from Andrew Macleod ---
> (In reply to rguent...@suse.de from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
--- Comment #16 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #15)
> On Wed, 16 Nov 2022, amacleod at redhat dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
> >
> > Andrew Macleod changed:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107604
--- Comment #2 from Christophe Lyon ---
Confirmed.
In test_dfp_17.c we have:
ARG(_Decimal64, 11.0dd, D0)
DOTS
ANON(struct z, a, D1)
ANON(struct z, b, STACK)
ANON(int , 5, W0)
ANON(_Decimal32, f1, STACK+32) /* Note: no promotion to _D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #4 from David Binderman ---
A third:
./gcc.target/i386/pr61403.c
==749959== Conditional jump or move depends on uninitialised value(s)
==749959==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==749959==by 0x11DFAE7: gimple_sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105278
--- Comment #7 from Eric Gallager ---
(In reply to Andrew Pinski from comment #6)
> I don't think clang implements -Wfloat-equal at all, at least they didn't at
> the last time I looked a few years back.
I just checked their diagnostics referen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107647
--- Comment #16 from Richard Biener ---
(In reply to Alexander Monakov from comment #15)
> I'm confused about the first hunk in the attached patch:
>
> --- a/gcc/tree-vect-slp-patterns.cc
> +++ b/gcc/tree-vect-slp-patterns.cc
> @@ -1035,8 +1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #3 from David Binderman ---
Another test case:
./gcc.target/i386/pr53366-2.c
==41== Conditional jump or move depends on uninitialised value(s)
==41==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==41==by 0x11DFAE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #2 from David Binderman ---
git blame says
dc95e1e970 (Hongyu Wang 2022-01-17 13:01:51 +0800 8292)if
(!bitmap_set_bit (seen, sel[i].to_constant ()))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #5 from Marco Clemencic ---
I forgot to mention that I compiled with the options:
g++ -c -Wmaybe-uninitialized -O1 -v -save-temps test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
--- Comment #4 from Marco Clemencic ---
I have a similar problem with this chunk of code:
```
#include
#include
#include
#include
#include
struct Wrapper {
using Map = std::map;
using Value = std::variant;
Wrapper(Value v) : da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #1 from David Binderman ---
The valgrind problem doesn't seem to occur with git hash 05432288d4e56055,
dated 20221113, so the bug is recent.
I used git hash 2b2f2ee49a33419f for today's build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107138
Marco Clemencic changed:
What|Removed |Added
CC||marco.clemencic at gmail dot
com
---
~/gcc/results.20221117.valgrind/bin/gcc -c -O2 ./gcc.target/i386/pr46051.c
==639651== Conditional jump or move depends on uninitialised value(s)
==639651==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==639651==by 0x11DFAE7: gimple_simplify_122(gimple_match_op*, gimple**,
tree
_node* (*)(tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930
--- Comment #2 from Jan Engelhardt ---
Subissue a) "the crash output is completely useless" seems to have been
addressed in the past already; I observe in gcc 12 that
Found plugin run function: 0x7fecaa0e01a0
AddressSanitizer:DEADLYSIGNAL
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #9 from Tamar Christina ---
(In reply to Florian Weimer from comment #8)
> (In reply to Tamar Christina from comment #4)
> > /opt/buildAgent/work/5c94c4ced6ebfcd0/libgcc/unwind-dw2-fde.c:111
> > #6 __register_frame_info (begin=, ob=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103930
Jan Engelhardt changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment #
1 - 100 of 120 matches
Mail list logo
