https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95446
--- Comment #2 from Martin Diehl ---
many thanks for the quick reply!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #2 from Markus Böck ---
I printed the size of the struct and it yielded 36. Interestingly, using clang
instead yields 32 like on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95052
--- Comment #13 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dc8c02ca1cd18f8c22d70cf17b47125fc25ab243
commit r11-748-gdc8c02ca1cd18f8c22d70cf17b47125fc25ab243
Author: Jakub Jelinek
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
--- Comment #6 from CVS Commits ---
The master branch has been updated by Thomas Kथà¤nig :
https://gcc.gnu.org/g:811f902b764c5a13178cbd7588e96c16b3fab504
commit r11-749-g811f902b764c5a13178cbd7588e96c16b3fab504
Author: Thomas Koenig
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #2 from Pádraig Brady ---
The test case is in bug #70462.
Copying here...
g++ -std=c++11 -c -o t.o -x c++ - << EOF
struct Bar final
{
Bar();
};
Bar::Bar()
{}
EOF
$ nm t.o | grep C2 || echo ABI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95449
Bug ID: 95449
Summary: void_t does not work with some uses of vector_size
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #22 from Avi Kivity ---
@Iain: if you can publish your patches somewhere we can test them with our
codebase and report.
(if you can publish them on releases/gcc-10 that's even better).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95449
Lars Bonnichsen changed:
What|Removed |Added
Attachment #48646|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #3 from Pádraig Brady ---
I've not got a reduced example where clang is generating the call, but it could
be a linker issue as the two constructors are aliased to the same address.
The linker used here was lld.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
Bug ID: 95450
Summary: [10 regression] Wrong long double folding
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #23 from Iain Sandoe ---
(In reply to Avi Kivity from comment #22)
> @Iain: if you can publish your patches somewhere we can test them with our
> codebase and report.
>
> (if you can publish them on releases/gcc-10 that's even better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #1 from David Malcolm ---
gcc_jit_context_dump_reproducer_to_file runs in the testsuite, and I see it
generating sane-looking reproducers (with non-empty create_code functions).
Are you calling gcc_jit_context_dump_reproducer_to_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95451
Bug ID: 95451
Summary: [8/9/10 regression] ICE for lambda capturing this and
calling operator()
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95451
--- Comment #1 from Max ---
I just noted this is a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90480, although the other bug
report neither mentions the workaround nor 86594. I guess I need to improve my
search skills :/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95452
Bug ID: 95452
Summary: Overflow Bug in GNAT Heapsort implementations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95453
Bug ID: 95453
Summary: Failure to avoid useless sign extension
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #2 from bouanto at zoho dot com ---
Created attachment 48648
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48648&action=edit
Reproducer for the bug
Oh, I see what I was doing wrong: I thought it was an option, so I was calling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #3 from David Malcolm ---
Aha - thanks.
Re-reading
https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging
it looks like the documentation for these entrypoints could use some
clarification on whether each one relates to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92838
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95453
Andrew Pinski changed:
What|Removed |Added
Keywords||ABI
--- Comment #1 from Andrew Pinski -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95454
Bug ID: 95454
Summary: type-level nodiscard not applied to constructors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #15 from Asher Gordon ---
(In reply to Luc Van Oostenryck from comment #14)
> I've now changed Sparse's default so that these warnings are not issued
> anymore.
Thanks Luc.
(In reply to Tom Tromey from comment #7)
> The feature was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #4 from Andrew Pinski ---
Looks like:
unsigned short int __cs_selector;
- unsigned short int __opcode;
+ unsigned int __opcode:11;
+ unsigned int __unused4:5;
For Windows ABI, the int causes the bitfield to start at the next 4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Looks like:
>unsigned short int __cs_selector;
> - unsigned short int __opcode;
> + unsigned int __opcode:11;
> + unsigned int __unused4:5;
>
> For Window
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #6 from Uroš Bizjak ---
(In reply to Thomas Koenig from comment #3)
> Adding the author of the patch.
>
> Uros: I find no discussion of this patch on the fortran mailing list.
> Please remember to do so in the future if you touch the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95087
--- Comment #2 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:1bb808504643e6c3c0df0fdd68a941ed2a64c7f0
commit r11-758-g1bb808504643e6c3c0df0fdd68a941ed2a64c7f0
Author: Iain Sandoe
Date: Sun M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #7 from Uroš Bizjak ---
Created attachment 48649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48649&action=edit
Untested patch.
Can someone with an access to MinGW target please test the attached patch?
The layout is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95420
--- Comment #2 from Iain Buclaw ---
With some confidence, I'm going to say that the intended cpu that should have
been set is "generic-armv7-a", and not "armv7-a".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #35 from wschmidt at linux dot ibm.com ---
Hi Jeff,
Just a quick comment. We should never discuss raw runtimes of SPEC
benchmarks on Power hardware in public. It's okay to talk about
improvements (>12% in this case), but not wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #8 from Markus Böck ---
Tested the above patch and the build failure is gone now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95418
--- Comment #9 from Thomas Koenig ---
(In reply to Uroš Bizjak from comment #6)
> Thomas,
>
> Contrary to my other libgfortran contribution, I was under the impression
> that the patch touches only deep architectural details of the x87 chip, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151
Bug 95151 depends on bug 95444, which changed state.
Bug 95444 Summary: Incorrect constraints on length operand in cmpstrnqi patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95444
H.J. Lu changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151
H.J. Lu changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70053
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #8)
> I see no conversion there?
>
> But, why does it it store to memory at all?
Yes, no conversion for this case, only adjust_address to TImode. mem/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93429
--- Comment #1 from CVS Commits ---
The master branch has been updated by Feng Xue :
https://gcc.gnu.org/g:32633ec815b4d741a9a4b1b75de235844f6d691c
commit r11-763-g32633ec815b4d741a9a4b1b75de235844f6d691c
Author: Feng Xue
Date: Fri Jan 24 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455
Bug ID: 95455
Summary: ICE in capture with initializer in requires block
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
41 matches
Mail list logo
