https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
Bug ID: 67607
Summary: Failure to perform constant folding through type
conversion
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67606
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
--- Comment #1 from Marc Glisse ---
In general, for unsigned x, 1+(unsigned long)(x-1) can be simplified to x only
if we know that x!=0, so we would need VRP information.
Maybe this could be handled as part of the type-promotion work. VRP could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67607
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
Urja Rannikko changed:
What|Removed |Added
CC||urjaman at gmail dot com
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #27 from Paul Thomas ---
Author: pault
Date: Thu Sep 17 09:09:34 2015
New Revision: 227855
URL: https://gcc.gnu.org/viewcvs?rev=227855&root=gcc&view=rev
Log:
2015-09-17 Paul Thomas
PR fortran/52846
PR fortran/6758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588
--- Comment #3 from Paul Thomas ---
Author: pault
Date: Thu Sep 17 09:09:34 2015
New Revision: 227855
URL: https://gcc.gnu.org/viewcvs?rev=227855&root=gcc&view=rev
Log:
2015-09-17 Paul Thomas
PR fortran/52846
PR fortran/67588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67597
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588
--- Comment #5 from Vittorio Zecca ---
I believe that
use_list = module_list;
at line module.c:805 is useless and can be expunged.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Eric Botcazou changed:
What|Removed |Added
CC||bonzini at gnu dot org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67608
Bug ID: 67608
Summary: ICE when capturing a local 2D array
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67608
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588
--- Comment #6 from Paul Thomas ---
(In reply to Vittorio Zecca from comment #5)
> I believe that
>
> use_list = module_list;
>
> at line module.c:805 is useless and can be expunged.
I don't think so Up to that point, use_list is set to po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #18 from Bernd Schmidt ---
FWIW I did some googling to refresh my memory, and this may be helpful:
www.seas.harvard.edu/courses/cs252/2011sp/slides/Lec02-Dataflow.pdf
It looks like you want exactly the available expressions problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67597
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Alexandre Oliva from comment #4)
> Mine. AFAICT this is fixed in the git branch aoliva/pr64164, that moves rtl
> allocation of parms and results back to assign_parms.
Thanks. I can confir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67490
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65958
--- Comment #5 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 11:06:57 2015
New Revision: 227860
URL: https://gcc.gnu.org/viewcvs?rev=227860&root=gcc&view=rev
Log:
PR middle-end/65958
* config/arm/linux-elf.h (STACK_CH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351
Allan Jensen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #19 from Paolo Bonzini ---
LIVE provides live registers that MAY be initialized (are initialized on at
least one path). The comments are all wrong!
There's no code in GCC for must-initialized. Pierre's patch gets it right
(except t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Bug ID: 67609
Summary: [Regression] Generates wrong code for SSE2 _mm_load_pd
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67351
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #1 from Joel Yliluoma ---
For the record, changing _mm_load_pd(v) into _mm_set_pd(v[1],v[0]) will coax
GCC into generating correct code. The bug is related to _mm_load_pd().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66530
--- Comment #8 from Jennifer Yao ---
I know this is horribly belated, but I *just* got around to testing the patch
proper, and I'm afraid to say that it does not appear to work.
(My last comment verified that setting PATH instead of LD_LIBRARY_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
--- Comment #21 from Richard Biener ---
Ok, so if we fix SCCVN further we hit its (designed) limitation with stmt
walking not following backedges (but the use is in a loop and the def outside).
We avoid doing the work to determine if sth is loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67570
--- Comment #4 from BENAÏSSA ---
Thank you very much for your reply.
Please do not take care of the first set of values for
MIN_NORMALIZED and in place you can test those new values.
MIN_NORMALIZED
1.755494 E-038 for float
2.2250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67222
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Thu Sep 17 12:50:54 2015
New Revision: 227862
URL: https://gcc.gnu.org/viewcvs?rev=227862&root=gcc&view=rev
Log:
PR middle-end/67222
* gimple-low.c (lower_stmt): Don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #20 from Kenneth Zadeck ---
>> On second thoughts, for the first point, maybe a native speaker understands
>> "an available definition on any path" as "an available definition on one
>> path,
>> whatever it is", in which case the de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67222
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #21 from Eric Botcazou ---
> LIVE provides live registers that MAY be initialized (are initialized on at
> least one path). The comments are all wrong!
>
> There's no code in GCC for must-initialized. Pierre's patch gets it right
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #3 from Uroš Bizjak ---
The doc says:
When used as an lvalue, 'subreg' is a word-based accessor.
Storing to a 'subreg' modifies all the words of REG that
overlap the 'subreg', but it leaves the other wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #22 from Eric Botcazou ---
> A native English speaker would say that this could be written better. I
> would suggest the term "on at least one path" and this is what a MAY problem
> is generally defined as.
Thanks. Here's a propos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #4 from Richard Biener ---
(In reply to Uroš Bizjak from comment #3)
> The doc says:
>
> When used as an lvalue, 'subreg' is a word-based accessor.
> Storing to a 'subreg' modifies all the words of REG that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
--- Comment #5 from Richard Biener ---
It does the "correct" thing for
#include
__m128d reg;
void set_lower(float b)
{
float v[4];
_mm_store_pd((double *)v, reg);
v[0] = b;
reg = _mm_load_pd((double *)v);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67611
Bug ID: 67611
Summary: strcpy BUG
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67611
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #21 from Oleg Endo ---
(In reply to Urja Rannikko from comment #20)
> I'll add a note here that this seems to also affect the AVR target when it
> is under register pressure and cant use Z or Y registers which can do Z+n
> /Y+n addres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573
--- Comment #8 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #7)
> Fixed on trunk.
> Oleg, now we can propose to make -mlra default on trunk.
Nice, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #23 from Kenneth Zadeck ---
This change to the doc looks fine to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67612
Bug ID: 67612
Summary: Unable to vectorize DOT_PROD_EXPR (PMADDWD)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
--- Comment #11 from Jonathan Wakely ---
Author: redi
Date: Thu Sep 17 15:06:42 2015
New Revision: 227872
URL: https://gcc.gnu.org/viewcvs?rev=227872&root=gcc&view=rev
Log:
Make std::random_device retry after short reads
PR libstdc++/65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #24 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 15:35:24 2015
New Revision: 227874
URL: https://gcc.gnu.org/viewcvs?rev=227874&root=gcc&view=rev
Log:
PR rtl-optimization/66790
* df-problems.c (LIVE): Ame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #25 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 15:35:43 2015
New Revision: 227875
URL: https://gcc.gnu.org/viewcvs?rev=227875&root=gcc&view=rev
Log:
PR rtl-optimization/66790
* df-problems.c (LIVE): Ame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67588
--- Comment #7 from Vittorio Zecca ---
use_list is local to the function gfc_match_submodule and it is already
reinitialized in the for statement at line 806.
So there is a duplication.
On return at line 812 it is then lost.
Maybe optimization wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #26 from Eric Botcazou ---
Author: ebotcazou
Date: Thu Sep 17 15:35:58 2015
New Revision: 227876
URL: https://gcc.gnu.org/viewcvs?rev=227876&root=gcc&view=rev
Log:
PR rtl-optimization/66790
* df-problems.c (LIVE): Ame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67610
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|cp-tools
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67610
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #3 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67611
--- Comment #2 from Andrew Pinski ---
*** Bug 67610 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913
--- Comment #7 from Jonathan Wakely ---
Author: redi
Date: Thu Sep 17 15:46:04 2015
New Revision: 227878
URL: https://gcc.gnu.org/viewcvs?rev=227878&root=gcc&view=rev
Log:
Handle alignment in __atomic_is_lock_free
gcc:
2015-09-17 Richard Hend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |5.3
Summary|[5/6 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67613
Bug ID: 67613
Summary: spell suggestions for misspelled command line options
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614
Bug ID: 67614
Summary: ICE on using arithmetic if with null
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614
--- Comment #1 from Gerhard Steinmetz
---
$ cat z4.f90
program p
integer, pointer :: z => null()
if ( z ) 1, 2, 3
1 stop 1
2 stop 2
3 stop 3
end
$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z4.f90
$ a.out
Program receive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615
Bug ID: 67615
Summary: ICE on using arithmetic if with array instead of
scalar
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615
--- Comment #1 from Gerhard Steinmetz
---
With an array constructor :
$ cat z6.f90
program p
if ( [1] ) 1, 2, 3
if ( [1, -1] ) 1, 2, 3
if ( [real :: 1, -1] ) 1, 2, 3
1 stop 1
2 stop 2
3 stop 3
end
$ gfortran -g -O0 -Wall -fcheck=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Joel Yliluoma changed:
What|Removed |Added
Component|target |regression
--- Comment #6 from Joel Ylil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616
Bug ID: 67616
Summary: ICE on data initialization of type variable in block
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616
--- Comment #1 from Gerhard Steinmetz
---
Compiles without block :
program p
type t
end type
type(t) :: x
data x /t()/
end
Compiles with block and intrinsic type :
program p
block
integer :: x
data x /1/
end blo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64920
--- Comment #2 from Vittorio Zecca ---
I propose the following fix at line 688 of regex.c in trunk
change
(destination) += SIGN_EXTEND_CHAR (*((source) + 1)) << 8 ; \
into
(*((source) + 1)) >= 0 ? (destination) += SIGN_EXTEND_CHAR (*(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #23 from baoshan ---
(In reply to Manuel López-Ibáñez from comment #22)
> (In reply to baoshan from comment #21)
> > Don't you think the range value is strange? how it is possible the range
> > value is so big according the code?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #24 from Andrew Pinski ---
(In reply to baoshan from comment #23)
> I have seen two places that would convert "A-1" to "A+(-1)", and due the
> type is unsigned int, it would be converted to "A+4294967295". This looks
> not right to me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #25 from baoshan ---
(In reply to Andrew Pinski from comment #24)
> (In reply to baoshan from comment #23)
> > I have seen two places that would convert "A-1" to "A+(-1)", and due the
> > type is unsigned int, it would be converted to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609
Uroš Bizjak changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #7 from Uroš
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #26 from Jakub Jelinek ---
(In reply to baoshan from comment #25)
> > Why wrapping is well defined for unsigned types so adding 4294967295 is the
> > same as subtracting by 1.
>
> What is wrapping? and where it is defined? I don't kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617
Bug ID: 67617
Summary: Non-standard const requirements imposed on associate
container comparison objects
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827
--- Comment #3 from Vittorio Zecca ---
(In reply to Mikhail Maltsev from comment #1)
> gcc/haifa-sched.c:1164:24
> gcc/haifa-sched.c:1442:26
> gcc/sched-deps.c:112:20
>
> are caused by the following macro definition in gcc/sched-int.h:243:
> #de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Daniel Gutson changed:
What|Removed |Added
CC||daniel.gutson@tallertechnol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Bug ID: 67618
Summary: malloc+memset optimization breaks code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #1 from Marc Glisse ---
Why do you call it wrong? It is always legal to replace malloc with calloc, and
if we do it, the memset becomes useless. It may not be optimal from a
performance POV, but I don't see where it breaks anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
--- Comment #14 from Bernd Edlinger ---
Author: edlinger
Date: Thu Sep 17 19:43:00 2015
New Revision: 227886
URL: https://gcc.gnu.org/viewcvs?rev=227886&root=gcc&view=rev
Log:
2015-09-17 Bernd Edlinger
PR sanitizer/64078
* c-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #22 from Urja Rannikko ---
All of the 3 pointer regs (X,Y,Z) can do post-inc operations, but only Y and Z
can do displacement (which is what gcc tries to use, even when the increment
operation would be better all around since we usual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64078
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #2 from Daniel Gutson
---
(In reply to Marc Glisse from comment #1)
> Why do you call it wrong? It is always legal to replace malloc with calloc,
Have you seen the 'if' condition? The optimization ignores it completely.
> and if we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #3 from Andreas Schwab ---
Trying to read the (uninitialized) contents of the allocated memory for x <= 12
would be undefined behaviour, so calling calloc instead does not change the
defined behaviour.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #4 from Daniel Gutson
---
(In reply to Andreas Schwab from comment #3)
> Trying to read the (uninitialized) contents of the allocated memory for x <=
> 12 would be undefined behaviour, so calling calloc instead does not change
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #5 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #6 from Daniel Gutson
---
(In reply to Andrew Pinski from comment #5)
> (In reply to Daniel Gutson from comment #4)
> > (In reply to Andreas Schwab from comment #3)
> > > Trying to read the (uninitialized) contents of the allocated m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Marc Glisse changed:
What|Removed |Added
Component|middle-end |c
--- Comment #7 from Marc Glisse ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Marc Glisse changed:
What|Removed |Added
Component|c |tree-optimization
--- Comment #8 from Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #9 from Daniel Gutson
---
(In reply to Marc Glisse from comment #8)
> (bugzilla bug that reset the component...)
>
> (In reply to Daniel Gutson from comment #6)
> > That's why the 'if (ptr != NULL)' should not be ignored, which curr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364
--- Comment #1 from Louis Dionne ---
Ping. This is one of the last bugs preventing Boost.Hana [1] to work with GCC.
I would be eternally grateful if someone could fix this!
[1]: https://github.com/ldionne/hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
--- Comment #11 from Daniel Gutson ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Daniel Gutson from comment #9)
> > (In reply to Marc Glisse from comment #8)
> > > (bugzilla bug that reset the component...)
> > >
> > > (In repl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67616
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67615
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67614
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67580
Manuel López-Ibáñez changed:
What|Removed |Added
CC||rui.maciel at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617
--- Comment #1 from Jonathan Wakely ---
If that code is conforming then it's a defect in the standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55613
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617
--- Comment #2 from Jonathan Wakely ---
Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38358
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51270
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
De
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50476
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45821
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24786
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2005-11-11 17:59:15 |2015-9-18
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
Manuel López-Ibáñez changed:
What|Removed |Added
Last reconfirmed|2006-02-01 04:38:45 |2015-9-18
--- Comment #36 from Man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66883
Manuel López-Ibáñez changed:
What|Removed |Added
Target||epiphany
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53712
Marco Leise changed:
What|Removed |Added
CC||Marco.Leise at gmx dot de
--- Comment #9 f
1 - 100 of 107 matches
Mail list logo
