https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106923
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107865
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
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=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=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 #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=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=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=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=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=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=107864
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
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=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=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=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=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=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=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
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=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 #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 #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=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=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=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=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 #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=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=107863
Andrew Pinski changed:
What|Removed |Added
Keywords||FIXME
--- Comment #2 from Andrew Pinski
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=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=107863
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|ICE with unreco
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
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=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))
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=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=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=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=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=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 #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=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=107860
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
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
--- 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=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 #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=107728
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |libgcc
Status|RESOLVED
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=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=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=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=107860
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
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=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=107728
Arnout Vandecappelle changed:
What|Removed |Added
CC||arnout at mind dot be
--- Commen
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=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=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=84469
Andrew Pinski changed:
What|Removed |Added
CC||pilarlatiesa at gmail dot com
--- Commen
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=107858
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
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=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=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=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=106609
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-11-24
Status|UNCONFIRM
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=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=107185
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolu
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=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 #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=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=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=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=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=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=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=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=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=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=107815
Jakub Jelinek changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comment
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=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=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=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=107856
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=107855
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |13.0
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
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=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=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=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=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=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
1 - 100 of 101 matches
Mail list logo
