Sorry, first contribution ever :) Here is the entry:
2014-10-19 Bruno Loff bruno.l...@gmail.com
* c-parser.c (c_parser_declspecs): Call invoke_plugin_callbacks after
processing enum declaration.
The dates are off because I actually made the change a while ago (took
me a while because I needed
Hi,
after the missed bug at Linux with no VTV I checked everything again on
the trunk. I saw that I erroneously wrote in the changelog for
libvtv/aclocal.m4 regenerate and deleted the change from the patch. The
only change I made there in my working directory was the following.
Index:
On Mon, Feb 02, 2015 at 03:41:50PM +0100, Dodji Seketeli wrote:
libcpp/ChangeLog:
* internal.h (cpp_reader::top_most_macro_node): New data member.
* macro.c (enter_macro_context): Pass the location of the end of
the top-most invocation of the function-like macro, or the
That's
On Mon, Feb 2, 2015 at 2:39 PM, Bruno Loff bruno.l...@gmail.com wrote:
Sorry, first contribution ever :) Here is the entry:
2014-10-19 Bruno Loff bruno.l...@gmail.com
* c-parser.c (c_parser_declspecs): Call invoke_plugin_callbacks after
processing enum declaration.
This is fine.
On Mon, Feb 2, 2015 at 2:39 PM, Bruno Loff bruno.l...@gmail.com wrote:
2014-10-19 Bruno Loff bruno.l...@gmail.com
* c-parser.c (c_parser_declspecs): Call invoke_plugin_callbacks after
processing enum declaration.
Thanks. Committed at r220358.
Diego.
Jakub Jelinek ja...@redhat.com writes:
On Mon, Feb 02, 2015 at 03:41:50PM +0100, Dodji Seketeli wrote:
libcpp/ChangeLog:
* internal.h (cpp_reader::top_most_macro_node): New data member.
* macro.c (enter_macro_context): Pass the location of the end of
the top-most invocation
This patch fixes a long standing bug where aligned_operand ignores
alignment of memory operand less than 32 bits. It drops address
decomposition and returns false if alignment of memory operand less
is than 32 bits. Tested on Linux/x86-64. OK for trunk, 4.9 and 4.8
branches?
H.J.
---
gcc/
Hi,
while looking into Firefox's regressions WRT 4.9 LTO builds, I noticed
that some of very small functions are not early inlined. This is because
firefox sometimes uses always_inline and we skip early inlining int those.
Once the always_inline is inlined we however do not inline recursively
On 2 February 2015 at 20:50, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
The modified test has been tested, I'm currently running the full testsuite,
so testing is incomplete. I wanted to send this in asap, since this is a
bad regression.
/cp
2015-02-02 Ville Voutilainen
On Feb 2, 2015, at 3:22 PM, Bernhard Reutner-Fischer rep.dot@gmail.com
wrote:
Untested draft patch
I looked it over, seems to slot in nicely.
+ gfc_error (%GCC unroll% directive does not commence a loop at %C”);
So, don’t like commence here.
On Mon, Feb 02, 2015 at 11:22:58PM +0100, Dodji Seketeli wrote:
Thanks. The patch that finally passed bootstrap is the one below. It's
slightly different in the condition I use to detect that we are popping
the context of the top-most macro expansion stored in
pfile-top_most_macro_node in
Hi,
Some compilers IIRC use !DIR$ unroll, if memory serves me right then
the DEC compiler had !DEC$ unroll.
We could support one or the other three-letter keyword or maybe not.
I think a combination of unroll and ivdep directives is allowed (at
least in some compilers); TODO.
Not sure what
On Mon, Feb 02, 2015 at 07:54:46PM +0100, Jakub Jelinek wrote:
+/* Highest pseudo for which we track REG_N_SETS. */
+static unsigned int reg_n_sets_max;
One more than the highest reg num, actually.
Looks fine otherwise :-)
Segher
On 02/02/2015 06:43 PM, Jason Merrill wrote:
One of the EDG guys pointed out to me that we weren't doing any sanity
checking
on the arguments to the abi_tag attribute. This patch adds checks to require
that the arguments be strings containing valid identifiers, so they work
appropriately in
While trying to build the GCC 5 with GCC 5, I ran into an ICE when
building libcpp at -O0. The problem is the C++ front-end was not
folding sizeof(a)/sizeof(a[0]) when passed to a function at -O0. The
C++ front-end keeps around sizeof until the gimplifier and there is no
way to fold the
fortran/ChangeLog:
2015-02-02 Bernhard Reutner-Fischer al...@gcc.gnu.org
* match.h (gfc_match_gcc_unroll): New prototype.
* decl.c (directive_unroll): New global variable.
(gfc_match_gcc_unroll): New function.
* gfortran.h (directive_unroll): New extern
Jeff Law l...@redhat.com writes:
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
On 28 Jan 19:20, Ilya Verbin wrote:
On 28 Jan 17:15, Jakub Jelinek wrote:
On Wed, Jan 28, 2015 at 07:02:59PM +0300, Ilya Verbin wrote:
+ = XNEWVEC (char, len + sizeof (-B ../ DEFAULT_TARGET_MACHINE
+/libgomp/));
+ sprintf (optional_target_path2,
On 2 February 2015 at 02:37, Michael Hanselmann wrote:
Calls to `std::uncaught_exception` after calling
`std::rethrow_exception' always return `true' when
`std::uncaught_exception' should return `false' unless an exception is
in flight. `std::rethrow_exception' does not update
On 23/01/15 13:20 -0800, Tim Shen wrote:
On Wed, Jan 21, 2015 at 9:10 PM, Tim Shen tims...@google.com wrote:
Submitted version.
I think this patch fits 4.9 branch well?
I don't think this needs to go on the 4.9 branch, apparently I'm the
only person who's noticed the problem. I expect it's
On 01/02/15 00:18 -0800, Tim Shen wrote:
On Wed, Jan 21, 2015 at 9:08 PM, Tim Shen tims...@google.com wrote:
Fixed and committed.
I believe this one is also suitable for 4.9?
I guess we don't have a 'code freeze' for 4.9 branch as we do for 5.0
late stage?
Release branches are always in
On Fri, Jan 30, 2015 at 10:19:26AM +0100, Dodji Seketeli wrote:
[This is a P1 regression for gcc 5]
libcpp/ChangeLog:
* internal.h (cpp_reader::top_most_macro_node): New data member.
* macro.c (enter_macro_context): Pass the location of the end of
the top-most invocation
On Sun, Jan 11, 2015 at 11:06:52PM +0300, Ilya Verbin wrote:
On 09 Jan 16:02, Jakub Jelinek wrote:
On Fri, Jan 09, 2015 at 05:57:02PM +0300, Ilya Verbin wrote:
If one (by mistake) calls a non-target function from the target region,
the
offload compiler crashes in input_overwrite_node.
On Mon, Jan 12, 2015 at 12:22:44AM +0300, Ilya Verbin wrote:
Currently if a target* pragma appears within a target region, GCC successfully
compiles such code (with a warning). But the binary fails at run-time, since
it
tries to call GOMP_target* functions on target.
The spec says: If a
On Fri, Jan 30, 2015 at 10:33:06AM +0100, Jakub Jelinek wrote:
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
Hi Jerry,
thanks for the review. Committed as r220345.
Regards,
Andre
On Sat, 31 Jan 2015 07:41:24 -0800
Jerry DeLisle jvdeli...@charter.net wrote:
On 01/30/2015 04:10 AM, Andre Vehreschild wrote:
Hi all,
I fear this fix is not so obvious in one location, I therefore ask for a
On 26 January 2015 at 14:23, Christophe Lyon christophe.l...@linaro.org wrote:
On 26 January 2015 at 13:10, Tejas Belagod tejas.bela...@arm.com wrote:
On 25/01/15 21:05, Christophe Lyon wrote:
On 23 January 2015 at 14:44, Christophe Lyon christophe.l...@linaro.org
wrote:
On 23 January 2015
On Tue, Jul 29, 2014 at 06:45:01PM +0400, Ilya Tocar wrote:
Hi,
As discussed here in https://gcc.gnu.org/ml/gcc/2014-01/msg00189.html
Gcc should complain about pragma omp declare target without
corresponding pragma omp end declare target. This patch adds a warning
for those cases.
Hi,
inliner uses crossmodule hint that during LTO preffers in-module inlining
over cross-module. This hint is wrong for comdats that gets merged and
thus the module information is more or less random.
The patch fixes it by adding merged flag to cgraph_node indicating merged
comdats and always
At Sun, 1 Feb 2015 00:39:08 +,
Joseph Myers wrote:
On Sat, 31 Jan 2015, Yoshinori Sato wrote:
+ * config/h8300/linux.h: New file.
+ * config/h8300/t-linux: New file.
These files don't appear to be included in the patch.
I'll resend it.
+h8300-*-linux*)
+
In the backend interface for the Go frontend, I foolishly used size_t
for the size of a type. That usually works, but fails when compiling
on a 32-bit host for a 64-bit target and compiling code that uses very
large types. The maximum type size for any Go target is a signed
64-bit number, so for
Jakub Jelinek ja...@redhat.com writes:
On Fri, Jan 30, 2015 at 10:19:26AM +0100, Dodji Seketeli wrote:
[This is a P1 regression for gcc 5]
libcpp/ChangeLog:
* internal.h (cpp_reader::top_most_macro_node): New data member.
* macro.c (enter_macro_context): Pass the location of the
Hi!
On Tue, 23 Dec 2014 19:49:35 +0100, I wrote:
On Mon, 10 Nov 2014 17:19:57 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
The scripts (11/11) I've put up on github, along with a hacked up
newlib. These are at [...]
They are likely to migrate to MentorEmbedded from bernds, but
2015-01-25 Christophe Lyon christophe.l...@linaro.org
* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
(_ARM_FPSRC): Add DN and AHP fields.
(clean_results): Force DN=1 on AArch64.
* gcc.target/aarch64/advsimd-intrinsics/binary_op_no64.inc: New file.
*
Rainer Orth wrote:
I'm still not really comfortable with those target lists; they tend to
artificially exclude tests on targets where they are perfectly capable
of running. At least with the comments added, it's better than before
with no explanation whatsoever. Perhaps Mike can weigh in
I have queued the following patch for stage1 which improves the
ability to utilize the match-and-simplify combiner during SSA
propagation (by CCP and VRP). It makes sure to mark stmts
as not-simulate-again when possible so that the valueization hooks
know when it is safe to combine multiple
On 30/01/15 19:14, Richard Henderson wrote:
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
Hello,
With target arm-none-eabi, the libstdc++ tests
28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc fail at
--
VERIFY(!t.isctype('\n', t.lookup_classname(range(blank;
--
This is because libstdc++ puts '\n' in the 'space' character class,
rather than 'blank' when
On 02/02/15 15:34, Szabolcs Nagy wrote:
On 30/01/15 19:14, Richard Henderson wrote:
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__
Hi Alan,
I'm still not really comfortable with those target lists; they tend to
artificially exclude tests on targets where they are perfectly capable
of running. At least with the comments added, it's better than before
with no explanation whatsoever. Perhaps Mike can weigh in here?
On 02/02/15 08:59, Alex Velenko wrote:
On 11/10/14 13:44, Felix Yang wrote:
Hello Jeff,
I see that you have improved the RTL typesafety issue for ira.c,
so I rebased this patch
on the latest trunk and change to use the new list walking
interface.
Bootstrapped on
On Mon, Feb 02, 2015 at 02:51:43PM -0800, Andrew Pinski wrote:
While trying to build the GCC 5 with GCC 5, I ran into an ICE when
building libcpp at -O0. The problem is the C++ front-end was not
folding sizeof(a)/sizeof(a[0]) when passed to a function at -O0. The
C++ front-end keeps around
Please could you add a comment explaining that the mips_nanlegacy is there
because of the #include of system headers that might not compile with
-mnan=legacy? I agree that that's a good reason, but it's not obvious
without a comment. (And without a comment this could start a precendent
of
On 2 February 2015 at 16:17, Paolo Carlini paolo.carl...@oracle.com wrote:
Hi,
On 02/02/2015 04:49 PM, Matthew Wahab wrote:
Hello,
With target arm-none-eabi, the libstdc++ tests
28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc fail at
--
VERIFY(!t.isctype('\n',
On Mon, 2015-01-26 at 19:14 -0500, David Malcolm wrote:
On Mon, 2015-01-26 at 15:21 -0700, Jeff Law wrote:
On 01/26/15 09:42, David Malcolm wrote:
update_web_docs_svn-support-the-JIT-documention-v2.patch
From 7f7e15881981228e51b347f23df6e3106ddd68ea Mon Sep 17 00:00:00 2001
Dear Paul,
I have tested your patch at
https://gcc.gnu.org/ml/fortran/2015-01/txtwnaoa1115V.txt
(the latest version) and I found that the test type_to_class_3.f03 is
miscompiled
(FAIL) with -flto -O0 -m64 (this does not happens with -flto -O0 -m32 or with
-Ox and
x!=0).
In addition, while the
copyright
assignment; is that still valid?
Janis
gcc-20150202-1
Description: Binary data
On Sat, 31 Jan 2015, Jeff Law wrote:
The nice thing about wrapping the result inside a convert is the types for the
inner operations will propagate from the type of the inner operands, which is
exactly what we want. We then remove the hack assigning type and instead the
original type will be
On 30/01/15 13:25, Jakub Jelinek wrote:
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?
On 11/10/14 13:44, Felix Yang wrote:
Hello Jeff,
I see that you have improved the RTL typesafety issue for ira.c,
so I rebased this patch
on the latest trunk and change to use the new list walking interface.
Bootstrapped on x86_64-SUSE-Linux and make check regression tested.
Hi,
On 02/02/2015 04:49 PM, Matthew Wahab wrote:
Hello,
With target arm-none-eabi, the libstdc++ tests
28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc
fail at
--
VERIFY(!t.isctype('\n', t.lookup_classname(range(blank;
--
This is because libstdc++ puts '\n' in the
Hi Bernd!
On Fri, 9 Jan 2015 16:38:51 +0100, Bernd Schmidt ber...@codesourcery.com
wrote:
On 12/23/2014 07:50 PM, Thomas Schwinge wrote:
[nvptx-tools patches]
I've pushed the three patches you sent to my github repository.
It probably makes sense for you to switch over to the
On 2 February 2015 at 18:03, Matthew Wahab wrote:
Updated patch attached and changelog below.
Looks good, OK for trunk - thanks for fixing it.
I am forwarding this reply to Cary Coutant, Diego Novillo and Le-Chun
Wu, as they were listed as the plugin maintainers.
Cary, Diego, Le-Chun, please let me know if you are on it, or if I
should send it to someone else.
On 29 January 2015 at 22:32, Bruno Loff bruno.l...@gmail.com wrote:
The
On 02/02/15 01:57, Richard Biener wrote:
The nice thing about wrapping the result inside a convert is the types for
the inner operations will propagate from the type of the inner operands,
which is exactly what we want. We then remove the hack assigning type and
instead the original type will
I am forwarding this reply to Cary Coutant, Diego Novillo and Le-Chun
Wu, as they were listed as the plugin maintainers.
Cary, Diego, Le-Chun, please let me know if you are on it, or if I
should send it to someone else.
Sorry, this isn't my kind of plugin -- I'm a maintainer for the LTO
Hi!
We miscompile the following testcase, because first we add
a mem/v into the hash table (which should not happen), later on
during merge_equiv_classes a new element for that mem/v is added
and doesn't even have in_memory set (because HASH failed with do_not_record
but nothing checked it) and
The modified test has been tested, I'm currently running the full testsuite,
so testing is incomplete. I wanted to send this in asap, since this is a
bad regression.
/cp
2015-02-02 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/64901
* decl.c (duplicate_decls): Also duplicate
Hi!
During combine we sometimes split instructions and on some target that can
create new pseudos.
combine_split_insns in that case grows the reg_stat vector, but REG_N_SETS
lives in an array allocated by regstat.c once and it isn't able right now to
grow it. Even adding the ability to grow
Dear Dominique,
On transferring from my laptop to my workstation, I find that it
segfaults in runtime - both are x86_64/FC21. If I can, I intend to
investigate tonight.
Thanks for the report.
Paul
On 2 February 2015 at 17:53, Dominique Dhumieres domi...@lps.ens.fr wrote:
Dear Paul,
I have
Hi David,
On Monday 2015-02-02 11:39, David Malcolm wrote:
* update_web_docs_svn: Don't delete gcc/jit/docs or
gcc/jit/jit-common.h, gcc/jit/notes.txt. Special case the
building of the jit docs (using sphinx-build). Special case
copying them up.
I've committed this to trunk as
On 02/02/15 09:59, Joseph Myers wrote:
On Sat, 31 Jan 2015, Jeff Law wrote:
The nice thing about wrapping the result inside a convert is the types for the
inner operations will propagate from the type of the inner operands, which is
exactly what we want. We then remove the hack assigning type
One of the EDG guys pointed out to me that we weren't doing any sanity
checking on the arguments to the abi_tag attribute. This patch adds
checks to require that the arguments be strings containing valid
identifiers, so they work appropriately in mangled names.
Tested x86_64-pc-linux-gnu,
On Sun, 1 Feb 2015, Bruno Loff wrote:
Do I need to do anything else to get this patch into gcc?
I suggest CC:ing the plugin maintainers (as listed in the MAINTAINERS
file), and then pinging weekly for as long as needed.
--
Joseph S. Myers
jos...@codesourcery.com
On 02/02/15 09:54, Janis Johnson wrote:
I retired from Mentor Graphics 3 weeks ago and have no immediate plans
to be active in GCC, so I'm resigning as a testsuite maintainer. I'm
leaving myself under Write After Approval with my personal email address
so people can find me.
Sounds good.
On Thu, Jan 29, 2015 at 4:32 PM, Bruno Loff bruno.l...@gmail.com wrote:
The issue was first reported by Joachim Wieland to the list
g...@gcc.gnu.org, on Wed,
Jan 19, 2011 (Subject: PLUGIN_FINISH_TYPE not executed for enums).
A description of the problem/bug and how my patch addresses it.
Something like:
The PLUGIN_FINISH_TYPE callback for gcc plugins is now triggered for
enum declarations.
?
On 2 February 2015 at 20:03, Diego Novillo dnovi...@google.com wrote:
On Thu, Jan 29, 2015 at 4:32 PM, Bruno Loff bruno.l...@gmail.com wrote:
The issue was first reported by Joachim
On Mon, Feb 2, 2015 at 2:07 PM, Bruno Loff bruno.l...@gmail.com wrote:
Something like:
The PLUGIN_FINISH_TYPE callback for gcc plugins is now triggered for
enum declarations.
?
ChangeLog entries in GCC are pretty pick as to how they want to be
formatted. See other entries for reference and
On Mon, Feb 2, 2015 at 3:22 AM, Jonathan Wakely jwak...@redhat.com wrote:
I don't think this needs to go on the 4.9 branch, apparently I'm the
only person who's noticed the problem. I expect it's quite rare to try
using those functions with forward iterators.
Sorry, I was not talking about the
On 02/02/15 11:18 -0800, Tim Shen wrote:
On Mon, Feb 2, 2015 at 3:22 AM, Jonathan Wakely jwak...@redhat.com wrote:
I don't think this needs to go on the 4.9 branch, apparently I'm the
only person who's noticed the problem. I expect it's quite rare to try
using those functions with forward
On 27 Jan 12:29, Richard Biener wrote:
On Tue, Jan 27, 2015 at 11:47 AM, Ilya Enkovich enkovich@gmail.com
wrote:
On 27 Jan 12:40, Ilya Enkovich wrote:
Hi,
This patch was supposed to fix PR tree-optimization/64277. Tracker is now
fixed by warnings disabling but I think patch is
On Monday 2015-01-26 11:03, Yury Gribov wrote:
Second version of patch with updates from Gerald Pfeifer.
Ok to commit?
Yes, this looks good.
Thank you,
Gerald
On Mon, Feb 2, 2015 at 9:19 AM, Ilya Enkovich enkovich@gmail.com wrote:
On 27 Jan 12:29, Richard Biener wrote:
On Tue, Jan 27, 2015 at 11:47 AM, Ilya Enkovich enkovich@gmail.com
wrote:
On 27 Jan 12:40, Ilya Enkovich wrote:
Hi,
This patch was supposed to fix PR
On Sun, Feb 1, 2015 at 6:46 AM, Jeff Law l...@redhat.com wrote:
On 01/31/15 17:47, Joseph Myers wrote:
On Fri, 30 Jan 2015, Jeff Law wrote:
+/* If we are testing a single bit resulting from a binary
+ operation in precision P1 where the operands were widened
+ precision P2 and the
74 matches
Mail list logo
