On 05/13/2015 02:51 AM, Iain Buclaw wrote:
Hi,
Started these as separate patches, but as more came out of what I was
originally trying to achieve (see Patch 6/7), I thought it better to
have it as a running series.
These set out to update d-demangle.c for new ABI additions, general
bug fixes,
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote:
On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote:
It seems that with whenever a function's frame is bigger than 512 bytes,
LRA loops.
I cannot reproduce this with your testcase. Please post the *exact*
testcase
On 05/13/2015 03:14 PM, Iain Buclaw wrote:
One last thing that was added in the next D version's ABI (and I
subsequently missed).
This is a trivial patch to just ignore the new mangle symbol.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclaw ibuc...@gdcproject.org
* d-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66011
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
On Thu, May 14, 2015 at 01:56:54PM +0800, Hale Wang wrote:
gcc/ChangeLog:
2015-04-22 Hale Wang hale.w...@arm.com
Terry Guo terry@arm.com
PR rtl-optimization/64818
* combine.c (can_combine_p): Don't combine user-specified register
if
On Wed, May 13, 2015 at 1:29 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
On Wed, May 13, 2015 at 01:25:16PM -0400, David Edelsohn wrote:
PR rtl-optimization/30967
* config/rs6000/rs6000.c (rs6000_rtx_costs): Don't consider
destination mode for the cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #4)
For this testcase, my patch gives:
test.cc:8:34: error: invalid use of non-static member function ‘void X::m()’
That seems great
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw ibuc...@gdcproject.org
* d-demangle.c (dlang_call_convention): Return NULL
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
This addresses a subtle logic error, noticed when I was in the middle
of testing out some other tightening up of parsing checks.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw ibuc...@gdcproject.org
* d-demangle.c (dlang_identifier): Check
Reported by Nathan and fixed by his patch. I added the tests.
Tested powerpc64le-linux, committed to trunk. This should be
backported too.
commit f859cb0e4a369bdade09d5d77f9c8bb78d388294
Author: Jonathan Wakely jwak...@redhat.com
Date: Thu May 14 14:36:20 2015 +0100
2015-05-14 Nathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Thu May 14 13:47:19 2015
New Revision: 223198
URL: https://gcc.gnu.org/viewcvs?rev=223198root=gccview=rev
Log:
2015-05-14 Nathan Myers n...@cantrip.org
On 05/13/2015 06:30 AM, Georg-Johann Lay wrote:
hmmm, it would actually lead to valid machine code: The jump table is
actually a dispatch table, i.e. it contains a list of direct jumps to
the case labels. casesi loads the value of the label associated with
the jump table into a register,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66121
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
In my tests, this gives the demangler near-complete support. Of a
sample of about 75k symbols pulled from the standard library
unittester, all but 20 were successfully parsed.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclawibuc...@gdcproject.org
On 14 May 2015 at 15:24, Jeff Law l...@redhat.com wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
In my tests, this gives the demangler near-complete support. Of a
sample of about 75k symbols pulled from the standard library
unittester, all but 20 were successfully parsed.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
Bug ID: 66142
Summary: Loop is not vectorized because not sufficient support
for GOMP_SIMD_LANE
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
Like C++ const and volatile, in D mangled symbols can exist modifiers
that represent the const, immutable, inout and shared-ness of the
'this' parameter.
This information should be written out in the demangled symbol to show
that each variant has a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66142
--- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com ---
Created attachment 35541
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35541action=edit
test-case to reproduce
Must be compiled with -Ofast -fopenmp -march=core-avx2
On 14 May 2015 at 14:58, Jeff Law l...@redhat.com wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw
On 05/14/2015 08:04 AM, Marc Glisse wrote:
On Fri, 1 May 2015, Jeff Law wrote:
Slight refactoring of the condition by using types_match as suggested
by Richi. I also applied the new types_match to 2 other patterns in
match.pd where it seemed clearly appropriate.
I would like to propose this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65955
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Hi,
This patch fixes an internal compiler error when micromips/nomicromips
attributes are used.
The problem here was that the cached boolean attributes for the current
target did not agree with the uncached attributes throwing an assertion error.
It appears that saving and restoring the state
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
The next version of D adds support for cent and ucent for platforms
that are able to handle them natively. This adds support for
demangling them.
---
libiberty/ChangeLog:
2015-05-13 Iain Buclaw ibuc...@gdcproject.org
* d-demangle.c
James Greenhalgh wrote:
On Mon, Apr 27, 2015 at 05:57:26PM +0100, Wilco Dijkstra wrote:
James Greenhalgh wrote:
On Mon, Apr 27, 2015 at 02:42:36PM +0100, Wilco Dijkstra wrote:
-Original Message-
From: Wilco Dijkstra [mailto:wdijk...@arm.com]
Sent: 03 March 2015 16:19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66011
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Thu May 14 13:23:14 2015
New Revision: 223196
URL: https://gcc.gnu.org/viewcvs?rev=223196root=gccview=rev
Log:
PR libstdc++/66011
* acinclude.m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
--- Comment #13 from Wilco wdijkstr at arm dot com ---
(In reply to Vladimir Makarov from comment #9)
Created attachment 35503 [details]
ira-hook.patch
Here is the patch. Could you try it and give me your opinion about it.
Thanks.
I
On 05/11/2015 04:10 PM, Eric Botcazou wrote:
This fixes an RTL checking failure I ran into while working on a change and it
is latent in the pristine compiler. emit_pattern_{after|before}_setloc have:
if (active_insn_p (after) !INSN_LOCATION (after))
if (active_insn_p (first)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65955
--- Comment #16 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Thu May 14 13:16:32 2015
New Revision: 223195
URL: https://gcc.gnu.org/viewcvs?rev=223195root=gccview=rev
Log:
[ARM] Fix PR 65955: Do not take REGNO on non-REG operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66055
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
On Fri, 1 May 2015, Jeff Law wrote:
Slight refactoring of the condition by using types_match as suggested by
Richi. I also applied the new types_match to 2 other patterns in match.pd
where it seemed clearly appropriate.
I would like to propose this small tweak (regtested ok). If we had a
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase. Please post the *exact*
testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation helped. Kaboom.
It wants to reload pretty much
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
The next version of D introduces two new mangle conventions.
- Nj to represent methods whose 'this' parameter is also the function
return value
- Nk to represent a 'ref' parameter that is also the function return value
This patch introduces support
The PR is due to missing the third argument to open(3) but there are
some other errors in the same function as well as some unimplemented
features, and some bad error handling elsewhere.
The autoconf check for sendfile is intentionally conservative because
some BSDs define a sendfile() function
Hello,
as I mentioned yesterday on IRC adding a check that only complete types
have TYPE_BINFO defined triggers on type:
record_type 0x76d24d20 __is_integer type_5 type_6 VOID
align 8 symtab 0 alias set -1 canonical type 0x76d24d20
fields const_decl 0x74a89930 __value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66144
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Version|tree-ssa|4.9.0
---
Before this patch, jit.dg/test-benchmark.c at optlevel 0, 100 iterations
showed rest of compilation as taking a significant chunk of time:
rest of compilation : 1.53 (64%) usr 0.06 (32%) sys 1.60 (27%) wall
1388 kB ( 6%) ggc
This turned out to be almost entirely spent inside
On Thu, 14 May 2015, Iain Buclaw wrote:
On another note, I've found out why the remaining 20 symbols in my 75k
sample failed. They don't fail at all! It's just that they were all
greater than 33,000 characters in length, and my test used c++filt,
which trims anything bigger than 32767
On Thu, 2015-05-14 at 09:42 -0700, Steve Ellcey wrote:
Marek,
This may be unrelated to your patches for PR 66127 and 66066 but I am
having a new failure when building the latest glibc with the latest GCC.
I haven't yet tracked down exactly which patch caused the problem. Included
is a
On Wed, 13 May 2015, Jan Hubicka wrote:
Thank you! This looks fine. Please add also the testcase that should break if
the new test was wrong andosmeone fixed postreload to allow use of the same
register
this check will prevent wrong code?
I'm checking in a patch with the following
On 05/14/2015 10:38 AM, David Malcolm wrote:
Running jit.dg/test-sum-of-squares.c under valgrind showed a couple of leaks:
608 bytes in 4 blocks are definitely lost in loss record 184 of 229
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5BC88B0:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66140
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
On 05/14/2015 10:33 AM, Marc Glisse wrote:
Hello,
after this patch I think I'll close the PR. This was regtested on
ppc64le-redhat-linux.
Apparently I wrote this patch in a file that already had a trivial hunk:
-1-A - ~A is rejected for complex while -A-1 isn't, there is no reason
for this
On 05/14/2015 04:40 AM, Uros Bizjak wrote:
On Thu, May 14, 2015 at 1:31 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, May 13, 2015 at 8:53 PM, Richard Henderson r...@redhat.com wrote:
On 05/13/2015 11:11 AM, Uros Bizjak wrote:
We can use general_operand instead of some_operand.
2015-05-13
On 05/14/2015 09:20 AM, James Bowman wrote:
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase. Please post the *exact*
testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Bug ID: 66145
Summary: std::ios_base::failure objects thrown from
libstdc++.so use old ABI
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: ABI
On Thu, May 14, 2015 at 03:20:46PM +, James Bowman wrote:
It wants to reload pretty much everything. Looking at your code,
it seems you use the ancient interfaces instead of
TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that?
The FT32 target uses
On May 14, 2015, at 8:30 AM, Iain Buclaw ibuc...@gdcproject.org wrote:
On another note, I've found out why the remaining 20 symbols in my 75k
sample failed. They don't fail at all! It's just that they were all
greater than 33,000 characters in length, and my test used c++filt,
which trims
On 05/14/2015 10:29 AM, David Malcolm wrote:
Before this patch, jit.dg/test-benchmark.c at optlevel 0, 100 iterations
showed rest of compilation as taking a significant chunk of time:
rest of compilation : 1.53 (64%) usr 0.06 (32%) sys 1.60 (27%) wall
1388 kB ( 6%) ggc
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66147
Bug ID: 66147
Summary: [5/6 Regression] go fails to cross build
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
On Thu, May 14, 2015 at 10:07:56AM -0700, Steve Ellcey wrote:
Sorry for the noise, it looks like this failure is not related to any
recent changes in GCC. I still get the error in older GCC's so I think
something must have changed in glibc. I will start digging there.
Yeah -- strict aliasing
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is B or W), it picks alt 0, loop, everyone unhappy.
B should match it seems?
(Why does IRA think r56 should be in memory? Yeah, good question.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
Bug ID: 66146
Summary: call_once not C++11-compliant on ppc64le
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66144
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
I suspect a == b is all equals and not element by element equals.
I am wrong.
From the manual:
Vector comparison is supported with
PING: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00772.html
The Fortran part was already approved, only the diagnostics part is pending.
Thanks,
Manuel.
On 05/13/2015 04:45 AM, Eric Botcazou wrote:
Hi,
the SJLJ EH schemes manipulate a buffer that contains a few pointers and, in
particular, the stack pointer. Therefore, when dynamic stack allocation is
also used, you need to update its value in the buffer, otherwise Bad Things
will happen if
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase. Please post the *exact*
testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation helped. Kaboom.
It wants to reload pretty
On 05/14/2015 08:32 AM, Uros Bizjak wrote:
2015-05-14 Uros Bizjak ubiz...@gmail.com
* config/alpha/alpha.c (alpha_extract_integer): Do not handle
CONST_WIDE_INT and CONST_DOUBLE. Assert CONST_INT_P (x).
(alpha_legitimate_constant_p) case CONST_WIDE_INT: Check high and
low
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66144
Bug ID: 66144
Summary: vector element operator produces very bad code
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Running jit.dg/test-sum-of-squares.c under valgrind showed a couple of leaks:
608 bytes in 4 blocks are definitely lost in loss record 184 of 229
at 0x4A081D4: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5BC88B0: xcalloc (xmalloc.c:162)
by 0x524F72D:
Marek,
This may be unrelated to your patches for PR 66127 and 66066 but I am
having a new failure when building the latest glibc with the latest GCC.
I haven't yet tracked down exactly which patch caused the problem. Included
is a cutdown test case from libio/memstream.c in glibc that results
On 12-05-15 12:04, Richard Biener wrote:
The fact that we have to handle this specially in both build_va_arg and
gimplify_va_arg makes me wonder whether we should be dealing with all this in
build_va_arg already.
That is, determine whether we take the address, and add the address operator
if so
On Wed, May 13, 2015 at 9:05 PM, Richard Henderson r...@redhat.com wrote:
On 05/13/2015 10:53 AM, Uros Bizjak wrote:
The only part that actually processes CONST_WIDE_INT is
alpha_legitimate_constant and movti expander. The latter immediately
splits any TImode CONST_WIDE_INTs.
Indeed. Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63513
zf zfefm at gmx dot de changed:
What|Removed |Added
CC||zfefm at gmx dot de
--- Comment
Hello,
after this patch I think I'll close the PR. This was regtested on
ppc64le-redhat-linux.
Apparently I wrote this patch in a file that already had a trivial hunk:
-1-A - ~A is rejected for complex while -A-1 isn't, there is no reason
for this difference (maybe there was before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66143
Bug ID: 66143
Summary: __gnat_set_executable insufficient for correct
gprinstall
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
On 14 May 2015 at 14:58, Jeff Law l...@redhat.com wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
On 14 May 2015 at 15:24, Jeff Law l...@redhat.com wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
In my tests, this gives the demangler near-complete support. Of a
sample of about 75k symbols pulled from the standard library
unittester, all but 20 were successfully parsed.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66130
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at
On 05/04/2015 03:27 PM, David Malcolm wrote:
@@ -158,7 +158,7 @@ expand_location_1 (source_location loc,
location (toward the expansion point) that is not reserved;
that is, the first location that is in real source code. */
loc =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66149
Bug ID: 66149
Summary: ICE: tree check: expected field_decl, have
template_decl in int_bit_position, at tree.h:5012 with
-std=c++14 -gstabs
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66150
Bug ID: 66150
Summary: [C++11] cv-qualifiers on function types are not
ignored.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
On 05/14/2015 01:24 PM, Segher Boessenkool wrote:
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is B or W), it picks alt 0, loop, everyone
The following patch is for solution of PR65862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
In some cases, calculations of reg class costs are not enough to choose
the right class. For example, in some cases you don't want to start fp
unit for energy saving considerations if you
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the operand
doesn't match (it is B or W), it picks alt 0, loop, everyone unhappy.
B should match it seems?
(Why does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903
--- Comment #4 from Laurent Chardon laurent.chardon at gmail dot com ---
Thanks for the fix. If I may suggest a modification of the testcase in order to
check also when there are no blanks between the and !. I know in Fortran it
shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66151
Bug ID: 66151
Summary: different override options
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66144
Segher Boessenkool segher at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
--- Comment #14 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
Author: vmakarov
Date: Thu May 14 20:40:44 2015
New Revision: 223202
URL: https://gcc.gnu.org/viewcvs?rev=223202root=gccview=rev
Log:
2015-05-14 Vladimir Makarov
On 04/24/2015 10:18 AM, Jiong Wang wrote:
2015-04-21 Jiong Wang jiong.w...@arm.com
gcc/
* loop-invariant.c (find_defs): Enable DF_DU_CHAIN build.
(vfp_const_iv): New hash table.
(expensive_addr_check_p): New boolean.
(init_inv_motion_data): Initialize new variables.
On 05/14/2015 01:15 PM, Iain Buclaw wrote:
Iant commited in the changes first time around. I don't have write
after approval access in GCC just yet, probably should go about
getting that sorted out if this is to become a regular thing. I dealt
with copyright assignments back in September.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66148
Bug ID: 66148
Summary: [6 regression] build/genpreds: Internal error: abort
in choose_enum_order, at genpreds.c:1006
Product: gcc
Version: 6.0
Status: UNCONFIRMED
On 14 May 2015 at 16:51, Jeff Law l...@redhat.com wrote:
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
On 14 May 2015 at 14:58, Jeff Law l...@redhat.com wrote:
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
If a symbol that has so far been valid abruptly ends then we will want
to fail the
Ping!
Could someone who can approve please review the patch?
Thanks,
-Andi
Nuno Diegues n...@ist.utl.pt writes:
Hello,
I have taken the chance to improve the patch by addressing the
comments above in this thread.
Namely:
- to use a simple random generator managed inside the library
This patch addresses the libgomp testsuite failure in
libgomp.oacc-fortran/data-2.f90 on nvidia targets. There are a couple of
things going on in here. The major underlying problem involved how
gomp_acc_remove_pointer was clearing target_mem_desc.to_free and
.tgt_end. That caused both a memory
On Thu, 2015-05-14 at 19:22 +0200, Marek Polacek wrote:
On Thu, May 14, 2015 at 10:07:56AM -0700, Steve Ellcey wrote:
Sorry for the noise, it looks like this failure is not related to any
recent changes in GCC. I still get the error in older GCC's so I think
something must have changed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152
Bug ID: 66152
Summary: suboptimal load bytes to stack
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
On Thu, 14 May 2015, Marek Polacek wrote:
Ping.
Joseph, do you have any further comments on the patch?
The C front-end changes are OK.
--
Joseph S. Myers
jos...@codesourcery.com
Jeff Law writes:
For all kinds of reassociation we have to concern ourselves with adding
overflow where it didn't already occur. Assuming a 32 bit architecture
we could get overflow if A is 0x7fff, b is -4 and and c = 3
0x7fff + -4 = 0x7ffb
0x7ffb + 3 = 0x7ffe
If
Snapshot gcc-4.8-20150514 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150514/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 05/14/2015 04:42 PM, Vladimir Makarov wrote:
The following patch is for solution of PR65862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
In some cases, calculations of reg class costs are not enough to
choose the right class. For example, in some cases you don't want to
start fp
On 05/14/2015 03:13 PM, Jiong Wang wrote:
Jeff Law writes:
For all kinds of reassociation we have to concern ourselves with adding
overflow where it didn't already occur. Assuming a 32 bit architecture
we could get overflow if A is 0x7fff, b is -4 and and c = 3
0x7fff + -4 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
--- Comment #5 from Dehao Chen dehao at google dot com ---
Could you try if the following patch fixes the bug?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66154
--- Comment #1 from Frank Heckenbach f.heckenb...@fh-soft.de ---
Somehow this got sent before the text was inserted, so here goes:
Also reported on Debian, but I was asked to report it here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66154
Bug ID: 66154
Summary: ReserveShadowMemoryRange test suite errors when memory
overcommitting is turned off on Linux
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66154
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
CC||dodji at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153
Bug ID: 66153
Summary: Internal compiler error in nested template function
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
On 05/14/2015 01:24 PM, Segher Boessenkool wrote:
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
The alternative that allows move to mem is alt 1, but it thinks the
operand
doesn't match (it is B or W), it picks alt 0, loop,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66018
--- Comment #14 from Thomas Preud'homme thopre01 at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #13)
This should be fixed now, please check.
It is indeed. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66152
--- Comment #1 from SztfG at yandex dot ru ---
If array of char is initialized using string, gcc can use larger mov
instruction, like movabsq, movq, movl etc. but not movdqa, movaps or other xmm
But if zero byte appears in string, compiler always
1 - 100 of 149 matches
Mail list logo
