Hi, For below simple example:
#include stdint.h
extern uint32_t __bss_start[];
extern uint32_t __data_start[];
void Reset_Handler(void)
{
/* Clear .bss section (initialize with zeros) */
for (uint32_t* bss_ptr = __bss_start; bss_ptr != __data_start; ++bss_ptr) {
*bss_ptr = 0;
}
}
One
On Fri, Jan 03, 2014 at 04:12:19PM +0800, Bin.Cheng wrote:
Hi, For below simple example:
#include stdint.h
extern uint32_t __bss_start[];
extern uint32_t __data_start[];
void Reset_Handler(void)
{
/* Clear .bss section (initialize with zeros) */
for (uint32_t* bss_ptr = __bss_start;
On Fri, Jan 3, 2014 at 4:24 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 03, 2014 at 04:12:19PM +0800, Bin.Cheng wrote:
Hi, For below simple example:
#include stdint.h
extern uint32_t __bss_start[];
extern uint32_t __data_start[];
void Reset_Handler(void)
{
/* Clear .bss
On Fri, Jan 03, 2014 at 04:44:48PM +0800, Bin.Cheng wrote:
extern uint32_t __bss_start[];
extern uint32_t __data_start[];
void Reset_Handler(void)
{
/* Clear .bss section (initialize with zeros) */
for (uint32_t* bss_ptr = __bss_start; bss_ptr != __data_start; ++bss_ptr)
{
Hi,
When the standard pattern 'sqrtm2' is defined I don't understand why calls to
sqrt or __builtin_sqrt is always followed by a comparison of the result with
itself (checking the NaN ?) and a conditional branch to sqrt symbol (so linking
with libm is always mandatory).
On Fri, Jan 03, 2014 at 10:44:21AM +0100, BELBACHIR Selim wrote:
When the standard pattern 'sqrtm2' is defined I don't understand why calls
to sqrt or __builtin_sqrt is always followed by a comparison of the result
with itself (checking the NaN ?) and a conditional branch to sqrt symbol
(so
Hi,
I noticed a problem in gcc/testsuite/g++.dg/lto/lto.exp
If the target does not support LTO (check_effective_target_lto) a brutal return
is performed so the mathlib variable modified in lto_init will not be restored
properly by lto_finish at the end of the script.
Subsequent testsuites
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
I think this has been discussed in some PR, unfortunately I can't find it.
Bug 57725?
--
Joseph S. Myers
jos...@codesourcery.com
Hello,
in gcc/Makefile, there is a test to determine how to set up the GCC
provided limits.h. Here is a collection of the relevant Makefile parts:
#
# Installation directories
#
# Common prefix for installation directories.
# NOTE: This
On Fri, 3 Jan 2014, Sebastian Huber wrote:
There is already a --with-newlib configure option, so maybe it makes sense to
use it for the stmp-int-hdrs Makefile target?
The --with-newlib option is a badly named option that really means set
inhibit_libc. That is, it's for an initial bootstrap
I am trying to figure out how the top-consuming routines in our weather
models will be compiled when using AVX512 instructions (and their 32 512
bit registers).
I thought an up-to-date trunk version of gcc, using the command line:
.../gfortran -Ofast -S -mavx2 -mavx512f source code
would do
On 1/3/2014 11:04 AM, Toon Moene wrote:
I am trying to figure out how the top-consuming routines in our
weather models will be compiled when using AVX512 instructions (and
their 32 512 bit registers).
I thought an up-to-date trunk version of gcc, using the command line:
.../gfortran -Ofast
On Fri, Jan 03, 2014 at 05:04:55PM +0100, Toon Moene wrote:
I am trying to figure out how the top-consuming routines in our
weather models will be compiled when using AVX512 instructions (and
their 32 512 bit registers).
I thought an up-to-date trunk version of gcc, using the command line:
On 01/03/2014 07:04 PM, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 05:04:55PM +0100, Toon Moene wrote:
I am trying to figure out how the top-consuming routines in our
weather models will be compiled when using AVX512 instructions (and
their 32 512 bit registers).
I thought an up-to-date
On 1/3/2014 2:58 PM, Toon Moene wrote:
On 01/03/2014 07:04 PM, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 05:04:55PM +0100, Toon Moene wrote:
I am trying to figure out how the top-consuming routines in our
weather models will be compiled when using AVX512 instructions (and
their 32 512
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
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 burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc
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 jakub at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125
Vladimír Čunát vcunat at gmail dot com changed:
What|Removed |Added
CC||vcunat at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59662
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
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 rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59630
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #10 from bin.cheng amker.cheng at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
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] !=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58950
--- Comment #11 from Marc Glisse glisse at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59651
--- Comment #7 from Tejas Belagod belagod at gcc dot gnu.org ---
AArch64 regressions came back OK. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
--- Comment #43 from Hin-Tak Leung htl10 at users dot sourceforge.net ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #40)
Please try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
--- Comment #6 from paolo at gcc dot gnu.org 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=206313root=gccview=rev
Log:
/cp
2014-01-03 Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59165
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
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
---
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 =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822
--- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Jan 3 12:22:17 2014
New Revision: 206314
URL: http://gcc.gnu.org/viewcvs?rev=206314root=gccview=rev
Log:
PR target/59625
* config/i386/i386.c
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 mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Fri Jan 3 12:28:31 2014
New Revision: 206315
URL: http://gcc.gnu.org/viewcvs?rev=206315root=gccview=rev
Log:
PR other/59661
* doc/extend.texi: Fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59661
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56791
--- Comment #10 from Bernd Schmidt bernds at gcc dot gnu.org ---
(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 jakub at gcc dot gnu.org ---
Author: jakub
Date: Fri Jan 3 12:59:42 2014
New Revision: 206316
URL: http://gcc.gnu.org/viewcvs?rev=206316root=gccview=rev
Log:
PR target/59625
* config/i386/i386.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59625
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
--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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
--- Comment #1 from Rainer Orth ro at gcc dot gnu.org ---
Created attachment 31566
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31566action=edit
assembler output with as and -fverbose-asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57773
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
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 rearnsha at gcc dot gnu.org ---
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
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=206319root=gccview=rev
Log:
2014-01-03 Bingfeng Mei b...@broadcom.com
PR
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 Anglin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59008
--- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org ---
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
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 rearnsha at gcc dot gnu.org changed:
What|Removed |Added
CC||vmakarov at
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
--build=hppa-linux-gnu
--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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59664
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58567
--- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org ---
Author: burnus
Date: Fri Jan 3 20:24:50 2014
New Revision: 206322
URL: http://gcc.gnu.org/viewcvs?rev=206322root=gccview=rev
Log:
2014-01-03 Tobias Burnus bur...@net-b.de
--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 glisse at gcc dot gnu.org ---
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 glisse at gcc dot gnu.org ---
Author: glisse
Date: Fri Jan 3 21:12:48 2014
New Revision: 206325
URL: http://gcc.gnu.org/viewcvs?rev=206325root=gccview=rev
Log:
2014-01-03 Marc Glisse marc.gli...@inria.fr
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 glisse at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.9 Regression] Missing|Missing statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58151
Patrick Kelly p-kell at live dot com changed:
What|Removed |Added
CC||p-kell at live dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #3 from Zhendong Su su at cs dot ucdavis.edu ---
(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,
//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 - crash
4.8 - ignoring
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 pinskia at gcc dot gnu.org changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32449
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||su at cs dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59668
--- Comment #5 from Zhendong Su su at cs dot ucdavis.edu ---
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 pinskia at gcc dot gnu.org ---
(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 sch...@linux-m68k.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59672
--- Comment #2 from H. Peter Anvin hpa at zytor dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50180
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50181
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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 pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14840
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59252
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
Meanwhile your patch is ok.
As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
can appear in the vtable and it has pretty much the same properties
as __builtin_unreachable (void return value, no arguments,
Hi!
Linus complained about padding inserted in between asm goto. In 4.8
even -mtune=generic performs ix86_avoid_jump_mispredicts, in 4.9 only e.g.
-mtune=atom and others, but not generic.
The issue is that assuming every asm goto must contain a jump is too
pessimistic, often asm goto (may)
Hi!
I've noticed that especially with the AVX512F introduction we use
GET_MODE_SIZE (MODEmode) quite heavily in the i386 *.md files, and
the problem with that is GET_MODE_SIZE isn't a compile time constant,
needs to read mode_size array (non-const) at runtime.
This patch attempts to decrease the
Hi!
This is an attempt to port my recent
http://gcc.gnu.org/viewcvs?rev=204219root=gccview=rev
http://gcc.gnu.org/viewcvs?rev=205663root=gccview=rev
http://gcc.gnu.org/viewcvs?rev=206090root=gccview=rev
changes also to AVX512F. The motivation is to get:
#include immintrin.h
__m512i
foo (void
On Fri, Jan 3, 2014 at 9:48 AM, Jakub Jelinek ja...@redhat.com wrote:
I've noticed that especially with the AVX512F introduction we use
GET_MODE_SIZE (MODEmode) quite heavily in the i386 *.md files, and
the problem with that is GET_MODE_SIZE isn't a compile time constant,
needs to read
Jakub Jelinek ja...@redhat.com wrote:
On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
Meanwhile your patch is ok.
As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
can appear in the vtable and it has pretty much the same properties
as __builtin_unreachable
In addition this patch fixes PR 59662.
Also: Ping!
Cheers,
Janus
2013/12/31 Janus Weil ja...@gcc.gnu.org:
Hi all,
... and the reg-bashing continues: Here is a small patch to fix a
bind(c) problem. It essentially prevents 'resolve_global_procedure' to
be applied to bind(c) procedures.
On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote:
Jakub Jelinek ja...@redhat.com wrote:
On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
Meanwhile your patch is ok.
As discussed in the PR, the patch wasn't sufficient, __cxa_pure_virtual
can appear in the vtable
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 10:26:44AM +0100, Richard Biener wrote:
Jakub Jelinek ja...@redhat.com wrote:
On Tue, Dec 31, 2013 at 11:30:12AM +0100, Richard Biener wrote:
Meanwhile your patch is ok.
As discussed in the PR, the patch wasn't
On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
Well, see PR59630. The question is if having to handle it everywhere
is worth it.
Well, this case happens because we go back to GENERIC which doesn't
have this feature. So everywhere is somewhat a broad stmt.
It's easy to
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 11:01:13AM +0100, Richard Biener wrote:
Well, see PR59630. The question is if having to handle it everywhere
is worth it.
Well, this case happens because we go back to GENERIC which doesn't
have this feature. So
On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
so if there is a decl then use its type signature, otherwise
(indirect calls) use the caller signature (and hope it matches
the callee...). That it later falls back to looking at
DECL_ARGUMENTS is odd (probably a FE issue where
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
so if there is a decl then use its type signature, otherwise
(indirect calls) use the caller signature (and hope it matches
the callee...). That it later falls back to looking at
On Fri, 3 Jan 2014, Richard Biener wrote:
On Fri, 3 Jan 2014, Jakub Jelinek wrote:
On Fri, Jan 03, 2014 at 11:15:32AM +0100, Richard Biener wrote:
so if there is a decl then use its type signature, otherwise
(indirect calls) use the caller signature (and hope it matches
the
1 - 100 of 157 matches
Mail list logo
