https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111282
--- Comment #2 from Andrew Pinski ---
Note `|` case already handled by r8-4395:
/* a | ~(a ^ b) --> a | ~b */
(simplify
(bit_ior:c @0 (bit_not:s (bit_xor:c @0 @1)))
(bit_ior @0 (bit_not @1)))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48
--- Comment #1 from Andrew Pinski ---
Note f was done in r14-3528 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
--- Comment #4 from Andreas Schwab ---
Doesn't fail here, but it uses release checking:
https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc14/openSUSE_Tumbleweed/i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110010
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #5 from Andrew Pinski ---
With the nop_convert added and using bitwise_equal_p :
(simplify
(mult:c @0 (nop_convert? (bit_ior:c (rshift @1 INTEGER_CST@2) integer_onep)))
(if (!TYPE_UNSIGNED (TREE_TYPE (@1))
&& wi::to_wide (@2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #6 from Andrew Pinski ---
Vector testcases too:
```
#define vector __attribute__((vector_size(4*sizeof(int
vector int
signed_f1(vector int v)
{
vector int b_5;
vector int _7;
vector int _9;
b_5 = v>>(sizeof(int)*8 - 1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98907
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
Thomas Schwinge changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111272
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #3 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
--- Comment #5 from Matthias Klose ---
a normal bootstrap (at least on i686-linux-gnu) succeeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111283
--- Comment #6 from Matthias Klose ---
last known successful profiled bootstrap with trunk 20230811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284
Bug ID: 111284
Summary: Some passing-by-value parameters are miscompiled since
GCC 9
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111258
--- Comment #3 from Jiang An ---
I've reduced the example and filed Bug 111284.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #7 from Manolis Tsamis ---
After some attempts to improve on this, my current solution is:
1) Do not change pointer_int_sum in c-common (otherwise codegen regressions
are observed)
2) Introduce a pattern that folds (unsigned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100059
Thomas Schwinge changed:
What|Removed |Added
Component|middle-end |other
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393
--- Comment #8 from philipp.tomsich at vrull dot eu ---
On Mon, 4 Sept 2023 at 13:38, manolis.tsamis at vrull dot eu <
gcc-bugzi...@gcc.gnu.org> wrote:
> My current match.pd pattern to do that is below; any feedback or
> improvements
> are welco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
--- Comment #3 from Thorsten Otto ---
Created attachment 55837
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55837&action=edit
Avoid segmentation fault when calling assign_temp with a NULL type pointer
Attached is a potential patch to fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26142
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:affbb7b4322a01cecddaa4dfb70faee925a2348b
commit r14-3654-gaffbb7b4322a01cecddaa4dfb70faee925a2348b
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #18 from Jerry DeLisle ---
With Johns test case from Comment #15 and the patch in Comment #17 I get the
following:
$ ./a.out
real kinds 4 8 10 16
With (A,1X,EN0.0 ) 666.
With (A,1X,EN0.0 ) 666.
With (A,1X,EN0.0 ) 666.
With (A,1X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111285
Bug ID: 111285
Summary: vector ABSU is lowered incorrectly
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
--- Comment #7 from Andrew Pinski ---
Created attachment 55838
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55838&action=edit
dg-testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110009
Andrew Pinski changed:
What|Removed |Added
Blocks||98907
--- Comment #8 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
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=111071
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:a338c5f6114f3b9f2ed067bc7738b405091a76ce
commit r14-3658-ga338c5f6114f3b9f2ed067bc7738b405091a76ce
Author: Thiago Jung Bauermann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
Bug ID: 111286
Summary: ICE on functional cast to const array reference
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111286
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287
Bug ID: 111287
Summary: doc: "strict ISO mode" definition is not up-to-date
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111287
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #1 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:56d0592db19b69e3cc217fabe5c2f8be3a75a8cf
commit r14-3660-g56d0592db19b69e3cc217fabe5c2f8be3a75a8cf
Author: Christophe Lyon
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
Bug ID: 111288
Summary: formatting mistake in HTML documentation
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #1 from Bruno Haible ---
Created attachment 55840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55840&action=edit
Rendering before applying the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238
--- Comment #2 from Christophe Lyon ---
Oops sorry I pushed an unwanted patch, which I reverted with
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=084a7cf9fb2d9cb98dfbe7d91602c840ec50b002
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #2 from Bruno Haible ---
Created attachment 55841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55841&action=edit
Rendering after applying the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #3 from Andrew Pinski ---
patches should be posted to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288
--- Comment #4 from Bruno Haible ---
My proposed patch is a correction to commit
2b4e0415ad664cdb3ce87d1f7eee5ca26911a05b by Jakub Jelinek.
> patches should be posted to gcc-patches@ after reading
> https://gcc.gnu.org/contribute.html
I do ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #20 from john.harper at vuw dot ac.nz ---
With the first test case all the EN outputs were 666. but the Fortran 2018
standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but
Table 13.2 first ENw.d line appears to requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
Bug ID: 111289
Summary: Unwarranted -Wanalyzer-va-arg-type-mismatch warning
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022
--- Comment #21 from Jerry DeLisle ---
(In reply to john.harper from comment #20)
> With the first test case all the EN outputs were 666. but the Fortran 2018
> standard 13.7.2.3.4 paragraph 2 requires that EN0.0 produce 666.E+0 but
> Table 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109638
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93006
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111274
--- Comment #11 from sandra at gcc dot gnu.org ---
OK, I've been digging around in the code. do_poplevel() only fills in
BIND_EXPR_BLOCK if stmts_are_full_exprs_p() is true. I haven't figured out the
control flow that affects the latter predica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111290
Bug ID: 111290
Summary: [11/12/13/14 Regression] Wrong code at -O0 on
x86_64-pc-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111290
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111290
--- Comment #2 from Andrew Pinski ---
```
int main()
{
int t = c;
c |= d / a;
b = (c) >= ((e %= 0x6B1D8456) > (res ^= t));
printf("%d\n", res);
}
```
gives -104
While:
```
int main()
{
c |= d / a;
int t =
46 matches
Mail list logo
