https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #13 from Martin Liška ---
I can confirm the reduced test-case is fixed, however the original file is
still not. I've created: https://bugs.libcamera.org/show_bug.cgi?id=185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109041
--- Comment #5 from Martin Liška ---
I can't reproduce the warning with the provided test-case :/ What options do
you use?
||r13-6101-g4d3b7be281e73ecd
Status|UNCONFIRMED |NEW
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Started with r13-6101-g4d3b7be281e73ecd.
||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org
--- Comment #3 from Martin Liška ---
Started with r8-7648-g8859913ea3cbefdc.
||marxin at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #6 from Martin Liška ---
Yes, one can see the heuristics with -fdump-tree-profile_estimate as Richi
showed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
--- Comment #5 from Martin Liška ---
*** Bug 109050 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109050
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108060
--- Comment #4 from Martin Liška ---
(In reply to Martin Liška from comment #3)
> @Marek, can you please take a look?
PING please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
--- Comment #3 from Martin Liška ---
(In reply to Richard Biener from comment #2)
> Are you sure it's not really stuck? Is it linking many target libs in
> parallel?
Dunno, it's slow even on a reasonably fast machine, so I can imagine it can
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: arm-linux-gnueabi
I've just noticed that a slower cross compiler buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108995
Martin Liška changed:
What|Removed |Added
Summary|Missed signed integer |Missed signed integer
|1
CC||marxin at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Summary|[13 Regression] LLVM JIT|[13 Regression] LLVM JIT
|segfaults in libgcc after |segfaults in libgcc after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109036
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, jakub at gcc dot gnu.org
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #14 from Martin Liška ---
(In reply to Marek Polacek from comment #13)
> I would really not like to do that, the false positives rate is pretty low.
You right! I noticed the warning for about 3 packages of 3300 we have in a
testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972
Martin Liška changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108963
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-03-02
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #12 from Martin Liška ---
(In reply to Marek Polacek from comment #11)
> No, because as Comment 9 says, there's no good way to suppress the warning.
> I'm currently leaning towards closing the BZ and suggesting adding a #pragma
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Martin Liška changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #10 from Martin Liška ---
@Marek, is there any progress on this?
||marxin at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Summary|[11/12/13 Regression] ICE: |[11/12/13 Regression] ICE:
|verify_gimple failed|verify_gimple failed
|(error
||jason at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Martin Liška ---
Started likely with r9-1493
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #12 from Martin Liška ---
(In reply to jbeulich from comment #9)
> (In reply to Jakub Jelinek from comment #1)
> > How does that look like a gcc bug? It is either a binutils bug for not
> > accepting it anymore, or ffmpeg-4 bug for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941
--- Comment #2 from Martin Liška ---
Well, I just noticed clang transforms it into:
$ clang libavformat.i -w -S -O2 -o /dev/stdout | grep shr
shrl$255, %eax
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jbeulich at suse dot com
Target Milestone: ---
Since the following binutils revision:
commit c34d1cc9200ae24dc7572aaf77d80276c0490e9b
Author
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
Martin Liška changed:
What|Removed |Added
Known to fail||12.2.0
Known to work|
,
||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Test-case:
$ cat pr108881.i
typedef float __m256 __attribute__((__vector_size__(32)));
__attribute__((__vector_size__(16 * sizeof(short short res2;
__m256 x3, x4;
avx512bf16_test() { res2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108843
--- Comment #4 from Martin Liška ---
Reduced test-case where adding -g takes 20x longer to compile:
$ typedef uint16_t;
typedef uint32_t;
typedef uint64_t;
(safe_rshift_func_int8_t_s_s)() {}
struct S0 {
signed f0 : 5
};
union U1 {
short f0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108843
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
,
||marxin at gcc dot gnu.org
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
|ICE in prep_operand, at |ICE in prep_operand, at
|cp/call.cc:6325 |cp/call.cc:6325 since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108793
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108792
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
:
|verify_gimple failed|verify_gimple failed since
||r12-2733-g31855ba6b16cd138
CC||marxin at gcc dot gnu.org
--- Comment #7 from Martin Liška ---
Btw. started with r12-2733-g31855ba6b16cd138.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108904
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108903
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #10 from Martin Liška ---
I've filed an upstream review request:
https://reviews.llvm.org/D144424
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #9 from Martin Liška ---
(In reply to Jakub Jelinek from comment #8)
> Sure, we want to keep using libbacktrace. But libbacktrace can be extended
> if Ian is ok with it, or some extensions can be done on the
> libsanitizer/libbacktr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #7 from Martin Liška ---
So clang uses __sanitizer::LLVMSymbolizer:
$ clang jhead.i -fsanitize=address -g && strace -f -s512 ./a.out 2>&1 | grep
execv
execve("./a.out", ["./a.out"], 0x7fffd520 /* 116 vars */) = 0
[pid 5529] exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #6 from Martin Liška ---
> so I wonder if emitting the locations isn't just wasted .rodata if libasan
> considers it being a windows_padding. In GCC 12 libsanitizer it was still
> location:
You are correct, we lost the ability to p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #5 from Martin Liška ---
Thank you Jakub for the investigation. I'm saying yes, using symbol names from
debuginfo seems to me a nice improvement. Lemme take a look at it..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108817
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834
--- Comment #2 from Martin Liška ---
So the module name is a string that is displayed when an ASAN error happens and
I see a discrepancy in between GCC and Clang (with LTO):
$ cat jhead.i
int x;
int *p;
int main() {
p = &x;
*(p + 1) = 123;
|--- |13.0
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed||2023-02-17
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #10 from Martin Liška ---
(In reply to David Binderman from comment #9)
> Created attachment 54463 [details]
> C source code
>
> After a further hour of reduction, a partially reduced program.
>
> cvise doesn't seem able to make mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
--- Comment #8 from Martin Liška ---
Wow, you reduced that really fast Jakub!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
--- Comment #2 from Martin Liška ---
(In reply to Jakub Jelinek from comment #1)
> Does firefox really use -fimplicit-constexpr and -g1?
Yes. Note the former option is used since gcc12:
https://bugzilla.mozilla.org/show_bug.cgi?id=1754752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
Martin Liška changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #4 from Mart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108773
Martin Liška changed:
What|Removed |Added
Summary|internal compiler error: in |[13 Regression] ICE in
||2023-02-13
Ever confirmed|0 |1
CC||marxin at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
I can reproduce that I'm reducing that right now..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-02-13
Status|UNCONFIRME
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Noticed that in Firefox
,
||marxin at gcc dot gnu.org
Summary|[13 Regression] ICE in |[13 Regression] ICE in
|verify_loop_structure, at |verify_loop_structure, at
|cfgloop.cc:1748 |cfgloop.cc:1748 since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101099
Martin Liška changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #22 from Martin Liška ---
Thank you Jakub, please revert my documentation patch if you are convinced
enough the change works only on old VIA CPUs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631
--- Comment #3 from Martin Liška ---
(In reply to Arthur Cohen from comment #2)
> Patch looks good to me Martin, thank you. Will you push it directly?
Do you see reasonable allocations when you run -fmem-report w/
--enable-gather-detailed-mem-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #4 from Martin Liška ---
Yes, noipa attribute is there for some time and I think we commit to support it
in the future.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #11 from Martin Liška ---
>
> Well, most definitely the new decls target options need to be
> instantiated?
Then it must be a tree pass that will properly call set_current_function :/ The
multiple_target pass is an IPA pass. Can w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
--- Comment #15 from Martin Liška ---
Your patch might work.
> In fact, I wonder why get_available_features isn't called unconditionally
Yes, I would also expect that, but it was not the case even before the big
refactoring in g:1890f2f0e210ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108470
--- Comment #2 from Martin Liška ---
Apparently, we support 'noipa' attribute for more than 5 years and so it should
be used rather than noiline attribute. Or do you need to support an older
toolchain as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438
--- Comment #11 from Martin Liška ---
(In reply to Bernie Innocenti from comment #10)
> Still present on GCC 12.2.
>
> Could someone look into it please, or point me at the point in ipa-icf.cc
> where the array-bounds analysis information shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
--- Comment #8 from Martin Liška ---
(In reply to Richard Biener from comment #7)
> -fno-move-loop-stores disables the store motion.
Ok, so I can confirm both -fno-move-loop-stores or -fprofile-update=atomic lead
to properly collected numbers w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #15 from Martin Liška ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Martin Liška from comment #10)
> > > where the XOR16 is implemented as:
> > >
> > > #define XORN(in1,in2,out,len) \
> > > do {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #13 from Martin Liška ---
Got it:
https://sourceforge.net/p/ddrescue/tickets/6/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #12 from Martin Liška ---
(In reply to Sam James from comment #11)
> Can you drop a link in here if/when reported upstream? Thanks
I was unable to find a bugzilla insntance for the dd_rescue project. Is there
any?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #9 from Martin Liška ---
Actually, looking at the tree dumps before and after the revision, it's leading
to a different place:
First difference happens in:
test_aes.ltrans0.ltrans.116t.dse2
[local count: 8687547526]:
- _118 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #8 from Martin Liška ---
Ok, one suspicious casting of memory comes from:
typedef union _roundkey {
unsigned char data[16];
unsigned int data32[4];
} roundkey;
...
typedef struct _sec_fields {
...
roundkey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108702
Martin Liška changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #6 from Martin Liška ---
(In reply to Andrew Pinski from comment #5)
> I am 99% sure there is aliasing violations in this code too:
> #if _MSC_VER
> #define GETU32(p) SWAP(*((u32 *)(p)))
> #define PUTU32(ct, st)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108711
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-02-08
Ever confirmed|0
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Host: i586-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #4 from Martin Liška ---
(In reply to Andrew Pinski from comment #2)
> Also does adding -fno-strict-aliasing help?
Yes, it helps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
--- Comment #3 from Martin Liška ---
(In reply to Andrew Pinski from comment #1)
> We need a better testcase than the direction on how to build a full package.
Sure, I'll try to reduce it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108698
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0
gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
The following is isolated from python-scipy package:
$ cat scipy.ii
template struct ndarray {};
template decltype(T() + 1.) median(ndarray);
struct Trans_NS_functor_median {
template void operator()(Types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-02-07
Target Milestone|---
Keywords: wrong-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
Since the r13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108135
--- Comment #9 from Martin Liška ---
Thank you for the fix, I can confirm all Modula-2-related issues are gone now.
|NEW
CC||iains at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Last reconfirmed||2023-02-06
--- Comment #3 from Martin Liška ---
Reduced to something that might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108660
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever
16-g6324c52bba490baa
CC||jason at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
--- Comment #4 from Martin Liška ---
Started with r11-2016-g6324c52bba490baa.
||) since
||r10-7441-ga7ea3d2ced786c45
CC||marxin at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Last reconfirmed||2023-02-06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Martin Liška changed:
What|Removed |Added
Summary|[13 Regression] ice in |[13 Regression] ice in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551
--- Comment #13 from Martin Liška ---
Thanks, I can confirm it's fine now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at redhat dot com
Target Milestone: ---
The following ICEs:
$ int
test_collapse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612
--- Comment #5 from Martin Liška ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54383 [details]
> Proposed fix v2
>
> Here is version 2 of the proposed fix which should also help resolve
> PR modula2/108551.
>
> Note a new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758
Martin Liška changed:
What|Removed |Added
CC||Mayshao-oc at zhaoxin dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108509
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108628
Martin Liška changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
201 - 300 of 5821 matches
Mail list logo
