Thanks for the responses!
I'll think about your warnings and decide whether I could afford such
effort or not, but anyway, I wanted to start from GCC, not glibc.
Am I getting it right, that before any other works we need to fix PR
34678 (that's correct number, thanks Mark!), making all passes take
Hello all,
trying to compile bash-4.2 with the gcc-4.8-20130106 snapshot I get the
following error:
gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu'
-DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL
On Thu, Jan 10, 2013 at 9:43 AM, thorsten fly_b...@gmx.de wrote:
Hello all,
trying to compile bash-4.2 with the gcc-4.8-20130106 snapshot I get the
following error:
gcc -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
I am pleased to announce that the GCC Steering Committee has
accepted the Synopsys DesignWare ARC port for inclusion in GCC and appointed
Joern Rennecke as maintainer.
Please join me in congratulating Joern on his new role.
Joern, please update your listing in the MAINTAINERS
On Thu, 10 Jan 2013, Michael Zolotukhin wrote:
Thanks for the responses!
I'll think about your warnings and decide whether I could afford such
effort or not, but anyway, I wanted to start from GCC, not glibc.
Am I getting it right, that before any other works we need to fix PR
34678 (that's
Hi all,
The latest errata for Texas Instruments' Cortex-M3 family, updated
last October [1], contains a disturbing new problem triggered by
non-word-aligned writes to SRAM. This is the kind of errata that is
effectively addressed with a compiler work-around. FWIW, it has
already been addressed by
Hello All,
I recently joined this mailing list and I was particularly interested
in knowing how the atomic built-ins
(http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html) are
implemented in gcc.
I skimmed through the source code (mostly libgcc/sync.c file), however
it looks like it
On Thu, Jan 10, 2013 at 10:38 AM, Prasad Joshi prasadjoshi...@gmail.com wrote:
I recently joined this mailing list and I was particularly interested
in knowing how the atomic built-ins
(http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html) are
implemented in gcc.
I skimmed
We had a useful discussion about C++11 ABI issues at the GNU Tools
Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be
shaped over time, but the general idea is as follows.
We will modify g++ to support a type attribute indicating the version
of the type, as a string.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55718
--- Comment #4 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-01-10
08:15:23 UTC ---
Author: krebbel
Date: Thu Jan 10 08:15:07 2013
New Revision: 195078
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195078
Log:
2013-01-10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55718
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55905
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45076
--- Comment #3 from janus at gcc dot gnu.org 2013-01-10 08:43:09 UTC ---
(In reply to comment #2)
With 4.7 I get instead of an ICE just the warning:
Same with curent 4.8 trunk:
dynamic_dispatch_6.f03:66:0: note: Skipping target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
--- Comment #3 from janus at gcc dot gnu.org 2013-01-10 08:50:51 UTC ---
Further reducing the test case:
module m
type, abstract :: t
contains
procedure(inter), pass, deferred :: foo
end type
contains
subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10
09:25:27 UTC ---
Author: jakub
Date: Thu Jan 10 09:25:12 2013
New Revision: 195080
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195080
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55921
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55933
Bug #: 55933
Summary: Missing attachment download link
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55882
--- Comment #13 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10
09:48:41 UTC ---
I have bootstrapped and tested the patch from comment #11 on
sparc64-linux (gcc63 on compile farm) and there were no issues
(actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
Bug #: 55934
Summary: [4.8 Regression] LRA inline asm error recovery
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55933
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-10
10:47:46 UTC ---
(In reply to comment #0)
The best option would be to disable the useless patch viewer.
This gets my vote.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55923
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #34 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2013-01-10 11:26:23 UTC ---
(In reply to comment #33)
Can you sent it to review? You can also mention that it fixes issue 40362.
I had a closer look at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #35 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10
11:37:08 UTC ---
For config/posix it is not that easy, because you can't assume that atomics are
available. You'd need to guard it with #ifdef HAVE_SYNC_BUILTINS and do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Attachment #29139|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2013-01-10 13:08:43
UTC ---
This has caused quite a bit of confusion lately with people installing ISL
instead of PPL for gcc-4.7.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #26 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
13:42:33 UTC ---
Author: rguenth
Date: Thu Jan 10 13:42:27 2013
New Revision: 195084
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195084
Log:
2013-01-10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381
Timo Kreuzer timo.kreuzer at reactos dot org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Attachment #29140|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46952
--- Comment #5 from janus at gcc dot gnu.org 2013-01-10 14:09:54 UTC ---
The following patch is equivalent in functionality to the one in comment 4, but
includes some minor cleanup (and regtests cleanly):
Index: gcc/fortran/resolve.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #28 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
14:11:43 UTC ---
Another possibility lies in DEBUG stmts which we do not consider at all ...
(in the checker, that is).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52381
--- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2013-01-10 14:12:54
UTC ---
Like __atomic_compare_exchange_n?
This will be usual difference of virtual call representation in ia64. The .cp
test is going fine?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
--- Comment #1 from Jan Hubicka hubicka at ucw dot cz 2013-01-10 14:33:48 UTC
---
This will be usual difference of virtual call representation in ia64. The .cp
test is going fine?
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
--- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2013-01-10 14:44:20
UTC ---
Yes, it does.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47203
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
15:02:37 UTC ---
By unswitching on an exit test that exits to the enclosing loop we create
an unswitched loop that is now reached by what looks like an exit test
of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47136
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #170 from Jan Hubicka hubicka at gcc dot gnu.org 2013-01-10
15:04:10 UTC ---
OK, here is updated memory use:
cgraph.c:863 (cgraph_allocate_init_indirect_info5905200: 0.1% 0:
0.0%6020160: 0.1% 0: 0.0%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55345
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833
--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-10
15:11:34 UTC ---
(In reply to comment #6)
By unswitching on an exit test that exits to the enclosing loop we create
an unswitched loop that is now reached by what
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #29 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
15:28:38 UTC ---
(In reply to comment #27)
Created attachment 29141 [details]
updated checker
Also verify expressions. Bootstrapped ok, target libs building
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #30 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
15:34:39 UTC ---
LTO profiled-bootstrap revals:
/space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44061
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-01-10
15:35:40 UTC ---
I'm updating and testing the patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
Bug #: 55935
Summary: [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs
with bogus BLOCK
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #8 from janus at gcc dot gnu.org 2013-01-10 15:46:12 UTC ---
(In reply to comment #7)
I want to emphasize again that the error I wanted to report was that gfortran
is rejecting valid structure constructor expressions (see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #9 from janus at gcc dot gnu.org 2013-01-10 16:06:51 UTC ---
In fact one also gets an ICE when replacing class(S) with type(S) in
comment 8 (already with an unpatched gfortran):
type :: S
integer :: n
end type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10
16:25:05 UTC ---
For the test gfortran.dg/class_array_15.f03, the ICE is triggered by the
statement:
allocate(b%cBh(1),source=defaultBhC)
(note that the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52448
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-10
16:49:26 UTC ---
Any progress with this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936
Bug #: 55936
Summary: Missed VRP optimization
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55683
--- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10
16:58:35 UTC ---
(In reply to comment #13)
The acutal ICE should be fixed. Martinj, I will leave the PR open
just to make you to double check that ipa-cp is doing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #31 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 17:03:13
UTC ---
(In reply to comment #30)
LTO profiled-bootstrap revals:
/space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55899
Hans-Peter Nilsson hp at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929
--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2013-01-10 17:30:36
UTC ---
Patch in testing:
Index: i386.md
===
--- i386.md (revision 195063)
+++ i386.md
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10
17:35:13 UTC ---
(note that the test compiles with -fno-whole-file;-).
To be honest, this is not true for the other failing tests. Reduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565
--- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-10
17:46:39 UTC ---
I compared the code generated by trunk with the generated code in rev 190339
which broke the test. The trunk code is more optimal than when the test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55927
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
CC||jamborm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-10
17:53:24 UTC ---
(In reply to comment #4)
Bottom line, on trunk we avoid a branch and memory load/stores.
I agree the code is much better now. Only moving between
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55488
--- Comment #1 from wmi at gcc dot gnu.org 2013-01-10 17:57:40 UTC ---
Author: wmi
Date: Thu Jan 10 17:57:34 2013
New Revision: 195092
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195092
Log:
2013-01-10 Wei Mi w...@google.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
--- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org 2013-01-10
18:02:35 UTC ---
(In reply to comment #8)
Let me look into those...
Try the patch I attached to PR45375
I have updated to revision 195082 which I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55264
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27338
Steve Ellcey sje at gcc dot gnu.org changed:
What|Removed |Added
CC||sje at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54139
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||aldyh at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55792
--- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2013-01-10 19:36:08
UTC ---
(In reply to comment #30)
LTO profiled-bootstrap revals:
/space/rguenther/src/svn/trunk/gcc/reginfo.c: In function 'reg_scan':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929
--- Comment #4 from uros at gcc dot gnu.org 2013-01-10 19:49:34 UTC ---
Author: uros
Date: Thu Jan 10 19:49:17 2013
New Revision: 195094
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195094
Log:
PR target/55929
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55929
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Target||x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55672
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2013-01-10 20:23:49
UTC ---
Author: vmakarov
Date: Thu Jan 10 20:07:55 2013
New Revision: 195095
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195095
Log:
2013-01-10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565
--- Comment #6 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-01-10
20:28:33 UTC ---
Author: aldyh
Date: Thu Jan 10 20:28:26 2013
New Revision: 195097
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=195097
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #10 from janus at gcc dot gnu.org 2013-01-10 20:39:58 UTC ---
The following patch makes comment 8 and 9 compile, but I'm not sure if the
generated code is correct:
Index: gcc/fortran/trans-expr.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55934
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55721
--- Comment #14 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
2013-01-10 21:32:24 UTC ---
(In reply to comment #12)
Here is another testcase that looks different then the others, it is cutdown
from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55937
Bug #: 55937
Summary: lto hides possible link issues
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55937
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-10
21:47:29 UTC ---
I think this is really invalid and the check (autoconf) should be changed
instead. What is happening is f is known to be used outside of the program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55742
Sriraman Tallam tmsriram at google dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10
22:35:06 UTC ---
Shorter test case for gfortran.dg/typebound_operator_*:
module i_field_module
implicit none
type :: i_field
integer :: i
end type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-01-10
23:10:39 UTC ---
Note that if the 'class's are replaced with 'type's, the program compiles.
The assert also triggers if
class(i_field) ,intent(in) ::
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938
Bug #: 55938
Summary: g++.dg/asan/deep-stack-uaf-1.C fails at r195092 on
darwin
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Hi,
I've committed the attached patch which fixes PR 55718 by adding
support for GOTENT + constant to legitimize_pic_address in the S/390
backend.
The patch also does some rearrangements of the whole function in order
to avoid some duplicate code.
Bye,
-Andreas-
2013-01-10 Andreas Krebbel
On Wed, 9 Jan 2013, Eric Botcazou wrote:
This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
account for the to-be applied bitpos when computing MEM_ALIGN.
It extracts alignment from 't' instead of t - bitpos.
Bootstrapped and tested on x86_64-unknown-linux-gnu, bootstrap
On Thu, 10 Jan 2013, Jakub Jelinek wrote:
Hi!
We weren't processing GIMPLE_ASMs that set complex SSA_NAMEs, which lead to
SSA_NAMEs with NULL SSA_NAME_DEF_STMT, either leading to crashes or silent
wrong code, depending on --enable-checking. Fixed thusly,
bootstrapped/regtested on
I haven't heard any complaints about the caret diagnostics being
enabled by default, so I am tempted to think it will stay like it is
for GCC 4.8. This patch documents that and also the new -Wpedantic.
OK?
Cheers,
Manuel.
caret.diff
Description: Binary data
On Thu, 10 Jan 2013, Richard Biener wrote:
On Wed, 9 Jan 2013, Eric Botcazou wrote:
This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
account for the to-be applied bitpos when computing MEM_ALIGN.
It extracts alignment from 't' instead of t - bitpos.
Bootstrapped
Hi Joel,
Well Doh!
The gcc-abi and 8byte multilib variants appeared to have
been added around 2012-11-20 by Nick Clifton. I think he
missed changing the ASM_SPEC in gcc/config/v850/rtems.h
when he added it. v850-rtems-gcc wasn't passing in the expected
cpu specification flags.
Nick.. how does
On Thu, Jan 10, 2013 at 6:15 AM, Jeff Law l...@redhat.com wrote:
Gary Funck noted that vrp06.c has two tests with the same output. After
further investigation it was clear that expected output strings were too
lenient and were in fact masking a missed optimization.
This patch tightens the
Hello!
This patch tightens the expected output from the vrp dump which has the side
effect of making each test's string unique. Obviously the masked failure is
xfailed.
OK for the trunk?
Hmm, but if the SSA versions are simply i_10 then i_.*0 will still match it
the same? I think you
On Thu, 10 Jan 2013, Richard Biener wrote:
On Thu, 10 Jan 2013, Richard Biener wrote:
On Wed, 9 Jan 2013, Eric Botcazou wrote:
This fixes PR55882 - set_mem_attributes_minus_bitpos misses to
account for the to-be applied bitpos when computing MEM_ALIGN.
It extracts alignment
On Thu, Jan 10, 2013 at 11:07:26AM +0400, Konstantin Serebryany wrote:
Our internal LLVM bots (Linux, Mac and Android) are also green, but
since the changes are large something may potentially break on other
platforms.
Ok to commit?
Ok, but it would be nice if the prctl stuff in
1 - 100 of 151 matches
Mail list logo
