http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662
Bug ID: 59662
Summary: [OOP] TBP subroutine call rejected in contained
subroutine
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59663
Bug ID: 59663
Summary: [4.9 Regression] config/darwin.c:3665:1: error:
control reaches end of non-void function
[-Werror=return-type]
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59654
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #8 from Jakub Jelinek ---
(In reply to bin.cheng from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Created attachment 31562 [details]
> > gcc49-pr59519.patch
> >
> > I wonder if this isn't just a checking issue, the t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125
Vladimír Čunát changed:
What|Removed |Added
CC||vcunat at gmail dot com
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #9 from Jakub Jelinek ---
BTW, the patch can hardly regress anything, it only affects cases that ICEd
before the patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59630
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59630
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Started with my r182761 but say:
> _Bool foo (int x)
> {
> _Bool (*f)(int) = __builtin_abs;
> return f(x);
> }
> ICEs at -O2 already since the gimple_call_fnt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #10 from bin.cheng ---
(In reply to Jakub Jelinek from comment #9)
> BTW, the patch can hardly regress anything, it only affects cases that ICEd
> before the patch.
Em, I am worried if vectorization can handle peeled phi correctly for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #11 from Jakub Jelinek ---
I've tried even:
struct S { int f0; } d;
int a[8] = { 0 }, b, c, e, f;
void
foo (void)
{
for (; e < 1; e++)
{
for (b = 0; b < 7; b++)
{
c |= (a[b + 1] != 0);
if (d.f0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #11 from Marc Glisse ---
(In reply to Jason Merrill from comment #10)
> (In reply to Marc Glisse from comment #7)
> > The __builtin_shuffle part of the patch seems fine.
>
> Yes, that looks right. That fixes the bug, yes?
It fixes t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #7 from Tejas Belagod ---
AArch64 regressions came back OK. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #43 from Hin-Tak Leung ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #40)
>> Please try this on your system and tell us how you end up with
>> bootstrap-deb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Fri Jan 3 11:11:31 2014
New Revision: 206313
URL: http://gcc.gnu.org/viewcvs?rev=206313&root=gcc&view=rev
Log:
/cp
2014-01-03 Paolo Carlini
Core DR 1442
PR c++/5916
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
--- Comment #4 from janus at gcc dot gnu.org ---
Slightly reduced test case:
implicit none
type Plane
integer :: M(1,1)
end type
type(Plane), parameter :: planes(1) = [ Plane(1) ]
integer:: f(1,1)
f = (planes(1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #6)
> Probably depends on cases. Sometimes it is good to have the explanation
> right next to the type, other times it takes up all the space and you can't
> even fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 3 12:22:17 2014
New Revision: 206314
URL: http://gcc.gnu.org/viewcvs?rev=206314&root=gcc&view=rev
Log:
PR target/59625
* config/i386/i386.c (ix86_avoid_jump_mispredicts):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Fri Jan 3 12:28:31 2014
New Revision: 206315
URL: http://gcc.gnu.org/viewcvs?rev=206315&root=gcc&view=rev
Log:
PR other/59661
* doc/extend.texi: Fix the return value of __built
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
--- Comment #3 from janus at gcc dot gnu.org ---
-fdump-tree-orginial shows that some code for the initialization of the
component 'label' is inserted:
{
struct branch_plot_results_ppv_type branch_plot_results_ppv_type.0;
if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791
--- Comment #10 from Bernd Schmidt ---
(In reply to John David Anglin from comment #9)
> Any chance the candidate patch can be submitted?
I guess this means you've tested it and it works?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 3 12:59:42 2014
New Revision: 206316
URL: http://gcc.gnu.org/viewcvs?rev=206316&root=gcc&view=rev
Log:
PR target/59625
* config/i386/i386.c (ix86_avoid_jump_mispredicts):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #12 from Jakub Jelinek ---
--target_board=unix/-O3 testing showed no changes (except for the testcases in
the patch), on both x86_64-linux and i686-linux (on the former one including
ada testing).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
Bug ID: 59664
Summary: avx512f-ceil-sfix-vec-2.c and
avx512f-floor-sfix-vec-2.c FAIL on Solaris9/x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
--- Comment #1 from Rainer Orth ---
Created attachment 31566
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31566&action=edit
assembler output with as and -fverbose-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57773
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59665
Bug ID: 59665
Summary: User code can cause ambiguous references to "std" in
libstdc++
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #15 from Richard Earnshaw ---
Another testcase where the thumb1 code is poor is
gcc.c-torture/execute/pr28982b.c
With LRA we often get sequences such as:
mov r3, sp
ldr r2, .L8+16
add r3, r3, r2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #8 from meibf at gcc dot gnu.org ---
Author: meibf
Date: Fri Jan 3 15:40:57 2014
New Revision: 206319
URL: http://gcc.gnu.org/viewcvs?rev=206319&root=gcc&view=rev
Log:
2014-01-03 Bingfeng Mei
PR tree-optimization/59651
* tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791
--- Comment #11 from dave.anglin at bell dot net ---
On 3-Jan-14, at 7:46 AM, bernds at gcc dot gnu.org wrote:
> I guess this means you've tested it and it works?
Yes, I have tested it and it works fine.
Dave
--
John David Anglindave.ang...@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008
--- Comment #5 from Martin Jambor ---
IPA-CP is decrementing reference count of parameter 1 instead of
parameter 2. That happens because the variable param_index in
ipcp_discover_new_direct_edges has type bool instead of int. What a
stupid mista
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
Bug ID: 59666
Summary: IBM long double arithmetic results invalid in
non-default rounding modes
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609
Richard Earnshaw changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot net
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
This is with gcc --version
gcc (GCC) 4.9.0 20140103 (experimental
--enable-clocale=gnu --enable-java-gc=boehm
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,lto
Thread model: posix
gcc version 4.8.3 20140103 (prerelease) [gcc-4_8-branch revision 206321] (GCC)
I see the following backtrace when the insn was emitted:
Breakpoint 1, pa_emit_move_sequence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567
--- Comment #4 from Tobias Burnus ---
Author: burnus
Date: Fri Jan 3 20:24:50 2014
New Revision: 206322
URL: http://gcc.gnu.org/viewcvs?rev=206322&root=gcc&view=rev
Log:
2014-01-03 Tobias Burnus
PR c++/58567
* pt.c (tsubst_om
--enable-multilib
Thread model: posix
gcc version 4.9.0 20140103 (experimental) [trunk revision 206321] (GCC)
$
$ gcc-trunk -Wall -Wextra -pedantic -std=c99 -c small.c
$
$ gcc-trunk -O0 -c small.c
$ gcc-trunk -Os -c small.c
$
$ gcc-trunk -O1 -c small.c
In file included from /usr/include/string.h:637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #1 from Marc Glisse ---
Well, that's a glibc issue, isn't it?
Btw, you need to provide the preprocessed code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #12 from Marc Glisse ---
Author: glisse
Date: Fri Jan 3 21:12:48 2014
New Revision: 206325
URL: http://gcc.gnu.org/viewcvs?rev=206325&root=gcc&view=rev
Log:
2014-01-03 Marc Glisse
PR c++/58950
gcc/cp/
* cvt.c (convert_to_
/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20140103 (experimental) (GCC)
Tested revisions:
r206310 - crash
4.8 - ignoring #pragma omp declare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
Marc Glisse changed:
What|Removed |Added
Summary|[4.9 Regression] Missing|Missing "statement has no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58151
Patrick Kelly changed:
What|Removed |Added
CC||p-kell at live dot com
--- Comment #3 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #3 from Zhendong Su ---
(In reply to Andrew Pinski from comment #2)
> Actually this is neither a bug in GCC or glibc. In C, strcmp can be defined
> as a macro and that is what you are getting a macro.
Huh, that's interesting; thanks.
ith: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-206310-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20140103 (experimental) (GCC)
Tested revisions:
r206310
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59671
Bug ID: 59671
Summary: Improper Ada behavior under -gnat2012
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #4 from Andrew Pins
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32449
Andrew Pinski changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #5 from Zhendong Su ---
> Because glibc decides only to implement the macro at -O and above but not
> when optimizing for size.
I see; thanks Andrew.
BTW, is strcmp the only one like this, or there are others?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #6 from Andrew Pinski ---
(In reply to Zhendong Su from comment #5)
> BTW, is strcmp the only one like this, or there are others?
Almost (if not all) all standard C functions are like this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #7 from Andreas Schwab ---
7.1.3 Reserved identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
Bug ID: 59672
Summary: Add -m16 support for x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #1 from Andrew Pinski ---
Note GCC does not even support real 16bit code for x86. So pretending GCC's
output is 16bit code is a joke.
Why can't you just write the 16bit binary support in assembly for the kernel?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #2 from H. Peter Anvin ---
It is much cleaner to have it in C. We converted the assembly code to C back
in 2007 and it has been much easier to maintain ever since. It works fine,
thankyouverymuch; it isn't *optimal* 16-bit code, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50180
Bill Schmidt changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59673
Bug ID: 59673
Summary: wrong specialization used when a partial
specialization of a member template is explicitly
specialized
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36109
Andrew Pinski changed:
What|Removed |Added
Keywords||patch
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
Bug ID: 59674
Summary: On m68k and vax variables stack variables with >
MAX_STACK_ALIGNMENT make ssp fail
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|una
71 matches
Mail list logo
