On Fri, 30 Jan 2015, Mikhail Maltsev wrote:
On Fri, 30 Jan 2015 00:15:02 +
Joseph Myers jos...@codesourcery.com wrote:
+#if 0
+ /* Check needs to be implemented. */
+ fuic (-1. + 0.i);
+ vuic = -1. + 0.i;
+#endif
The #if 0 cases should have a bug filed in Bugzilla
On Fri, Jan 30, 2015 at 08:27:06AM -0800, Mike Stump wrote:
+static bool
+c_parse_pragma_ivdep (c_parser *parser)
+{
+ c_parser_consume_pragma (parser);
+ c_parser_skip_to_pragma_eol (parser);
+ return true;
+}
+
+static unsigned short
+c_parser_pragma_unroll (c_parser *parser)
On Thu, 29 Jan 2015, Mike Stump wrote:
@@ -5587,6 +5600,12 @@ c_parser_for_statement (c_parser *parser
%GCC ivdep% pragma);
cond = error_mark_node;
}
+ else if (unroll)
+ {
+ c_parser_error
Avoid possible warning on darwin during compiler build.
Should hopefully close PR 64349, committed on trunk
2015-01-30 Tristan Gingold ging...@adacore.com
PR ada/64349
* env.c: Move vxworks and darwin includes out of #ifdef IN_RTS.
Index: env.c
On Jan 30, 2015, at 7:49 AM, Joseph Myers jos...@codesourcery.com wrote:
Use error_at, and %u directly in the format.
Done.
Index: ada/gcc-interface/trans.c
===
--- ada/gcc-interface/trans.c (revision 220084)
+++
This patch fixes a rather obscure bug in case there is a user-defined +
operator returning Boolean, passed to two contexts where the expected type is
Boolean, and the expected type is the result of the PREdefined operator.
This is ambiguous, and therefore illegal.
gnatmake -q -f cutdown1-main.adb
Hi Tristan,
On 30 Jan 2015, at 15:13, Arnaud Charlet wrote:
Avoid possible warning on darwin during compiler build.
it's not just a warning it's a documented incorrect usage which causes a link
error (and thus bootstrap fail) on systems that are not using the catch-all
-Wl, -undefined,
The warning for use of Import in a Pure unit is refined so that it is
omitted if an explicit Pure_Function aspect is given, as shown by
the following test, compiled with -gnatl
1. package PureImportF is
2. pragma Pure (PureImportF);
3.function F (A : integer) return integer;
On Jan 29, 2015, at 7:16 PM, Andrew Pinski pins...@gmail.com wrote:
On Thu, Jan 29, 2015 at 6:58 PM, Mike Stump mikest...@comcast.net wrote:
On Jan 29, 2015, at 4:15 PM, Joseph Myers jos...@codesourcery.com wrote:
The patch is OK for GCC 6
We will be releasing 5.x compilers for the next
This is the followup patch. This adds more information to the package
when any imported packages have a pkgpath symbol that is not the
obvious transformation of the pkgpath. This is enough to determine
the right symbol name to use in all cases. Bootstrapped and ran Go
testsuite on
On Fri, Jan 30, 2015 at 12:52 AM, Joseph Myers jos...@codesourcery.com wrote:
Ian: this patch does *not* change go/gofrontend/go.cc; you'll need to
update that (such an update is of course best done before this patch
goes in; since the overload currently exists, updating it does not
depend on
On 01/30/2015 12:40 PM, Richard Biener wrote:
On January 30, 2015 9:18:57 PM CET, Richard Henderson r...@redhat.com wrote:
On 01/30/2015 12:12 PM, Mike Stump wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I
Hi,
This patch fixes two more cases where alias chain should be followed to emit
correct assembler name for instrumented functions. Bootstrapped and tested on
x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-01-30 Ilya Enkovich ilya.enkov...@intel.com
* varasm.c
The patch in the attachment solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
The patch was bootstrapped and tested on x86-64 and ppc64.
Committed as rev.220297.
2015-01-30 Vladimir Makarov vmaka...@redhat.com
PR target/64688
* lra-constraints.c
Similar to the issue with fatal_error that I fixed in
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02690.html, the
overloads of gfc_warning and gfc_warning_now (with and without a first
argument for an option number) also break gcc.pot regeneration because
xgettext expects the translated string
On 01/30/2015 09:47 AM, Jakub Jelinek wrote:
+hash_maptree, tree *deep_ter_debug_map;
Any reason this data can't be static?
Otherwise, ok.
r~
On 01/30/2015 04:52 AM, Szabolcs Nagy wrote:
When running natively on AArch64 the preprocessor did not use the
AdvSIMD optimized search_line_fast function, because it was ifdefed
around by __ARM_NEON__ instead of __ARM_NEON.
Yes, sorry I didn't follow up on that from September:
On 01/30/15 03:24, Jakub Jelinek wrote:
On Fri, Jan 30, 2015 at 11:23:38AM +0100, Uros Bizjak wrote:
On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek ja...@redhat.com wrote:
/* Each function should compile down to a byte move from
the input register into x, possibly at an offset within
On Fri, 30 Jan 2015, David Malcolm wrote:
gcc/ChangeLog:
PR jit/64810
* Makefile.in (GCC_OBJS): Add gcc-main.o.
* gcc-main.c: New file, containing main taken from gcc.c.
* gcc.c (do_self_spec): Free decoded_options.
(class driver): Move declaration to gcc.h.
On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
/* It is possible to have both DECL_ABSTRACT_P and DECLARATION be true if we
started to generate the abstract instance of an inline, decided to output
its containing class, and proceeded to emit the declaration of the inline
from the
On 30 January 2015 at 23:06, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
Let's drop libstdc++, this discussion is about a test that doesn't
really concern them.
On 30 January 2015 at 22:51, Jason Merrill ja...@redhat.com wrote:
The patch changes all the static_assert strings to ,
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest
braces around empty body in an 'if' statement [-Wempty-body]
On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote:
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning:
suggest
On January 30, 2015 5:36:16 PM GMT+01:00, Marek Polacek pola...@redhat.com
wrote:
On Fri, Jan 30, 2015 at 08:27:06AM -0800, Mike Stump wrote:
+static bool
+c_parse_pragma_ivdep (c_parser *parser)
+{
+ c_parser_consume_pragma (parser);
+ c_parser_skip_to_pragma_eol (parser);
+ return
On Jan 30, 2015, at 12:36 PM, Richard Biener richard.guent...@gmail.com wrote:
Ah, I kinda discounted that as it went by it seems. It seems most
other players go the other way, as the numbers get large, the first one
fixes, and then they add numbers at the bottom. Thanks.
You obviously
Let's drop libstdc++, this discussion is about a test that doesn't
really concern them.
On 30 January 2015 at 22:51, Jason Merrill ja...@redhat.com wrote:
The patch changes all the static_assert strings to , which is not very
useful; let's keep the macro.
Ok. How about this one? It reuses the
On January 30, 2015 9:18:57 PM CET, Richard Henderson r...@redhat.com wrote:
On 01/30/2015 12:12 PM, Mike Stump wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18
On Jan 30, 2015, at 12:52 PM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
This last test is still puzzling me.
As it is to me. The reason it seems like they were going for in the code was
due to wrapping, but wrapping should only happen at something relating to the
bit size of the
On 01/30/2015 03:05 PM, Ville Voutilainen wrote:
-#define TRY(expr) static_assert (expr, #expr)
The patch changes all the static_assert strings to , which is not very
useful; let's keep the macro.
Jason
Hi!
As the following two testcases show, while we have avoid_complex_debug_insns
that decreases debug insn complexity after expansion is done, there is a
problem during expansion if the TER chains are too deep, because
simplify-rtx.c in some cases is inherently quadratic - does not like
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128 [0x80])
(const_int 6 [0x6])
] UNSPECV_SPECIAL_OP)
(set (mem/v:BLK (scratch:DI) [0 A8])
(unspec:BLK [
On 30 January 2015 at 21:59, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
So, a new patch attached. The only change to the previous one is the change
to the trivial1.C test.
Oops. The No-template was borken and there was remnants of the macros
in commented
code. Let's try that again,
On 01/28/2015 10:51 AM, Jason Merrill wrote:
On 01/28/2015 01:29 PM, Aldy Hernandez wrote:
+ /* It is rather unfortunate that Cilk creates trees this late +
(during gimplification). However, until this gets fixed, +
specially handle emitting DWARF for this new function and +
immediately clean
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617
The patch was bootstrapped and tested on x86-64 and ppc64.
Committed as rev.220294.
2015-01-30 Vladimir Makarov vmaka...@redhat.com
PR target/64617
* lra-constraints.c
On 30 January 2015 at 19:46, Jason Merrill ja...@redhat.com wrote:
On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
+#define YES2(type) TRY(std::is_trivialtype::value); \
+ TRY(std::is_trivialtype[]::value); \
TRY(std::is_trivialconst volatile type::value)
+YES2(void *);
+YES2(int
On 01/30/2015 12:12 PM, Mike Stump wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128
On January 30, 2015 9:12:12 PM CET, Mike Stump mikest...@comcast.net wrote:
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128 [0x80])
(const_int 6 [0x6])
] UNSPECV_SPECIAL_OP)
(set
Hello!
Attached patch adds nonpic target requirement for some (obvious)
cases, where data access or PIC register setup confuses scan-asms.
2015-01-30 Uros Bizjak ubiz...@gmail.com
* gcc.target/i386/fuse-caller-save-rec.c: Require nonpic target.
*
On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
+#define YES2(type) TRY(std::is_trivialtype::value); \
+ TRY(std::is_trivialtype[]::value); \
TRY(std::is_trivialconst volatile type::value)
+YES2(void *);
+YES2(int A::*);
Why would void *const volatile still be trivial?
Jason
On 30 January 2015 at 20:25, Jason Merrill ja...@redhat.com wrote:
On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
Why would void *const volatile still be trivial?
Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
is_trivialconst volatile void*::value, which is true,
On Jan 30, 2015, at 9:52 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Jan 30, 2015 at 09:45:26AM -0800, Mike Stump wrote:
I have a port that has:
(insn 47 46 48 18 (parallel [
(unspec_volatile:DI [
(const_int 128 [0x80])
(const_int 6
We haven't been using this for a looong time. It never even gets defined.
Removed and committed to branch.
Aldy
commit a8076b015cad17538e369c153f8c7cf888433840
Author: Aldy Hernandez al...@redhat.com
Date: Tue Jan 27 11:24:53 2015 -0800
* dwarf2out.c (file_table_last_lookup): Remove
On 01/30/2015 11:01 AM, Aldy Hernandez wrote:
We haven't been using this for a looong time. It never even gets defined.
Removed and committed to branch.
Aldy
Ughh, I'm having git rebase issues. I was missing part of the patch.
Here's the rest.
Committed to branch.
Aldy
diff --git
On January 30, 2015 5:33:43 PM CET, Mike Stump mikest...@comcast.net wrote:
On Jan 29, 2015, at 7:16 PM, Andrew Pinski pins...@gmail.com wrote:
On Thu, Jan 29, 2015 at 6:58 PM, Mike Stump mikest...@comcast.net
wrote:
On Jan 29, 2015, at 4:15 PM, Joseph Myers jos...@codesourcery.com
wrote:
The
OK.
Jason
On 01/29/15 05:38, Rainer Orth wrote:
So I saw. If all else fails, we can still commit the (ugly/hard to
read) initial version, otherwise libgo won't build on Solaris before
some (quite recent) Solaris 11.2 patch, breaking bootstrap.
Having it work at all seems like a nice feature.
I think
On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
Why would void *const volatile still be trivial?
Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
is_trivialconst volatile void*::value, which is true, whereas
is_trivialvoid* const volatile::value is false.
I think it
Hello,
Recently on gcc-help@ one of the users asked whether they need to set
-fvar-tracking-assignments on the command line by hand. The documentation may
be clearer in that this flag has a useful value by default, like -fvar-tracking
(i.e. GCC's behavior is to take the value of
On 01/30/15 01:19, Jakub Jelinek wrote:
The biggest problem is that what fails and what does not varries between
targets and between optimization levels. Right now we have no way to xfail
test XYZ for -Os on x86_64-linux and for -O2 and -O3 on i686-linux ia32, and
the lists would become very
On 01/30/15 03:07, Uros Bizjak wrote:
On Fri, Jan 30, 2015 at 7:12 AM, Jeff Law l...@redhat.com wrote:
Hello!
So here's the updated patch which handles all 4 testcases from the PR as
well as a couple of my own.
@@ -0,0 +1,33 @@
+/* PR 15184 first two tests, plus two addition ones. */
+/*
On Fri, Jan 30, 2015 at 08:33:43AM -0800, Mike Stump wrote:
Ah, I kinda discounted that as it went by it seems. It seems most other
players go the other way, as the numbers get large, the first one fixes, and
then they add numbers at the bottom. Thanks.
The GCC release series is now a
On Fri, Jan 30, 2015 at 12:50:01PM -0800, Richard Henderson wrote:
Jakub, the current formation includes both a use and a set of all
memory. Your
clobber form would not imply a use.
What do you need the use for? Prevent all DSE before the barrier for some
weird reason?
I don't
From: Trevor Saunders tbsaunde+...@tbsaunde.org
Hi,
tree-emutls wasn't resolvingthe aliases it created which meant that the
varpool node's ref_list said it didn't refer to anything which caused
get_alias_target to crash. Then varpool_node::remove called
varpool_node::ctor_useful_for_folding_p
On 01/30/2015 02:04 PM, Jason Merrill wrote:
On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
/* It is possible to have both DECL_ABSTRACT_P and DECLARATION be
true if we
started to generate the abstract instance of an inline, decided
to output
its containing class, and proceeded to
This patch by Chris Manghane fixes a bug in the gofrontend in which
map index expressions were not treated as lvalues in range
expressions. That is,
for m[0] = range s
did not work. This was Go issue 9695. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
../../../../gcc-tile-new/libgcc/libgcov-interface.c:182:53: warning: suggest
braces around empty body in an 'if' statement [-Wempty-body]
On 1/31/15 06:57, Jakub Jelinek wrote:
On Sat, Jan 31, 2015 at 06:37:30AM +0800, Chen Gang S wrote:
The related warning (cross compile tile with --disable-threads):
../../../../gcc-tile-new/libgcc/libgcov-interface.c: In function
'__gcov_fork':
So I've gone round and round with BZ39726.
The basic idea here is we have an operation on widened operands that
feeds a narrow comparison. ie, the two inputs are QImode, extended to
SImode, subtracted, then we want to conditionally branch on the result
of sign bit of QImode.
If we could
On 01/22/15 12:01, Maxim Kuvyrkov wrote:
On Jan 22, 2015, at 8:11 PM, Jeff Law l...@redhat.com wrote:
On 01/19/15 06:07, Maxim Kuvyrkov wrote:
The underlying problem is that the order in which elements of
ready_list are compared matters to the final result. This is
because rank_for_schedule
Joseph Myers wrote:
Similar to the issue with fatal_error that I fixed in
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02690.html, the
overloads of gfc_warning and gfc_warning_now (with and without a first
argument for an option number) also break gcc.pot regeneration because
xgettext expects
On 30 January 2015 at 12:09, Alan Lawrence alan.lawre...@arm.com wrote:
This was posted towards the end of stage 3, a few days before stage 4
started. Is it now too late to ping ?
--Alan
gcc/ChangeLog:
* config/aarch64/arm_neon.h (vst1_lane_f32, vst1_lane_f64,
When the Access attribute is applied within a generic body to a prefix
that denotes a subprogram declared in an enclosing generic unit, the
compiler rejects this as a violation of the rule in the last sentence
of RM 3.10.2(32/3). This is happening because the compiler is requiring
both the access
The warning message for an always True condition special cased the
simple variable case. This special casing is now extended for the
False case as well:
1. package CCF_Warn is
2.procedure Mess;
3. end;
1. package body CCF_Warn is
2. type T is array (1..10) of
This patch improves the text of the error reported for RM 9.4(11.9).
This new output is visible using this small reproducer:
procedure by30018 is
package pack is
type Iface is synchronized interface;
procedure Prim1_1 (M : in Iface) is abstract;
protected type T_PO is new
On 30/01/15 09:20, Richard Biener wrote:
On Thu, 29 Jan 2015, Jiong Wang wrote:
2015-01-29 14:27 GMT+00:00 Kyrill Tkachov kyrylo.tkac...@arm.com:
On 29/01/15 12:44, Richard Biener wrote:
Can you test?
two issues during bootstrapping the patch on arm board on top of r220249
* one
On Thu, Jan 29, 2015 at 11:11:12PM -0700, Jeff Law wrote:
Linux/x86_64Solaris 11/x86 Solaris
11/SPARC
(Fedora 20)
gcc.dg/guality:
# of expected passes6490 65005489
# of unexpected
On Fri, Jan 30, 2015 at 11:07:45AM +0100, Uros Bizjak wrote:
--- gcc.target/i386/pr15184-1.c (revision 220273)
+++ gcc.target/i386/pr15184-1.c (working copy)
@@ -1,11 +1,10 @@
/* PR 15184 first two tests, plus two addition ones. */
-/* { dg-do compile } */
-/* { dg-options -O2
Hello,
While looking at PR preprocessor/64803, I noticed that builtin_macro
was changing the location a token after it was been handed out by
_cpp_lex_direct(). Use the combination of cpp_force_token_locations()
and cpp_stop_forcing_token_locations() that are intended for exactly
that use case.
On Fri, Jan 30, 2015 at 10:12:35AM +0100, Richard Biener wrote:
Ok - without digging into why the above would fail with your patch
(don't see that - the use in the function call can't be opdd) - let's
take a step back and decide whether we want to allow user-created
function descriptors. And
Dodji Seketeli do...@redhat.com writes:
+ /* force the location of the token emitted by _cpp_lex_direct() to
s/force/Force/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
On Thu, 29 Jan 2015, Jiong Wang wrote:
2015-01-29 14:27 GMT+00:00 Kyrill Tkachov kyrylo.tkac...@arm.com:
On 29/01/15 12:44, Richard Biener wrote:
Can you test?
two issues during bootstrapping the patch on arm board on top of r220249
* one warning treated as error.
On Fri, Jan 30, 2015 at 11:23:38AM +0100, Uros Bizjak wrote:
On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek ja...@redhat.com wrote:
/* Each function should compile down to a byte move from
the input register into x, possibly at an offset within x. */
-/* { dg-final {
On Fri, Jan 30, 2015 at 6:12 AM, Alan Modra amo...@gmail.com wrote:
On Fri, Jan 30, 2015 at 01:19:51PM +1030, Alan Modra wrote:
On Thu, Jan 29, 2015 at 04:21:15PM +0100, Richard Biener wrote:
This means that you still will be able to create a testcase that is
miscompiled with exposing the
[This is a P1 regression for gcc 5]
Hello,
Consider the example code mentionned in this PR:
$ cat -n test.c
1 #define C(a, b) a ## b
2 #define L(x) C(L, x)
3 #define M(a) goto L(__LINE__); __LINE__; L(__LINE__):
4 M(a /* -- this is the line of the expansion point of M.
Hi Jeff,
The tests gcc.target/i386/pr15184-[12].c fail on darwin. Grepping for movb, I
get
movb%al, (%edx)
movb%al, 1(%edx)
movb%al, 2(%edx)
movb%al, 3(%edx)
TIA
Dominique
On Fri, Jan 30, 2015 at 7:12 AM, Jeff Law l...@redhat.com wrote:
Hello!
So here's the updated patch which handles all 4 testcases from the PR as
well as a couple of my own.
@@ -0,0 +1,33 @@
+/* PR 15184 first two tests, plus two addition ones. */
+/* { dg-do compile } */
+/* {
On Fri, Jan 30, 2015 at 11:13 AM, Jakub Jelinek ja...@redhat.com wrote:
/* Each function should compile down to a byte move from
the input register into x, possibly at an offset within x. */
-/* { dg-final { scan-assembler-times \tmovb\t%al, x 4 } } */
+/* { dg-final {
The patch https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00698.html
adding an overload for fatal_error that passes an explicit location
broke gcc.pot regeneration because xgettext cannot handle function
overloads with the diagnostic string argument in different positions.
As the desired direction
On Fri, Jan 30, 2015 at 08:52:03AM +, Joseph Myers wrote:
Bootstrapped with no regressions for x86_64-unknown-linux-gnu (Go
excluded, as noted above). OK to commit (once Go has been fixed)?
Ok, thanks.
Jakub
This patch reimplements a key aspect of heap-allocated controlled objects.
Primitive Finalize_Address is now associated with the finalization master of
an access-to-controlled type when the designated type is frozen and not at the
point of object allocation.
-- Source --
This was posted towards the end of stage 3, a few days before stage 4
started. Is it now too late to ping ?
--Alan
Alan Lawrence wrote:
Nowadays, just storing the (bigendian-corrected) vector element to the address,
generates exactly the same assembler for all cases except
Hi.
Attached patch handles situation where remove_unreachable_nodes is called before
IPA ICF registers removal hooks. As a result, a deleted callgraph node is
touched.
Tested on x86_64-linux-pc without a new regression seen.
Ready for trunk?
Thanks,
Martin
From
Jakub Jelinek ja...@redhat.com writes:
On Thu, Jan 29, 2015 at 11:11:12PM -0700, Jeff Law wrote:
Linux/x86_64 Solaris 11/x86 Solaris
11/SPARC
(Fedora 20)
gcc.dg/guality:
# of expected passes6490
On Fri, Jan 23, 2015 at 11:03:13AM +, Tejas Belagod wrote:
Hi,
This is an almost obvious patch to fix PR64231 as discovered by A. Pinksi
and as proposed by Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64231
Regressions happy. OK to commit?
This is ok for trunk. We have a
On 30/01/15 12:52, Szabolcs Nagy wrote:
Hello,
When running natively on AArch64 the preprocessor did not use the
AdvSIMD optimized search_line_fast function, because it was ifdefed
around by __ARM_NEON__ instead of __ARM_NEON.
(The ARM C Language Extensions specifies the __ARM_NEON macro,
From: Trevor Saunders tbsaunde+...@tbsaunde.org
Hi,
given the glibc man page claims this is in POSIX.1-2001 and SUv1, and none of
the people testing on normally odd systems other than mingw have complained it
doesn't seem terribly likely there's many other hosts where this is an issue,
so I just
Hello,
When running natively on AArch64 the preprocessor did not use the
AdvSIMD optimized search_line_fast function, because it was ifdefed
around by __ARM_NEON__ instead of __ARM_NEON.
(The ARM C Language Extensions specifies the __ARM_NEON macro, but not
__ARM_NEON__ which is legacy and thus
On 01/27/2015 01:31 PM, Martin Liška wrote:
On 01/27/2015 05:23 AM, DJ Delorie wrote:
+/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */
+
+# if GCC_VERSION = 4004
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored -Wstrict-overflow
+#endif
+
#pragma
Currently the jit completely fails to work on arm.
The root cause is that the jit is ignoring configure-time
default options.
For example, on configuring arm with e.g.:
--with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16
these options are written into configargs.h as
jit_langhook_type_for_mode was failing for DImode on arm
(see via a segfault in test-expressions.c.exe in the jit testsuite).
A fix is to add handling for:
mode == TYPE_MODE (long_long_integer_type_node)
to the existing checks.
gcc/jit/ChangeLog:
PR jit/64810
* dummy-frontend.c
Hi all,
I fear this fix is not so obvious in one location, I therefore ask for a
review. The attached patch fixes:
- a duplicate code fragment (possibly due to merged twice),
- the indentation in the trans-expr.c block (in my first patch), and
- a typo on the datatype-size to create for the
Andreas Schwab sch...@linux-m68k.org writes:
+ /* force the location of the token emitted by _cpp_lex_direct() to
s/force/Force/
Thanks for noticing this, Andreas!
I have updated my local copy of the patch to fix that.
Cheers!
--
Dodji
libgccjit can make repeated in-process calls to the compiler code.
On arm I see failures where e.g. the top of the generated .s file has:
on the 1st iteration:
.arch armv7-a
on the 2nd iteration:
.cpu armv7-a
without changing any options.
What's happening is the 1st time through
On 30/01/15 11:11, David Malcolm wrote:
libgccjit can make repeated in-process calls to the compiler code.
On arm I see failures where e.g. the top of the generated .s file has:
on the 1st iteration:
.arch armv7-a
on the 2nd iteration:
.cpu armv7-a
without changing any options.
On Fri, Jan 30, 2015 at 12:46:43PM +0100, Martin Liška wrote:
There's a small patch that updates the version.
Ready for trunk?
2015-01-30 Martin Liska mli...@suse.cz
* tree.h: Guard GCC version for a pragma ifdef.
* tree.h: Change GCC_VERSION = 4004 to GCC_VERSION = 4006
On Wed, 14 Jan 2015, Matthew Fortune wrote:
Yeah, but that's just the way it goes. By trying to get everyone to
test with the options that matter to you, you're reducing the amount of
work you have to do when tracking regressions on those targets, but
you're saying that people who care
97 matches
Mail list logo
