I'm very skeptical... In any case, having a type whose TYPE_SIZE is smaller
than the size of its MODE is a lie which will bite you back at some point.
Except gcc now knows the size of partial int modes. In this case,
PSImode is 20 bits and TYPE_SIZE is 20 bits, so they match.
The code was
Ping.
On 2014-07-02 10:15, Sebastian Huber wrote:
This change is necessary to support Cortex-R based chips in RTEMS.
This patch should be applied to GCC 4.8, 4.9 and mainline. I do not
have write access, so in case this gets approved, please commit it for
me.
gcc/ChangeLog
2014-07-02
Ping.
On 2014-06-26 13:43, Sebastian Huber wrote:
This patch should be applied to GCC 4.9 and mainline. I do not have
write access, so in case this gets approved, please commit it for me.
gcc/ChangeLog
2014-06-26 Sebastian Huber sebastian.hu...@embedded-brains.de
* config.gcc
On Sun, Jul 6, 2014 at 11:13 PM, FX fxcoud...@gmail.com wrote:
Actually, it makes a lot of sense to change these into static assertions:
this way, any target-specific issues with FP-state buffer size will show up
at libgfortran-building-time, rather than be swept under the rug.
Since
On 01/07/14 18:21, Kugan wrote:
On 26/06/14 20:12, Jakub Jelinek wrote:
On Thu, Jun 26, 2014 at 07:41:22PM +1000, Kugan wrote:
2014-06-26 Kugan Vivekanandarajah kug...@linaro.org
* calls.c (precompute_arguments): Use new SUBREG_PROMOTED_SET
instead of SUBREG_PROMOTED_UNSIGNED_SET
For -fwrapv I don't see why you'd get into trouble ever, the VRP computation
should be well aware of the -fwrapv semantics and the value ranges should
reflect that.
For -fno-strict-overflow, I have no idea since it is very weirdly defined.
In any case, for your example above, the loop is
Dear All,
This PR is caused by a rather unfortunate cast for the pointer to the
return value from matmul:
struct array1_real(kind=4) D.2357;
D.2357 = *(struct array1_real(kind=4) *) __result;
D.2357.data = 0B;
snip
_gfortran_matmul_r4 (*(struct array1_real(kind=4)
/sysv/linux/raise.c:67
#2 0x20435ab0 in *__GI_abort () at abort.c:92
#3 0x49e0 in C::m_virt (this=0x4760 main()+96)
at /usr/local/gcc/gcc-20140707/gcc/testsuite/g++.dg/ipa/pr61085.C:26
#4 0x4760 in m_foo (this=0x600eee40)
at /usr/local/gcc
Ping.
The patch is at [1].
[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02430.html
Thanks,
Uros.
On Mon, Jun 30, 2014 at 9:59 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
After fixing _.barriers and _.eh_range passes w.r.t. CALL_ARG_LOCATION
notes, we can finaly move handling of
On Sun, 29 Jun 2014, Gerald Pfeifer wrote:
On Thu, 12 Jun 2014, Richard Biener wrote:
It seems the https transition broke refering to permanently moved
URL gcc-3.0/gcc-3.0.html (I get a certificate error or some such),
breaking gennews and thus gcc_release. Fixed like below which
makes
Jan Hubicka hubi...@ucw.cz writes:
Index: testsuite/g++.dg/ipa/imm-devirt-2.C
===
--- testsuite/g++.dg/ipa/imm-devirt-2.C (revision 212278)
+++ testsuite/g++.dg/ipa/imm-devirt-2.C (working copy)
@@ -1,7 +1,7 @@
/*
Paul Richard Thomas wrote:
This PR is caused by a rather unfortunate cast for the pointer to the
return value from matmul:
[...]
The fix is obvious (ie use its natural kind)
[...]
Dominique points out that the patch fixes PR58883 as well. I'll
enhance the testcase appropriately.
Nice!
On Mon, Jul 07, 2014 at 04:52:39PM +1000, Kugan wrote:
Ok with following nit:
+/* Checks if RTX of SUBREG_PROMOTED_VAR_P() is promoted for given SIGN. */
+#define SUBREG_CHECK_PROMOTED_SIGN(RTX, SIGN)\
+((SIGN) == SRP_POINTER ? SUBREG_PROMOTED_GET (RTX) == SRP_POINTER\
+ :
On Sun, 29 Jun 2014, Jan Hubicka wrote:
In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.
Hello,
the problem here is that we have POINTER_TYPE that points to array of variable
length (not sure why it happens only with -O0). The ICE is introduced
On Mon, 30 Jun 2014, Jan Hubicka wrote:
Please revert the original patch instead which was not tested properly.
I'll get back to this after I return from vacation.
OK, I will bootstrap and revert tomorrow morning.
Note that testusite passes with the patch; the problem appears only
On Mon, 30 Jun 2014, Dominique Dhumieres wrote:
Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
the addition of '-g -flto'. Is it worth pushing in this direction?
Yes. It
On Thu, 3 Jul 2014, Jakub Jelinek wrote:
On Thu, Jul 03, 2014 at 09:41:15AM +0200, Richard Biener wrote:
On July 3, 2014 7:37:13 AM CEST, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jul 02, 2014 at 04:06:30PM -0700, Jason Merrill wrote:
I think that makes sense; I'm not aware of anyone
Hi,
On 07/06/2014 08:20 PM, Tim Shen wrote:
I'd like to merge testcases to several huge files (char, wchar_t,
dg-do compile, locales, etc.) to (greatly) reduce duplicated regex
compilation.
We do not really care the fine-grained test report, do we? We hope
them all PASS.
Yes. As long as it's
Furthermore, on 2014-05-12 I committed a patch changing libgfortran to
be built with -std=gnu11 instead of -std=gnu99, so that we can make
use of C11 functionality; see
https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
Committed as rev. 212323, thanks for the review.
I now propose the
FX fxcoud...@gmail.com writes:
Unfortunately, while the patch works fine on Solaris/x86, it broke
Solaris/SPARC bootstrap for trivial reasons: contrary to the ChangeLog,
configure and config.h.in weren't regenerated, thus FPSETSTICKY
wasn't defined.
I apologize. Thanks for checking in the
Hi Rainer,
while the i386/amd64 values are the usual ones. Unfortunately,
gcc/fortran/libgfortran.h hardcodes the more common values for
GFC_FPE_*, and libgfortran/Makefile.am extracts them from there into
fpu-target.inc. I'm unsure what's the best way to handle this.
No, we don’t hardcode
On Sat, Jun 28, 2014 at 8:22 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
This is first bug noticed by the type consistency checks I added.
gcov_info_type is a structure that contains function pointer to itself. While
building it we first build a structure w/o size and fields, then we build a
On Sat, Jun 28, 2014 at 8:26 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is another bug noticed. Here ipa-devirt attempts to merge binfos of two
representations
of the same ODR type, but forgets about variants.
I also noticed that using variant instead of the type may end up in
On Sat, Jun 28, 2014 at 10:38 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
Applied.
Richi, Jakub, I noticed that you seem to have stopped including those
with GCC 4.7 and later. Any particular reason? It appears useful to
me.
Are you sure? I can still see them in 4.7 changes.html and
On Sun, Jun 29, 2014 at 12:44 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch fixes another problem where we manage to produce a variant of
variadic array that has different TYPE_SIZE (but an equivalent expression).
This happens because remap_type_1 blindly copies all expressions referred
Hi FX,
while the i386/amd64 values are the usual ones. Unfortunately,
gcc/fortran/libgfortran.h hardcodes the more common values for
GFC_FPE_*, and libgfortran/Makefile.am extracts them from there into
fpu-target.inc. I'm unsure what's the best way to handle this.
No, we don’t hardcode
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.
The new function is copied from init_subtree_with_zero right above. I guess
it
FWIW, those FP_* values are also enum values in IRIX 6.5 ieeefp.h, the
only other SysV target I have around. Seems this file is common between
all of them, so the risk should be manageable.
The following patch does away with the #ifdef stuff and lets all
gfortran.dg/ieee tests PASS on
On Mon, Jun 30, 2014 at 8:56 AM, Jeff Law l...@redhat.com wrote:
SSA_NAME_VALUE is, in effect, a chain of values. ie, it's possible for
SSA_NAME_VALUE of any given SSA_NAME to refer to another SSA_NAME.
Hmm, but it shouldn't as we walk in dominator order and should
always do
FX fxcoud...@gmail.com writes:
FWIW, those FP_* values are also enum values in IRIX 6.5 ieeefp.h, the
only other SysV target I have around. Seems this file is common between
all of them, so the risk should be manageable.
The following patch does away with the #ifdef stuff and lets all
On 04/07/14 17:24, Kyrill Tkachov wrote:
Hi all,
-mwords-little-endian was deprecated in GCC 4.7. This patch removes the
option and associated machinery and documentation.
Tested armeb-none-eabi and saw no regressions.
Ok for trunk?
Thanks,
Kyrill
2014-07-04 Kyrylo Tkachov
On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson r...@redhat.com wrote:
On 06/29/2014 11:14 AM, Uros Bizjak wrote:
if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr) == AND)
+ return 1;
return 0;
Certainly missing braces here. But with that fixed the patch looks plausible.
On Mon, Jul 7, 2014 at 11:29 AM, FX fxcoud...@gmail.com wrote:
Furthermore, on 2014-05-12 I committed a patch changing libgfortran to
be built with -std=gnu11 instead of -std=gnu99, so that we can make
use of C11 functionality; see
https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
What about --disable-bootstrap? Does it just skip stage1 and stage2,
and stage3 is used to compile libgfortran, or is the host compiler
used to build libgfortran as well? If the former, yes I guess we can
remove #ifnderf __GNUC__ stuff?
Even with --disable-bootstrap, libgfortran is compiled
Dear Tobias,
The patch is so safe and, as you say, has no side effects that I will
commit to 4.9 first.
Cheers
Paul
On 7 July 2014 10:05, Tobias Burnus tobias.bur...@physik.fu-berlin.de wrote:
Paul Richard Thomas wrote:
This PR is caused by a rather unfortunate cast for the pointer to the
On 3 July 2014 10:34, Tom de Vries tom_devr...@mentor.com wrote:
On 03-07-14 10:20, Marcus Shawcroft wrote:
On 2 July 2014 09:02, Tom de Vries tom_devr...@mentor.com wrote:
On 02-07-14 08:23, Marc Glisse wrote:
In the first example you gave, looking at the pattern (no match_dup,
setting
On 7 July 2014 11:29, Christophe Lyon christophe.l...@linaro.org wrote:
On 3 July 2014 10:34, Tom de Vries tom_devr...@mentor.com wrote:
On 03-07-14 10:20, Marcus Shawcroft wrote:
On 2 July 2014 09:02, Tom de Vries tom_devr...@mentor.com wrote:
On 02-07-14 08:23, Marc Glisse wrote:
In the
On Mon, 7 Jul 2014, Richard Biener wrote:
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.
The new function is copied from
Hi,
LOCALEDIR seams a build-time constant, which is an absolute path. But
* When releasing gcc binaries as a tarball, users can put it at any dir.
* For Canadian build, the dir layout on the build machine might be
different from the host machine.
For such cases, gcc most likely can not find the
Hi,
in April Andrew figured out that:
The problem occurs in cp_parser_cast_expression. A term of having the
form (T())... cannot be parsed as a cast expression since the the
expansion is only applied to a part of the cast expression. If ...
follows the closing paren, the expression must be
On Thu, Jul 3, 2014 at 1:08 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
So apparently its not entirely obvious to everyone that removing the names of
unused arguments is the best way of dealing with warnings about unused
arguments in places like hooks
On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
richard.guent...@gmail.com wrote:
On Thu, Jul 3, 2014 at 1:08 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
So apparently its not entirely obvious to everyone that removing the names of
unused arguments is
On Thu, Jul 3, 2014 at 2:39 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Ping!
Ok.
Thanks,
Richard.
2014-06-24 13:37 GMT+04:00 Yuri Rumyantsev ysrum...@gmail.com:
Hi All,
Here is a fix for PR 61576 - additional test was added that block
containing reduction statement is predecessor of
Hi Cesar!
On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis
cesar_philippi...@mentor.com wrote:
This patch is the first step to enabling parallel reductions in openacc.
Thanks!
As mentioned earlier, this patch isn't complete yet. For starters, parts
of it depends on our internal ptx
On Thu, Jul 3, 2014 at 11:53 AM, Mark Wielaard m...@redhat.com wrote:
Hi,
I pulled out the guality.exp [p]type test extension from the actual
dwarf2out.c changes (which I will repost soon with some tweaks). I think
the test extension itself is useful on its own (and will use it to
add tests
Janne Blomqvist wrote:
On Mon, Jul 7, 2014 at 11:29 AM, FX fxcoud...@gmail.com wrote:
PS: I didnât touch libcaf, as I assume this might be compiled with a
different compiler. Am I right?
My understanding is that libcaf is delivered in source form, and the
end user is expected to compile
On Mon, Jul 7, 2014 at 12:16 PM, FX fxcoud...@gmail.com wrote:
What about --disable-bootstrap? Does it just skip stage1 and stage2,
and stage3 is used to compile libgfortran, or is the host compiler
used to build libgfortran as well? If the former, yes I guess we can
remove #ifnderf __GNUC__
On Sun, Jul 6, 2014 at 4:23 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 30 Jun 2014, Jeff Law wrote:
On 06/28/14 16:33, Marc Glisse wrote:
In an earlier version of the patch, I was using
get_or_create_ssa_default_def (cfun, sym);
(I was reusing the same variable). This passed
As ARC maintainer, I have applied the appended patch to changes.html.
tmp
Description: Binary data
On Jul 5, 2014, at 11:42 AM, Gerald Pfeifer ger...@pfeifer.com wrote:
Farther below in wide-int.h, we define wide_int_storage as a class:
class GTY(()) wide_int_storage
{
private:
HOST_WIDE_INT val[WIDE_INT_MAX_ELTS];
unsigned int len;
unsigned int precision;
:
The patch
Hi all,
This patch adds the rtx costs table for the Cortex-A5 core.
Tested arm-none-eabi and looked at the codegen for various codebases to
make sure there's no regression in code quality.
Ok for trunk?
Thanks,
Kyrill
2014-07-07 Kyrylo Tkachov kyrylo.tkac...@arm.com
*
Hi,
This change implements little-endian code generation for Signal
Processing Engine (SPE) operations.
Where possible changes are handled within the existing patterns with
suitable conditionals added to support the little-endian mode.
In some cases operand constraints are different
Hi Ramana/Maxim,
On 18 June 2014 16:05, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
Hi Ramana,
On 18 June 2014 15:29, Ramana Radhakrishnan ramana@googlemail.com wrote:
On Mon, Jun 16, 2014 at 1:53 PM, Venkataramanan Kumar
venkataramanan.ku...@linaro.org wrote:
Hi
In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
I wrote
I am now trying to do the back port to 4.9 and I got two failures: ...
Actually I did not applied the right patch, with it the testsuite pass without
regression. Still OK for 4.9.1?
TIA
Dominique
Right, that's what I (vaguelly) remembered. Please consider a patch
removing the ifndef __GNUC__ stuff from libgfortran.h pre-approved.
The only occurrence (outside of libcaf) is in libgfortran.h. Committed attached
patch as rev. 212328, after building on x86_64-linux.
FX
x
Description:
Dear Dominique,
On condition that your commit the right patch :-), OK for 4.9.1
Cheers
Paul
On 7 July 2014 13:48, Dominique Dhumieres domi...@lps.ens.fr wrote:
In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
I wrote
I am now trying to do the back port to 4.9 and I got two failures:
Dear Dominique,
OK for trunk.
Thanks for the patch
Paul
On 5 July 2014 18:09, Dominique Dhumieres domi...@lps.ens.fr wrote:
On Mon, 05 May 2014, I have posted
https://gcc.gnu.org/ml/fortran/2014-05/msg00012.html.
On IRC Tobias Burnus remarked that the *.mod file in
On 07/07/2014 00:16, Mircea Namolaru wrote:
Hello,
In the isl library used by Graphite, isl_val replaced isl_val (that become
obsolete).
This patch implements the required changes in Graphite.
No regressions for c/c++/fortran on x86-64 Linux.
Hi Mircea,
the patch looks good and the
On Sun, Jun 29, 2014 at 12:44 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch fixes another problem where we manage to produce a variant of
variadic array that has different TYPE_SIZE (but an equivalent expression).
This happens because remap_type_1 blindly copies all expressions
To quote William Shakespeare:
FALSTAFF
‘Tis not due yet; I would be loath to pay him before
his day. What need I be so forward with him that
calls not on me? Well, ’tis no matter; honour pricks
me on. Yea, but how if honour prick me off when I
come on? how then? Can honour set to a leg? no: or
an
Btw - this points to the obvious opportunity to make variant types
a lot smaller (with the caveat to require an indirection to the main
variant to access shared bits). That would also automagically
help LTO streaming
Yeah, I was playing with this idea. Lets get things checked and
2014-07-07 Maciej W. Rozycki ma...@codesourcery.com
gcc/
* config/rs6000/rs6000.c (output_vec_const_move): Handle
little-endian code generation.
* config/rs6000/spe.md (spe_evmergehi): Rename to...
(vec_perm00_v2si): ... this. Handle little-endian code
generation.
(spe_evmergehilo): Rename
On condition that your commit the right patch :-), OK for 4.9.1
Indeed! Committed as r212329.
Thanks for the review.
Dominique
Hi,
This patch removes repeating strlen instrumentation.
Regtested/bootstrapped on x86_64-unknown-linux-gnu.
Ok to commit?
-Maxim
gcc/ChangeLog:
2014-06-24 Max Ostapenko m.ostape...@partner.samsung.com
* asan.c (instrument_strlen_call): Do not instrument first byte in strlen
if
On Mon, Jul 07, 2014 at 06:09:41PM +0400, Maxim Ostapenko wrote:
This patch removes repeating strlen instrumentation.
Regtested/bootstrapped on x86_64-unknown-linux-gnu.
Ok to commit?
Ok.
Jakub
This patch addresses an old issue of warning about macro touching string
literal even if the code is skipped:
#define BAZ baz
#if 0
barBAZ
#endif
Just skip the warning Wliteral-suffix if the preprocessor is skipping.
Built and tested on x86_64-linux.
OK?
And for 4.9?
Thanks,
Ed
On 07/07/2014 02:10 AM, Richard Biener wrote:
On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson r...@redhat.com wrote:
On 06/29/2014 11:14 AM, Uros Bizjak wrote:
if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr) == AND)
+ return 1;
return 0;
Certainly missing braces here.
When simplifying the points-to-set comparison I failed to realize
we don't expand ESCAPED special vars. The following does that
for the only interesting one (NONLOCAL).
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Will apply to trunk and 4.9 branch if that succeeds.
Richard.
The following fixes PR61680.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-07-07 Richard Biener rguent...@suse.de
PR tree-optimization/61680
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence):
Handle properly all read-write
On Mon, 7 Jul 2014, David Edelsohn wrote:
gcc/
* config/rs6000/rs6000.c (output_vec_const_move): Handle
little-endian code generation.
* config/rs6000/spe.md (spe_evmergehi): Rename to...
(vec_perm00_v2si): ... this. Handle little-endian code
generation.
(spe_evmergehilo): Rename to...
On 07/07/2014 06:17 PM, Jakub Jelinek wrote:
On Mon, Jul 07, 2014 at 06:09:41PM +0400, Maxim Ostapenko wrote:
This patch removes repeating strlen instrumentation.
Regtested/bootstrapped on x86_64-unknown-linux-gnu.
Ok to commit?
Ok.
Jakub
Thanks, done in r212332.
-Maxim
On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson r...@redhat.com wrote:
On 07/07/2014 02:10 AM, Richard Biener wrote:
On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson r...@redhat.com wrote:
On 06/29/2014 11:14 AM, Uros Bizjak wrote:
if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr)
On 07/03/2014 02:53 AM, Evgeny Stupachenko wrote:
-expand_vec_perm_palignr (struct expand_vec_perm_d *d)
+expand_vec_perm_palignr (struct expand_vec_perm_d *d, int insn_num)
insn_num might as well be bool avx2, since it's only ever set to two values.
- /* Even with AVX, palignr only operates
On Mon, Jul 7, 2014 at 4:34 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson r...@redhat.com wrote:
On 07/07/2014 02:10 AM, Richard Biener wrote:
On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson r...@redhat.com wrote:
On 06/29/2014 11:14
On 27 Jun 09:32, Bernd Schmidt wrote:
Sorry for the delayed reply, I was travelling. There seem to be some
thinkos in the configure script and Makefile; can you try the
following (don't forget to regenerate configure)? It seems to work
for ptx (with some additional changes to allow ptx builds
On 07/07/2014 07:34 AM, Richard Biener wrote:
Ugh. I wasn't aware of that - is this documented anywhere? What
exactly does such address conflict with? Does it inhibit type-based analysis?
Dunno if it's documented anywhere. Such addresses conflict with anything,
unless it can be proven not
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
2) Or should I build accel compiler as a cross from
x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
Yes, that's the general idea.
Will it help to distinguish the libs?
Is libgomp the only problematic one? (Does the accel compiler even need
On Mon, Jul 7, 2014 at 10:33 AM, Maciej W. Rozycki
ma...@codesourcery.com wrote:
Could you add a short comment explaining what the 0 and 1 labels
in vec_perm[01][01]_v2si mean?
Like this?
Maciej
gcc-ppc-spe-le-update.diff
Index: gcc-fsf-trunk-quilt/gcc/config/rs6000/spe.md
On Mon, Jul 07, 2014 at 05:03:07PM +0200, Bernd Schmidt wrote:
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
2) Or should I build accel compiler as a cross from
x86_64-pc-linux-gnu to x86_64-intelmic-linux-gnu?
Yes, that's the general idea.
Will it help to distinguish the libs?
Is libgomp
On Mon, Jul 07, 2014 at 05:14:27PM +0200, Jakub Jelinek wrote:
We need a libgomp for the offload targets to be different from the host
libgomp even on targets like mic, because there are various omp_* functions
that should behave differently. Or the host libgomp needs to have a way how
to
Hi,
tested x86_64-linux, committed as obvious.
Thanks,
Paolo.
/cp
2014-07-07 Paolo Carlini paolo.carl...@oracle.com
* class.c (check_for_override): Wrap the 'final' and 'override'
keywords in % and %.
/testsuite
2014-07-07 Paolo Carlini
On Mon, 7 Jul 2014, David Edelsohn wrote:
Yes, that's good. It helps if someone reading the code doesn't need to
reverse engineer the numbering convention of the name.
Sure, I haven't questioned your request. Thanks for your review, applied
now.
Maciej
Dave,
I guess if \[ \t\]_*myBindC worked on hppa*-*-linux*, then it would
probably work on hpux and the target condition could be removed.
Does this mean that the following patch will succeed on hppa*-*-*
without/with -flto?
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
Dear Paul,
OK for trunk.
Thanks for the review. Committed as r212330.
Dominique
On Fri, Jul 04, 2014 at 03:45:10PM +0100, Marcus Shawcroft wrote:
On 24 June 2014 09:45, James Greenhalgh james.greenha...@arm.com wrote:
2014-06-20 James Greenhalgh james.greenha...@arm.com
* config/aarch64/aarch64-simd.md (move_lo_quad_internal_mode):
New.
On Mon, Jul 7, 2014 at 5:01 PM, Richard Henderson r...@redhat.com wrote:
Early alpha can't store sub-4-byte quantities. Altivec can't store anything
but 16 byte quantities. In order to perform smaller stores, we have to do a
read-modify-write sequence on a larger aligned chunk of memory.
On 7/7/2014 12:13 PM, Dominique Dhumieres wrote:
Does this mean that the following patch will succeed on hppa*-*-*
without/with -flto?
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +0200
+++
On 07/07/14 02:56, Richard Biener wrote:
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.
The new function is copied from
I've changed the heading to ARC and put the item in its
proper alpha-sorted position to make it easier to find.
tmp
Description: Binary data
On 07/07/2014 09:35 AM, Uros Bizjak wrote:
On Mon, Jul 7, 2014 at 5:01 PM, Richard Henderson r...@redhat.com wrote:
Early alpha can't store sub-4-byte quantities. Altivec can't store anything
but 16 byte quantities. In order to perform smaller stores, we have to do a
read-modify-write
Hello,
On 17/06/2014 19:41, Joseph S. Myers wrote:
On Tue, 17 Jun 2014, Sylvestre Ledru wrote:
OK. I will do that.
We should test the following:
* default = run just -Wreturn-type
* -Wreturn-type = Run both
* -Wreturn-type + -Wmissing-return = Run both
* -Wno-return-type +
On 07/06/14 08:23, Marc Glisse wrote:
What is the lifetime of an SSA_NAME with a default definition? The way
we handle it now, we start from the uses and go back to all blocks that
can reach one of the uses, since there is no defining statement where we
could stop
Right, that's exactly what I
On 07/03/14 04:18, Marek Polacek wrote:
On Mon, Jun 30, 2014 at 03:40:18PM -0700, Mike Stump wrote:
I glanced at it:
(gdb) p/x TYPE_ALIGN (type)
$1 = 2147483648
(gdb) p/x TYPE_ALIGN (type)
$2 = 0x8000
The callee is int, the caller uses unsigned int. The assert I see is because
the
On 07/04/14 03:05, Jan Hubicka wrote:
Hi,
BLOCK_SUPERCONTEXT for normal blocks leads all the way to FUNCTOIN_DECL. This
is not the case of some
automatically generated functions, like one for cilk. I think it is bug. This
patch fixes cilk, I will
look for other cases if that looks OK.
Sri, can you provide examples to show why putting thunks into the same
section as the target function when function reorder is on can be bad
?
Thanks,
David
On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam tmsri...@google.com wrote:
Hi Honza,
Could you review this patch when you find
Hi,
in this bug submitter noticed that talking only about explicit
constructors without mentioning conversion operators is misleading in
C++11. Thus Jon suggested simply not mentioning the constructors in the
error message, which I find reasonable because after all it's about the
fact that
Finally had some time to pick this up again. See responses and
questions below. But it looks like you are commenting on a stale
version of the patch. See the update I sent in March:
https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01176.html
On Sun, May 25, 2014 at 10:43 PM, Jan Hubicka
On July 7, 2014 11:32:10 AM CEST, Marc Glisse marc.gli...@inria.fr wrote:
On Mon, 7 Jul 2014, Richard Biener wrote:
On Mon, Jun 30, 2014 at 1:38 AM, Marc Glisse marc.gli...@inria.fr
wrote:
Hello,
with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally
Hello,
I apologize for taking so long to get into this patch. I ad busy time (wedding
and teaching), should be back in regular schedule now.
Sri, can you provide examples to show why putting thunks into the same
section as the target function when function reorder is on can be bad
?
C++ ABI
On Mon, Jul 07, 2014 at 11:46:27AM +0200, Richard Biener wrote:
On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
richard.guent...@gmail.com wrote:
On Thu, Jul 3, 2014 at 1:08 AM, tsaund...@mozilla.com wrote:
From: Trevor Saunders tsaund...@mozilla.com
Hi,
So apparently its not
1 - 100 of 118 matches
Mail list logo
