https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #19 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Kaz Kylheku from comment #17)
> > The standrad does not define the conversion at the *type* level.
> > ...
> > The program is strictly conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46116
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114494
--- Comment #6 from Akihiko Odaki ---
(In reply to Hans-Peter Nilsson from comment #5)
> (In reply to Akihiko Odaki from comment #0)
> > if (hlen < sizeof(struct ip_header)) {
>
> Is this a typo for "if (hlen > sizeof(struct ip_header)) {"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66630
--- Comment #5 from Andrew Pinski ---
(In reply to Marek Polacek from comment #2)
> That's one thing. But there also something else going on. I hope it's just
> missing TYPE_OVERFLOW_SANITIZED in some match.pd patterns.
```
/* ~A + A -> -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64662
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114560
Meirav Grimberg changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64565
Andrew Pinski changed:
What|Removed |Added
CC||mikulas at artax dot
karlin.mff.cu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64545
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254
Andrew Pinski changed:
What|Removed |Added
CC||jg at jguk dot org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90039
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59518
Andrew Pinski changed:
What|Removed |Added
Depends on||54254
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56755
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254
Andrew Pinski changed:
What|Removed |Added
CC||dungtq1387 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54254
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55634
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #37 from Jerry DeLisle ---
Created attachment 57855
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57855=edit
Preliminary patch to address some incorrect behavior
This attached patch, gives some better results for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
--- Comment #5 from Andrew Pinski ---
Found potential split point: if (f.12_35 <= _25)
{ 3 + I*-1 } le_expr 2147483647 - _2
Applying pattern match.pd:6064, generic-match-4.cc:1699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #36 from Jerry DeLisle ---
Created attachment 57854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57854=edit
Modified extended test case
I modified the extended test case so I could review this and summarize.
Currently this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114568
Bug ID: 114568
Summary: [14 regression] g++.dg/vect/pr84556.cc fails to
produce executable since r14-9706-gb8e7aaaf350a45
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Kewen Lin changed:
What|Removed |Added
Target Milestone|--- |15.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
Bug ID: 114567
Summary: rs6000: explicit _Float128 doesn't generate optimal
code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114476
--- Comment #7 from JuzheZhong ---
Hi, Robin.
Will you fix this bug ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309
Kewen Lin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107945
Brian Bi changed:
What|Removed |Added
CC||bbi5291 at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114556
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114556
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|middle-end
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114559
Andrew Pinski changed:
What|Removed |Added
Known to work||8.5.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114559
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114558
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Also since you are using a redhat provided compiler you should be reporting
> it to them.
>From the pytorch issue even:
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114558
--- Comment #2 from Andrew Pinski ---
Also since you are using a redhat provided compiler you should be reporting it
to them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114551
--- Comment #3 from Andrew Pinski ---
The first major difference with/without continue is the moving of `f >
(2147483647 - a)` checkout of the loop via lim2 in the case of not having the
continue.
You can replace the inner most loop with:
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55581
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
--- Comment #5 from Gaius Mulley ---
Closing now the patch has been bootstrapped, compared and applied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114565
--- Comment #4 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:1bafa6a3fdbb53651ffa5d854c2341c487bf3269
commit r14-9764-g1bafa6a3fdbb53651ffa5d854c2341c487bf3269
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #12 from Jason Merrill ---
(In reply to Iain Sandoe from comment #11)
> SO I suppose the question is do we want to figure out why the opt is failing
> (knowing that if it succeeds that is a secondary issue) - or just
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53593
--- Comment #4 from Andrew Pinski ---
here is the latest link:
https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2024-1/prefetch-noprefetch.html
So reading the page, it is only can be used when AVX512 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #11 from Iain Sandoe ---
(In reply to Jason Merrill from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> > > So I am actually asking if the extension actually has any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
--- Comment #9 from Andrew Pinski ---
*** Bug 46679 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46635
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #5 from kargls at comcast dot net ---
(In reply to anlauf from comment #4)
> (In reply to kargls from comment #3)
> > Created attachment 57109 [details]
> > patch
> >
> > The attached patch has been regtested. There were no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46116
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
--- Comment #5 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:871bb5ad2dd56343d80b6a6d269e85efdce5
commit r14-9763-g871bb5ad2dd56343d80b6a6d269e85efdce5
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #10 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Iain Sandoe from comment #7)
> > So I am actually asking if the extension actually has any useful meaning?
>
> For non-darwin, yes, it requests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41088
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320
Bug 36320 depends on bug 36453, which changed state.
Bug 36453 Summary: [DR 412] PR36320 breaks boost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570
Andrew Pinski changed:
What|Removed |Added
CC||mueller at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #18 from Harald van Dijk ---
(In reply to Kaz Kylheku from comment #17)
> The standrad does not define the conversion at the *type* level.
> ...
> The program is strictly conforming because it has no problem with type.
The DRs I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.5
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
Andrew Pinski changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31782
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515
--- Comment #9 from Jeffrey A. Law ---
Thanks for that info Edwin -- my tester flagged them too and mentally I'd
figured it was most likely the combiner change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #8 from Andrew Pinski ---
(In reply to Yuxuan Shui from comment #7)
> Looks similar to Bug 110027, but ASAN is not involved here.
Right, someone will need to debug it but I looked at the patch for PR 110027
and it is ASAN specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #9 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #7)
> So I am actually asking
> - if the extension actually has any useful meaning?
YES it does. Especially when it comes to the ability to reduce space used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #8 from Jonathan Wakely ---
(In reply to Iain Sandoe from comment #7)
> So I am actually asking
> - if the extension actually has any useful meaning?
For non-darwin, yes, it requests the storage of two initializer lists to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
--- Comment #3 from Michael Ragazzon ---
(In reply to Andrew Pinski from comment #2)
> std::vector is a different issue and filed as PR 18.
Thanks for pointing me in the right direction. I believe the warnings in the
description points to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #7 from Yuxuan Shui ---
Looks similar to Bug 110027, but ASAN is not involved here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #5 from Yuxuan Shui ---
And -fstack-protector-strong is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
--- Comment #2 from Andrew Pinski ---
(In reply to Michael Ragazzon from comment #1)
> I seem to also have encountered this issue while using `std::vector`.
> Here is a relatively small reproducer.
std::vector is a different issue and filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515
--- Comment #8 from Edwin Lu ---
(In reply to Robin Dapp from comment #7)
> There is some riscv fallout as well. Edwin has the details.
I haven't done an in depth analysis but the full list of new riscv scan-dump
failures can be found here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #4 from Yuxuan Shui ---
Reduced a bit further:
void setup_tone_curves(float binHz, float center_decay_rate) {
float workc[8][56];
memset(workc, 0, sizeof(workc));
for (int j = 0; j < 8; j++) {
for (int k = 0; k < 56;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498
Michael Ragazzon changed:
What|Removed |Added
CC||michael.ragazzon at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
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=111067
--- Comment #7 from Iain Sandoe ---
however:
1) it is not in the gnu:: namespace the tests just have it as [[ ]].
2) I do not think that the standard has anything to say about how entities at
file scope are ordered in memory (many/most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #3 from Yuxuan Shui ---
Roughly reduced example:
#include
#include
#define toOC(n) (log(n)*1.442695f-5.965784f)
float *setup_tone_curves(float binHz,
float center_decay_rate) {
float workc[8][56];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:21aa57e73b820395b7b01843d61ef5b84cd20d02
commit r14-9761-g21aa57e73b820395b7b01843d61ef5b84cd20d02
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #6 from Jonathan Wakely ---
Yes, I think it's an extension, added by r14-1500-g4d935f52b0d5c0
The question then is whether the attribute is supposed to be a non-binding
request or not.
If it's a non-binding request then the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
--- Comment #5 from GCC Commits ---
The master branch has been updated by Tom Tromey :
https://gcc.gnu.org/g:ca2f7c84927f85b95f0f48f82b93f1460c372db4
commit r14-9760-gca2f7c84927f85b95f0f48f82b93f1460c372db4
Author: Tom Tromey
Date: Sat Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #17 from Kaz Kylheku ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Joseph S. Myers from comment #11)
> > I think that simply failing to say whether a value of type X may be
> > converted to type Y is clearly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
Mikael Morin changed:
What|Removed |Added
Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #2 from Yuxuan Shui ---
/nix/store/qp3k692bxjhlzvsdqpq7mdylfyr7i1ln-gcc-wrapper-13.2.0/bin/gcc
-I/tmp/vorbis/include -I/tmp/vorbis/lib -O3 -march=znver4 -mtune=znver4 -g -o
psy.c.o -c /tmp/vorbis/lib/psy.c -v
Using built-in specs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> (In reply to Paul Thomas from comment #3)
> > I can see why the assert is there but it is manifestly wrong for both the
> > assumed length target and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #16 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #15)
> In the cases where there is no statement either way, the behavior is
> undefined as a property of the translation unit (not just of the execution):
> it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111066
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:f650cfccc61f0352f9c3a0993457e1cb7845bc7a
commit r13-8564-gf650cfccc61f0352f9c3a0993457e1cb7845bc7a
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515
Robin Dapp changed:
What|Removed |Added
CC||ewlu at rivosinc dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114547
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:2f2924078ce51c2a0da3ad8f958f2d1de533969a
commit r14-9759-g2f2924078ce51c2a0da3ad8f958f2d1de533969a
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:22510e4a68aa9ca850db34ae62c21c58442d8ab3
commit r13-8560-g22510e4a68aa9ca850db34ae62c21c58442d8ab3
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #11 from Matthias Klose ---
while not a test case, that was seen when running autopkg tests of the evolver
package against glibc 2.39 packages.
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2052929
the failing evolver test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:daa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c
commit r14-9758-gdaa2e7c7ffe49b788357f7f2c9ef1c9b125c1f8c
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Bug ID: 114566
Summary: Misaligned vmovaps when compiling libvorbis for znver4
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #15 from Joseph S. Myers ---
There are several statements such as "Any pointer type may be converted to an
integer type." and "A pointer to an object type may be converted to a pointer
to a different object type.", that allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114562
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:5d7e9a35024f065b25f61747859c7cb7a770c92b
commit r14-9757-g5d7e9a35024f065b25f61747859c7cb7a770c92b
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:5d7e9a35024f065b25f61747859c7cb7a770c92b
commit r14-9757-g5d7e9a35024f065b25f61747859c7cb7a770c92b
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #14 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or
1 - 100 of 230 matches
Mail list logo
