32-bit and x32 user-space environments may be running under Linux/x86-64
kernel. Using "uname -m" isn't sufficient to properly detect the
canonical system name for 32-bit and x32 user-space environments. This
patch checks if compiler is configured for 64-bit, 32-bit or x32 objects
under Linux/x86
On Mon, Feb 23, 2015 at 09:17:43AM -0800, H.J. Lu wrote:
> 32-bit and x32 user-space environments may be running under Linux/x86-64
> kernel. Using "uname -m" isn't sufficient to properly detect the
> canonical system name for 32-bit and x32 user-space environments. This
> patch checks if compile
On Mon, 23 Feb 2015, H.J. Lu wrote:
> Tested with 64-bit, 32-bit and x32 user-space environments under
> Linux/x86-64 kernel. I am not sure if this will ever be accepted in
> upstream since the config.guess maintainer doesn't want to add a new
> use of set_cc_for_build to config.guess. set_cc_fo
On Mon, Feb 23, 2015 at 9:40 AM, Jakub Jelinek wrote:
> On Mon, Feb 23, 2015 at 09:17:43AM -0800, H.J. Lu wrote:
>> 32-bit and x32 user-space environments may be running under Linux/x86-64
>> kernel. Using "uname -m" isn't sufficient to properly detect the
>> canonical system name for 32-bit and
Hi!
Committed to trunk in r220915:
commit 0853f8db62498ecc36380aa2b352f812c37aae2f
Author: tschwinge
Date: Mon Feb 23 17:51:41 2015 +
[PR target/65181] nvptx libgcc: Prevent building "advanced" stuff (for
example, gcov support)
When building GCC against a proper newlib sysro
On Mon, Feb 23, 2015 at 09:49:43AM -0800, H.J. Lu wrote:
> On Mon, Feb 23, 2015 at 9:40 AM, Jakub Jelinek wrote:
> > On Mon, Feb 23, 2015 at 09:17:43AM -0800, H.J. Lu wrote:
> >> 32-bit and x32 user-space environments may be running under Linux/x86-64
> >> kernel. Using "uname -m" isn't sufficien
On Mon, Feb 23, 2015 at 9:52 AM, Jakub Jelinek wrote:
> On Mon, Feb 23, 2015 at 09:49:43AM -0800, H.J. Lu wrote:
>> On Mon, Feb 23, 2015 at 9:40 AM, Jakub Jelinek wrote:
>> > On Mon, Feb 23, 2015 at 09:17:43AM -0800, H.J. Lu wrote:
>> >> 32-bit and x32 user-space environments may be running under
On Fri, 2015-02-20 at 15:43 -0500, David Edelsohn wrote:
> On Fri, Feb 20, 2015 at 12:44 PM, Adhemerval Zanella
> wrote:
> > gcc/ChangeLog:
> >
> > * config/rs6000/htm.md (tcheck): Fix assembly encoding.
> >
> > gcc/testsuite/ChangeLog
> >
> > * gcc.target/powerpc/htm-builtin-1.c:
On 02/19/2015 12:31 PM, Aldy Hernandez wrote:
As explained in the PR, I would ideally like to get rid of the kludge
where we set the location of location-less FINALLY statements to be that
of the TRY statement, but that may be by design, and/or beyond the scope
of this fix.
This reminds me of t
On Mon, Feb 23, 2015 at 1:26 PM, Peter Bergner wrote:
> On Fri, 2015-02-20 at 15:43 -0500, David Edelsohn wrote:
>> On Fri, Feb 20, 2015 at 12:44 PM, Adhemerval Zanella
>> wrote:
>> > gcc/ChangeLog:
>> >
>> > * config/rs6000/htm.md (tcheck): Fix assembly encoding.
>> >
>> > gcc/testsuite/
On 02/23/2015 10:37 AM, Jason Merrill wrote:
On 02/19/2015 12:31 PM, Aldy Hernandez wrote:
As explained in the PR, I would ideally like to get rid of the kludge
where we set the location of location-less FINALLY statements to be that
of the TRY statement, but that may be by design, and/or beyond
Hi,
The attached patch fixes PR 65163.
Although the problem started to show up on trunk and not on the 4.8 /
4.9 branches, I've also backported it, since it's a latent bug.
Tested on trunk with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-
Hi!
To represent 128-bit unsigned multiplication results of 64-bit unsigned
operands one sometimes needs 3 HWIs instead of 2.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2015-02-23 Jakub Jelinek
PR tree-optimization/65170
* wide-int.cc (
On Mon, Feb 23, 2015 at 8:56 AM, Alan Modra wrote:
> get_memreg_parts can return a memory base other than a REG, when the
> memory address in question is a PLUS with other than a REG as its
> first operand. This leads to an ICE with rtl checking enabled on the
> following, since the callers of ge
Hi!
The "ODR" checking lib libsanitizer isn't really ODR checking and relies on
the LLVM way of registering the same symbol multiple times, where GCC uses
private aliases and the only time "ODR violatilation" is reported is when
there are symbol aliases.
Until libsanitizer rewrites this to use na
On 02/12/15 08:49, Jonathan Wakely wrote:
This changes __attribute__((unused)) to __attribute__((__unused__)) in
three gthr-*.h headers. As Jakub pointed out at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64885#c7 there are still
lots of other problems in these headers, but they have been there
PING!
> -Original Message-
> From: Iyer, Balaji V
> Sent: Thursday, February 19, 2015 10:43 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH] Fix for PR c++/60198
>
> Hello Everyone,
> Attached, please find a patch that is a fix for PR c++/60198. Is this OK
> for trunk?
>
> Here
On 02/22/15 11:49, David Edelsohn wrote:
The patch below tweaks the ppc64-abi-1.c test to make it less
prone to volatile registers getting clobbered before the test
has had a chance to save them for later comparison to their
expected values. This resolves the test failure discussed
in PR 65109.
Jakub Jelinek writes:
> Hi!
>
> To represent 128-bit unsigned multiplication results of 64-bit unsigned
> operands one sometimes needs 3 HWIs instead of 2.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk?
>
> 2015-02-23 Jakub Jelinek
>
> PR tree-opt
On 02/23/15 00:23, Tom de Vries wrote:
Hi,
This patch fixes PR65126, which is about the fact that the cleanup procs
are not cleaning up files generated from additional_sources. This
happens because dg-additional-files-options empties additional_sources
before the cleanup procs can use it.
Examp
The comment for wi::from_mpz says:
/* Returns X converted to TYPE. If WRAP is true, then out-of-range
values of VAL will be wrapped; otherwise, they will be set to the
appropriate minimum or maximum TYPE bound. */
The problem in PR 63427 was that we didn't actually implement the WRAP
case
On 02/17/15 07:03, Richard Biener wrote:
This is something I noticed some time ago and that I remembered when
you added that looping SSA_NAME_VALUE to simplify_control_stmt_condition.
Currently DOM doesn't make sure that when setting
SSA_NAME_VALUE (x) = y that SSA_NAME_VALUE (y) == y, thus you
On 02/22/15 02:02, Chen Gang S wrote:
It is for Bug65117, after this fix, ".i" file can be passed compiling.
- 'this_alternative_win' is not initialized before use it: for the
first looping 0, it initializes 'this_alternative_win[0]', but
'did_match' may use 'this_alternative_win[2]
On 02/23/15 15:00, Richard Sandiford wrote:
The comment for wi::from_mpz says:
/* Returns X converted to TYPE. If WRAP is true, then out-of-range
values of VAL will be wrapped; otherwise, they will be set to the
appropriate minimum or maximum TYPE bound. */
The problem in PR 63427 was
[text only]
Looks good.
I am not planing to work on the fix any time soon, co I encourage you
or someone else interested to send patches to fix the problem in LLVM.
Since you are also committing a test we should not accidentally remove
this patch with the next merge.
Thanks!
--kcc
On Mon, Feb 23
On Mon, Feb 23, 2015 at 11:26 PM, Jeff Law wrote:
> On 02/22/15 02:02, Chen Gang S wrote:
>>
>> It is for Bug65117, after this fix, ".i" file can be passed compiling.
>>
>>- 'this_alternative_win' is not initialized before use it: for the
>> first looping 0, it initializes 'this_alternativ
On 02/23/15 16:09, Steven Bosscher wrote:
Which violate the rule for matching constraints.
...and should never have worked at all...
Yup. It's only been fairly recently that we started statically checking
MD files in any significant way -- we've still got a long way to go I'm
sure.
I
On 02/18/15 15:27, Sebastian Pop wrote:
Jeff Law wrote:
These kinds of situations are normally pruned out in mark_threaded_blocks.
I added the FSM code generation before calling mark_threaded_blocks.
OK. Hmm. Makes me wonder what happens if we have a normal jump thread
path embedded inside
The attached patch is to fix PR target/65153 which is a 4.9.2
regression and latent on trunk. The patch removes a problematic
peephole and sh.c:replace_n_hard_rtx of which that peephole is
the last user. Oleg shows that the patch doesn't give any
significant differences with CSiBE tests. See
htt
On Tue, Feb 24, 2015 at 2:30 AM, augustine.sterl...@gmail.com
wrote:
> On Sat, Feb 21, 2015 at 4:19 PM, Max Filippov wrote:
>>
>> gcc for xtensa always aligns data at least to a word boundary, even when
>> it has smaller natural alignment. This results in unexpectedly high data
>> section sizes a
On Sat, Feb 21, 2015 at 4:19 PM, Max Filippov wrote:
> gcc for xtensa always aligns data at least to a word boundary, even when
> it has smaller natural alignment. This results in unexpectedly high data
> section sizes and unreasonable amount of wasted space when linking
> objects compiled with -f
On 02/23/2015 03:36 AM, Patrick Marlier wrote:
On 02/22/2015 04:06 AM, Sandra Loosemore wrote:
+Here is an example showing handling for @code{_XABORT_RETRY}
+and a fallback path for other failures:
+
+@smallexample
+#include
+
+int n_tries, max_tries;
+unsigned status = _XBEGIN_STARTED;
I woul
On 2/24/15 07:14, Jeff Law wrote:
> On 02/23/15 16:09, Steven Bosscher wrote:
>>>
>>>
>>> Which violate the rule for matching constraints.
>>
>> ...and should never have worked at all...
> Yup. It's only been fairly recently that we started statically checking MD
> files in any significant way --
lis 9,.LANCHOR1@ha
lvsr 13,0,8
addi 10,10,16
la 9,.LANCHOR1@l(9)
lvx 0,0,10
li 3,0
vperm 0,1,0,13
stvx 0,0,9
blr
...while 5.0.0 20150223 emits this:
main1:
lis 7,.LANCHOR0@ha
stwu 1,-32(1)
la 7,.LANCHOR0@l(7)
On 23-02-15 11:09, Tom de Vries wrote:
On 23-02-15 09:26, Michael Matz wrote:
Hi,
On Sun, 22 Feb 2015, Tom de Vries wrote:
Btw, I'm wondering if as run-time optimization we can tentatively set
PROP_gimple_lva at the start of the gimple pass, and unset it in
gimplify_va_arg_expr. That way we w
Hi,
I found a fort.10 file in the test directories, and tracked it back to
readwrite_unf_direct_eor_1.f90, which creates fort.10 but doesn't remove it.
This patch fixes that.
Tested by running the test-case and checking that fort.10 doesn't appear anymore
in the test directory.
Committed a
On 22-02-15 21:48, Arnaud Charlet wrote:
I didn't see a question here:
...
As for the @dircategory I do not know, I couldn't find a proper documentation
for this node other than:
http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Installing-Dir-Entries.html#index-dircategory
which is in
Hi,
On Sun, 22 Feb 2015, Tom de Vries wrote:
> Btw, I'm wondering if as run-time optimization we can tentatively set
> PROP_gimple_lva at the start of the gimple pass, and unset it in
> gimplify_va_arg_expr. That way we would avoid the loop in
> expand_ifn_va_arg_1 (over all bbs and gimples) i
On Sat, 21 Feb 2015, Thomas Schwinge wrote:
> Hi!
>
> On Sat, 21 Feb 2015 17:22:40 +0100, I wrote:
> > On Mon, 10 Jun 2013 14:01:53 +0200 (CEST), Richard Biener
> > wrote:
> > > This fixes one very annoying thing collect2 does when trying to
> > > debug LTO WPA issues. Even with -v you need to
On Sun, 22 Feb 2015, Tom de Vries wrote:
> On 20-02-15 12:54, Richard Biener wrote:
> > On Thu, 19 Feb 2015, Tom de Vries wrote:
> >
> > > On 19-02-15 14:07, Richard Biener wrote:
> > > > On Thu, 19 Feb 2015, Jakub Jelinek wrote:
> > > >
> > > > > On Thu, Feb 19, 2015 at 01:44:46PM +0100, Richar
Hi!
On Thu, 15 Jan 2015 21:20:07 +0100, I wrote:
> In r219682, I have committed to trunk our current set of OpenACC changes,
> which we had prepared on gomp-4_0-branch. [...]
> gcc/ada/
> * gcc-interface/utils.c (DEF_FUNCTION_TYPE_VAR_8)
> (DEF_FUNCTION_TYPE_VAR_12): New macros
On 23-02-15 09:26, Michael Matz wrote:
Hi,
On Sun, 22 Feb 2015, Tom de Vries wrote:
Btw, I'm wondering if as run-time optimization we can tentatively set
PROP_gimple_lva at the start of the gimple pass, and unset it in
gimplify_va_arg_expr. That way we would avoid the loop in
expand_ifn_va_arg
Hi!
In r220911, I have committed a merge from trunk r220892 (2015-02-22) into
gomp-4_0-branch.
Grüße,
Thomas
pgp70Isqy2lOJ.pgp
Description: PGP signature
On 02/22/2015 04:06 AM, Sandra Loosemore wrote:
On 02/19/2015 12:36 PM, Sandra Loosemore wrote:
On 02/19/2015 09:38 AM, Patrick Marlier wrote:
Thanks Sandra. Just a minor comment.
-Valid abort status bits (when the value is not
@code{_XBEGIN_STARTED}) are:
+If the transaction aborts, the retur
This patch fixes PR64331 which produced wrong code because of outdated (too
many) REG_DEAD notes. These notes are not (re)computed per default, hence do
the computation by hand each time avr.c:reg_unused_after is called in a
different pass.
Ok to apply?
Johann
gcc/
PR target/64331
On Mon, Feb 23, 2015 at 11:53:52AM +0100, Georg-Johann Lay wrote:
> This patch fixes PR64331 which produced wrong code because of outdated (too
> many) REG_DEAD notes. These notes are not (re)computed per default, hence
> do the computation by hand each time avr.c:reg_unused_after is called in a
>
get_memreg_parts can return a memory base other than a REG, when the
memory address in question is a PLUS with other than a REG as its
first operand. This leads to an ICE with rtl checking enabled on the
following, since the callers of get_memreg_parts expect a REG.
(gdb) p debug_rtx(addr_rtx)
(p
This include stdfix-avrlibc.h in the avr-gcc specific stdfix.h.
Ok for trunk?
Johann
gcc/
* config/avr/stdfix.h [__WITH_AVRLIBC__]: Include .
Index: config/avr/stdfix.h
===
--- config/avr/stdfix.h (revision 220854)
+++ co
2015-02-23 13:53 GMT+03:00 Georg-Johann Lay :
> This patch fixes PR64331 which produced wrong code because of outdated (too
> many) REG_DEAD notes. These notes are not (re)computed per default, hence
> do the computation by hand each time avr.c:reg_unused_after is called in a
> different pass.
>
>
2015-02-23 17:12 GMT+03:00 Georg-Johann Lay :
> This include stdfix-avrlibc.h in the avr-gcc specific stdfix.h.
>
> Ok for trunk?
>
> Johann
>
>
>
> gcc/
> * config/avr/stdfix.h [__WITH_AVRLIBC__]: Include
> .
Approved.
Denis.
On Sun, Feb 22, 2015 at 7:45 PM, David Edelsohn wrote:
> Does this patch really fix the problem? The PR notes that the
> testcase fails and code quality has regressed. Has the code
> generation been corrected but the testcase looks for the wrong string?
> Presumably the message that basic block
Hi,
this patch is a rewrite of libgomp.oacc-c-c++-common/reduction-1.c (included as
a whole in the patch prefix).
The patch attempts to get rid of the errorprone copy-paste style. An example of
such an error in this test-case is:
...
result = 5;
vresult = 5;
lresult = false;
lvresul
On Mon, Feb 23, 2015 at 04:52:56PM +0100, Tom de Vries wrote:
> The only thing I'm not sure about is the two-level pragma expansion using
> the apply pragmas. It maximizes factoring out common parts, but it makes
> things less readable.
>
> Tested on x86_64.
>
> OK for stage4?
If Thomas is ok wi
On 23-02-15 17:08, Jakub Jelinek wrote:
On Mon, Feb 23, 2015 at 04:52:56PM +0100, Tom de Vries wrote:
The only thing I'm not sure about is the two-level pragma expansion using
the apply pragmas. It maximizes factoring out common parts, but it makes
things less readable.
Tested on x86_64.
OK fo
54 matches
Mail list logo
