https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #2 from Patrick O'Neill ---
Created attachment 57641
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57641&action=edit
unreduced preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
Bug ID: 114262
Summary: Over-inlining when optimizing for size?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #1 from Andrew Pinski ---
I thought it was documented that gnu_inline also causes always_inline if
optimization is turned on but I can't seem to find that ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #2 from LIU Hao ---
(In reply to Andrew Pinski from comment #1)
> I thought it was documented that gnu_inline also causes always_inline if
> optimization is turned on but I can't seem to find that ...
Is that the case in GCC source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #3 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253
--- Comment #4 from Andrew Pinski ---
VIEW_CONVERT_EXPR(pid$4_26)
Where I have seen this before ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #4 from LIU Hao ---
(In reply to Andrew Pinski from comment #3)
> It looks like it has been this way since r0-37737-g4838c5ee553f06 (2001) (or
> rather that is when it was used by the tree inline; I don't want to dig
> further back t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114253
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114262
--- Comment #5 from Andrew Pinski ---
(In reply to LIU Hao from comment #4)
> The only difference between the C99 `extern inline` and C++ `extern inline`
> is that the C++ external definition is COMDAT.
Well not really. comdat changes heurstic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-checking|
--- Comment #6 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:03932d3203bce244edd812b81921c2f16ea18d86
commit r14-9348-g03932d3203bce244edd812b81921c2f16ea18d86
Author: Jerry DeLisle
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
Andrew Pinski changed:
What|Removed |Added
Summary|Multiple 554.roms_r |[14 regression] Multiple
ctual: 66`. The bug won't reproduce if I specify C++ standard
before C++20, or if I don't disable strict-aliasing optimization.
Changing the size of A::y affects the number of bytes that are correctly copied
in the output. The bug reproduces in gcc 13.2.0 and from the latest
releases/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263
--- Comment #1 from Andrew Pinski ---
This sounds almost the same as what is mentioned in PR 113359 ("is changed by
SRA to only store 64 + 32 bits into the std::pair rather than 64 + 64 bits.").
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114263
--- Comment #2 from Andrew Pinski ---
the testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359#c15 makes
it even more likely the same as this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114200
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114195
--- Comment #2 from Li Pan ---
Trigger below assert in vectorizable_store, the loop_vinfo use_partial,
fully_masked and fully_lens are all true here.
/* Shouldn't go with length-based approach if fully masked. */
gcc_assert (!loop_lens || !loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #3 from Alexander Monakov ---
The first attachment is empty (perhaps you made a non-recursive archive when
you meant to recursively zip a directory).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
--- Comment #10 from rguenther at suse dot de ---
On Wed, 6 Mar 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114252
--- Comment #7 from Richard Biener ---
Note I do understand what you are saying, just the middle-end in detecting and
using __builtin_bswap32 does what it does everywhere else - it checks whether
the target implements the operation.
The middle-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:95b6ee96348041eaee9133f082b57f3e57ef0b11
commit r14-9350-g95b6ee96348041eaee9133f082b57f3e57ef0b11
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
Patrick O'Neill changed:
What|Removed |Added
Attachment #57640|0 |1
is obsolete|
201 - 224 of 224 matches
Mail list logo