https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
--- Comment #2 from Jonathan Wakely ---
I have very little sympathy for this use case, predicates that can't be called
with const arguments are always wrong. I'm inclined to say the standard should
be fixed to match our new behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107836
--- Comment #3 from Zixuan Chen ---
I think there is a data dependency between the second asm statement and the
third, a read-after-write one. If the third one is moved to the top then we
can't get the correct value of mm5(mm0). Also, could you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107807
--- Comment #6 from Rainer Orth ---
It did in last night's Solaris bootstraps (sparc and x86). macOS bootstraps
are
super-slow, so I'll wait for tomorrow night's weekly bootstraps there and
report
back when they are finished.
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107817
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jonathan Wakely ---
> Native configuration is sparc-sun-solaris2.11
[...]
> PASS: std/format/functions/format.cc (test for excess errors)
> PASS: std/format/functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jakub Jelinek ---
> Created attachment 53953
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53953&action=edit
> gcc13-pr107815.patch
>
> Untested workarou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #11 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> It's only necessary on sparc: i386-pc-solaris2.11 PASSed even before.
> That's what I've been using successfully last night:
>
> +// Solaris h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
Bug ID: 107855
Summary: gcc.dg/vect/vect-ifcvt-18.c FAILs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
--- Comment #1 from Rainer Orth ---
Created attachment 53958
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53958&action=edit
32-bit i386-pc-solaris2.11 vect-ifcvt-18.c.172t.vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107856
Bug ID: 107856
Summary: gcc.dg/plugin/infoleak-vfio_iommu_type1.c XPASSes
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107856
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:add0f941be18cdf962a0f300019acacbf2325d41
commit r13-4283-gadd0f941be18cdf962a0f300019acacbf2325d41
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d1389be011f0fac422e98e795c55156052c4d960
commit r13-4284-gd1389be011f0fac422e98e795c55156052c4d960
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107468
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ec73b55c75baa16c1cf7482fa65928a8d45598d4
commit r13-4285-gec73b55c75baa16c1cf7482fa65928a8d45598d4
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107857
Bug ID: 107857
Summary: recursive_mutex misses destructor if non-function call
initialization is used
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
Jakub Jelinek changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107805
--- Comment #5 from CVS Commits ---
The master branch has been updated by Florian Weimer :
https://gcc.gnu.org/g:a42e39a7b974645d2820931357e99411fdb0beb6
commit r13-4286-ga42e39a7b974645d2820931357e99411fdb0beb6
Author: Florian Weimer
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107805
Florian Weimer changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
--- Comment #2 from Richard Biener ---
We see
[local count: 3508266]:
if (c_4(D) != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 2350538]:
goto ; [100.00%]
[local count: 3508266]:
# v_10 = PHI
_3 = (unsign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107838
--- Comment #2 from Richard Biener ---
I think there's a duplicate bug, we fail to pick up the controlling condition
because IVOPTs replaced the exit test but we still have
i_19 = (int) ivtmp.4_6;
if (i_19 == 0)
...
[local count: 96636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b6330a7685476fc30b8ae9bbf3fca1a9b0d4be95
commit r13-4289-gb6330a7685476fc30b8ae9bbf3fca1a9b0d4be95
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841
--- Comment #2 from Alexander ---
Source code:
void qq(int a) {
char *s = alloca(128);
sprintf(s,"qq %d",3);
}
Generated code:
040c <_qq>:
40c: 1166mov r5, -(sp)
40e: 1185mov s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
--- Comment #2 from Richard Biener ---
Can you attach the ifcvt dump as well? The issue seems to be that only the
first loop is if-converted, so floats are not handled at all (only a single
loop is vectorized).
Not sure about the runtime FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
--- Comment #3 from Rainer Orth ---
Created attachment 53959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53959&action=edit
32-bit i386-pc-solaris2.11 vect-ifcvt-18.c.171t.ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
--- Comment #4 from Rainer Orth ---
(In reply to Richard Biener from comment #2)
> Can you attach the ifcvt dump as well? The issue seems to be that only the
> first loop is if-converted, so floats are not handled at all (only a single
> loop i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107185
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107858
Bug ID: 107858
Summary: Variable in generic lambda incorrectly considered to
be a dependent name
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-11-24
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413
--- Comment #12 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:0c1b0a23f1fe7db6a2e391b7cb78cff90032
commit r13-4291-g0c1b0a23f1fe7db6a2e391b7cb78cff90032
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107859
Bug ID: 107859
Summary: Fail to optimize rot13
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840
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=106609
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107858
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107858
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469
Andrew Pinski changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91456
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:db206f15f7091382cb981ade3c75f4c3e3559ab8
commit r12-8930-gdb206f15f7091382cb981ade3c75f4c3e3559ab8
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Bug ID: 107860
Summary: Compilation failure, ambiguous fisttp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107611
Gaius Mulley changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Arnout Vandecappelle changed:
What|Removed |Added
CC||arnout at mind dot be
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609
--- Comment #15 from Sébastien Michelland ---
Thanks, turns out my bisected commit was related after all...
I can confirm that test cases from OP and #4 (with protocol from OP) are no
longer broken for me on yesterday's master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #1 from Andrew Pinski ---
Can you attach config.log from the gcc directory?
It should have done detected filds :
gcc_GAS_CHECK_FEATURE([filds and fists mnemonics],
gcc_cv_as_ix86_filds,,
[filds (%ebp); fists (%ebp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> But is it required to generate a temporary?
> As I understand it, the code is invalid, and (correctly) diagnosed, so there
> is nothing else to do.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
--- Comment #3 from Vincent Lefèvre ---
(In reply to Richard Biener from comment #2)
> it's loop invariant motion that hoists the v + v compute out of the loop
> and thus outside of its controlling condition. You can see it's careful
> to not i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
Bug ID: 107861
Summary: C++ static_assert() does not honor -fwrapv, leading to
compilation error
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
--- Comment #5 from Arnout Vandecappelle ---
Based on
> glibc builds needs to be fixed such that it does not reference the function
> in the unwinder at -O0
I've traced through the map file why this symbol is pulled in:
/.../libgcc.a(unwind-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107728
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |libgcc
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #2 from simon at pushface dot org ---
Created attachment 53960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53960&action=edit
gcc/config.log
As requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107577
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
--- Comment #3 from simon at pushface dot org ---
Created attachment 53961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53961&action=edit
gcc/config.log
As requested (this time, sorry about previous attempt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107755
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107860
Andrew Pinski changed:
What|Removed |Added
Host|x86_64-apple-darwin21 |aarch64-apple-darwin21
Bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #1 from Andrew Pinski ---
Right, this is by design and I don't think it is a bug. The reasoning is the
C++ constant expressions have a way of requiring you to having to figure out if
it was going to overflow and cause different behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #2 from Andrew Pinski ---
Note clang rejects even just:
#include
#define wrap_inc(x) ((x) + 1 < (x))
constexpr int int_max = INT_MAX;
bool b0 = wrap_inc(int_max);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #3 from Markus F.X.J. Oberhumer ---
Indeed.
And just for reference I had also reported this as clang bug in
https://github.com/llvm/llvm-project/issues/59195
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107862
Bug ID: 107862
Summary: Returning an std::vector from a lambda fails to be
constexpr, while a custom class with allocated storage
works
Product: gcc
Version: 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107862
--- Comment #1 from Andrew Pinski ---
I don't think this is valid code.
In the function dynamic_data_to_array you have:
std::array data;
But test.size() is not a constexpr unless test is a constexpr. making test a
constexpr does not work as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Bug ID: 107863
Summary: ICE with unrecognizable insn when using
-funsigned-char with some AVX builtins
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #6 from Mikael Morin ---
(In reply to anlauf from comment #5)
> (In reply to Mikael Morin from comment #4)
> > But is it required to generate a temporary?
> > As I understand it, the code is invalid, and (correctly) diagnosed, so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #7 from Petr Skocik ---
(In reply to Jakub Jelinek from comment #4)
> Say for
> void bar (char *);
> void
> foo (int x, int y)
> {
> __attribute__((assume (x < 64)));
> for (int i = 0; i < y; ++i)
> bar (__builtin_alloca (x))
ncludes:
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-src/configure --enable-languages=c,c++
--enable-multiarch --program-suffix=-trunk
gcc version 13.0.0 20221124 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #4 from Jonathan Wakely ---
Andrew is right. The C++ standard says this is ill-formed, the -fwrapv option
isn't allowed to change that.
The option means that runtime overflow is well-defined instead of undefined,
but that doesn't ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|ICE with unreco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #8 from Jakub Jelinek ---
Alloca itself doesn't touch the stack on many architectures, and the code
doesn't have to have a function call in between.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #5 from Jonathan Wakely ---
To expand on that, the standard allows compilers to do anything for undefined
behaviour, including making it valid with well-defined semantics. So wrapping
for undefined overflow is a conforming extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Andrew Pinski changed:
What|Removed |Added
Keywords||FIXME
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #1 from Andrew Pinski ---
/path/to/mycodedistr/include/mycode/grfx/_cpu/../color/../../_stdafx/_math.hpp:111:23:
internal compiler error: Segmentation fault
0x120e72f crash_signal
/home/apinski/src/upstream-gcc/gcc/gcc/toplev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #6 from Markus F.X.J. Oberhumer ---
Please note that I'm explicitly using "int_max" and not "INT_MAX", and I'd
appreciate if you could give me a link where the standard says this is
"ill-formed". Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
--- Comment #3 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #7 from Jonathan Wakely ---
(In reply to Markus F.X.J. Oberhumer from comment #6)
> Please note that I'm explicitly using "int_max" and not "INT_MAX",
It's a constexpr variable with the same value, so that makes no difference
whatso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107158
--- Comment #9 from urs at akk dot org ---
After commit ce917b0422c145779b83e005afd8433c0c86fb06 this doesn't show up
anymore.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107850
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=107819
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #6)
> (In reply to anlauf from comment #5)
> > Second, I stumbled over:
> >
> > ! 15.5.2.3 Argument association
> > ! (4) A present dummy argument with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #2 from Andrew Pinski ---
Hmm, I don't know if I reduced it too much but this might be __bfloat16_t
related ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #8 from Mikael Morin ---
(In reply to anlauf from comment #3)
> Could need help by some expert on this...
I guess I qualify as expert.
Reading the code again after years, it is not exactly crystal clear...
Here is a dump of what I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Hmm, I don't know if I reduced it too much but this might be __bfloat16_t
> related ...
It is not, I changed 0.0bf16 to just 0.0f and it fails. still reducing i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> int_max+1 is not a core constant (C++20 7.7 [expr.const] paragraph 5, bullet
oops, s/core constant/core constant expression/
> 5.7), so is not usable as th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.1.0, 11.1.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Andrew Pinski changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #7)
>
> In the meantime, do you have an idea where to force the generation of a
> temporary? I've been scrolling through gfc_conv_procedure_call to see
> if that might be th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
--- Comment #18 from Sergei Trofimovich ---
The fix also fixed all initial llvm-12's test suite failures for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #14 from Michael_S ---
I tested a smaller test bench from Comment 3 with gcc trunk on godbolt.
Issue appears to be only partially fixed.
-Ofast result is no longer a horror that it was before, but it is still not as
good as -O3 or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #8 from Brjd ---
__get_cpuid(0): eax=0xa, ebx=0x756e6547, ecx=0x6c65746e, edx=0x49656e69
__get_cpuid(1): eax=0x106ca, ebx=0x20800, ecx=0x40e39d, edx=0xbfe9fbff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107864
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106201
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3892251498c16c9507cf8471f4f10676212e9ead
commit r13-4292-g3892251498c16c9507cf8471f4f10676212e9ead
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Hongtao.liu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #5 from Hongtao.liu ---
Also I get below from build_common_tree_nodes
/* Define `char', which is like either `signed char' or `unsigned char'
but not the same as either. */
char_type_node
= (signed_char
? make_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:f120196382ac5ac49ec4a60f8abad42f22d45a91
commit r13-4294-gf120196382ac5ac49ec4a60f8abad42f22d45a91
Author: Kewen.Lin
Date: Thu Nov 24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107865
Bug ID: 107865
Summary: [12/13 Regression] ICE in verify_loop_structure, at
cfgloop.cc:1748 (Error: loop 3's number of iterations
'_61 > 0 ? (uint128_t) (_61 + -1) : 0' references the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #6 from Hongtao.liu ---
For pattern
(set (reg:QI 607)
(const_int 255 [0xff]))
general_operand return false for op const_int 255 QImode since
trunc_int_for_mode (INTVAL (op), mode) return -1, INVAL (op) is 255.
---cut from gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #7 from Hongtao.liu ---
> - if (width < HOST_BITS_PER_WIDE_INT)
> + if (width < HOST_BITS_PER_WIDE_INT
> + && (mode != QImode || !flag_signed_char))
typo should be
+ && (mode != QImode || flag_signed_char))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
--- Comment #8 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #7)
> > - if (width < HOST_BITS_PER_WIDE_INT)
> > + if (width < HOST_BITS_PER_WIDE_INT
> > + && (mode != QImode || !flag_signed_char))
> typo should be
> + &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107865
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
1 - 100 of 101 matches
Mail list logo
