Hi,
I am working right now on PR/56892, which is about missing
inline-optimization for dllexported classes. That's caused by the
default for TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P hook, which
disallows inlining for any machine-attribute. By taking a closer look
to i386's attributes, I don't see
The problem occurs when accessing local array element. For example,
# VUSE .MEM_27
k_8 = parent[k_29];
GCC calculates the address in three steps:
1) addr is calculated as r105 + (-2064).
2) offset is calculated as r165*4.
3) calls offset_address to combine the address into r105+ r165*4 +
This really should come with testcases (e.g. guality ones).
guality testcases are barely maintainable, especially on non-x86 platforms, so
I'd rather not enter this business. I'll discuss with Joel and see whether we
can coordinate with the GDB side.
--
Eric Botcazou
On Mon, Jun 17, 2013 at 09:46:30AM +0200, Eric Botcazou wrote:
This really should come with testcases (e.g. guality ones).
guality testcases are barely maintainable, especially on non-x86 platforms,
so
I'd rather not enter this business. I'll discuss with Joel and see whether
we
can
On Sat, 15 Jun 2013, Jan Hubicka wrote:
I've managed to fix nearly all reported missed merged types for cc1.
Remaining are those we'll never be able to merge (merging would
change the SCC shape) and those that eventually end up refering
to a TYPE_STUB_DECL with a make_anon_name ()
CPU: AMD64 family10, speed 2100 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
mask of 0x00 (No unit mask) count 75
samples %app name symbol name
4504711.7420 lto1 inflate_fast
It might
-Original Message-
From: Eric Botcazou [mailto:ebotca...@adacore.com]
Sent: Monday, June 17, 2013 3:32 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address
mode
when expanding array reference
The problem occurs
My mistake. It's because arm_legitimize_address cannot re-factor [r105 +
r165*4 + (-2064)] into rx = r105 + (-2064); [rx + r165*4]. Do you
suggest that this kind of transformation should be done in backend? I can
think of some disadvantages by doing it in backend:
Different kinds of address
Ping?
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00493.html
Thanks,
Kyrill
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Kyrylo Tkachov
Sent: 10 June 2013 11:52
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw; Ramana
On Mon, 17 Jun 2013, Kugan wrote:
Can you please help to review this patch? Richard reviewed the original patch
and asked it to be split into two parts. Also, he wanted a review from RTL
maintainer for the RTL changes.
Thanks,
Kugan
On 03/06/13 11:43, Kugan wrote:
Hi,
This patch
-Original Message-
From: Eric Botcazou [mailto:ebotca...@adacore.com]
Sent: Monday, June 17, 2013 4:42 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH GCC]Fix PR57540, try to choose scaled_offset address
mode
when expanding array reference
My mistake. It's
On Fri, Jun 14, 2013 at 6:31 PM, Sandra Loosemore
san...@codesourcery.com wrote:
On 06/14/2013 06:31 AM, Richard Biener wrote:
I think we can split the patch up, so let me do piecewise approval of
changes.
The changes that remove the packedp flag passing around and remove
the warning code
On Fri, Jun 14, 2013 at 11:17 PM, David Malcolm dmalc...@redhat.com wrote:
ggc_pch_write_object's parameter d is marked with ATTRIBUTE_UNUSED,
but in fact it is used in 4 places at the end of the function.
Successfully bootstrapped on x86_64-unknown-linux-gnu.
OK for trunk?
Ok.
Thanks,
Hi all,
This arm testsuite patch initialises an array in the
unaligned-memcpy-2.c test to ensure alignment, making the test pass.
This is similar to the patch
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00683.html.
Ok for trunk?
Thanks,
Kyrill
gcc/testsuite/
2013-06-17 Kyrylo Tkachov
On 06/17/13 10:24, Kyrylo Tkachov wrote:
Hi all,
This arm testsuite patch initialises an array in the
unaligned-memcpy-2.c test to ensure alignment, making the test pass.
This is similar to the patch
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00683.html.
Ok for trunk?
Ok - thanks for
This improves the diagnostics messages in case we're using initial
declarations in the for loop, but we're not using C99 or newer standard;
in this case we shouldn't forget about =c11 and =gnu11, where the
initial declaration is fine as well.
Ok for trunk?
2013-06-17 Marek Polacek
Hi,
this patch makes it possible to fold through aliases. It may seem unimportant,
but we
run into those cases in C++ where extra name aliases may get used by
devirtualization
machinery. The patch also fixes the following long standing bug:
jh@gcc10:~/trunk/build2/gcc$ cat t.c
static int a=4;
Hi,
during LTO we seem to give up on many valid devirtualization cases because
the types are not merged by type merging machinery. This is i.e. because their
declarations are different; one unit define a function, while in the other
unit it is just an external declaration.
It is my understanding
Hi Zhenqiang,
This patch causes PR57637 (miscompare in SPEC2000). I'll try to reduce a
testcase.
Thanks,
Kyrill
The *arm_simple_return is the same as simple_return used by
shrink-wrap. *arm_return and *arm_simple_return are not merged
since
*arm_return is for Often the return insn will be
On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch makes it possible to fold through aliases. It may seem
unimportant, but we
run into those cases in C++ where extra name aliases may get used by
devirtualization
machinery. The patch also fixes the
Tested on powerpc64-unknown-linux-gnu with:
make -k check RUNTESTFLAGS=--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}'
gcc/testsuite/ChangeLog
2013-06-17 Sebastian Huber sebastian.hu...@embedded-brains.de
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
---
On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek ja...@redhat.com wrote:
On Sun, Jun 16, 2013 at 01:08:12PM -0600, Sandra Loosemore wrote:
This patch fixes the PR23623 regression. In conjunction with part 2
of the series, it also fixes the new volatile-bitfields-3.c test
case.
As I noted in
Hi,
This patch fixes an ICE where the compiler crashes (with NEON enabled)
during expansion of an instruction such as:
pr48335-5.c:17:1: error: unrecognizable insn:
}
^
(insn 9 8 10 2 (set (reg:DI 116 [ s ])
(unspec:DI [
(mem/c:DI (plus:SI (reg/f:SI 105
This patch makes the following changes:
* Define MAX_CONDITIONAL_EXECUTE in arm backend using max_insns_skipped,
which is set based on the current tune.
* Update max_insns_skipped for Cortex-A15 tune to be 2 (instead of 5).
* Use max_insns_skipped in thumb2_final_prescan_insn to decide when to
On Mon, 17 Jun 2013 13:12:09 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Sun, Jun 16, 2013 at 9:26 PM, Jakub Jelinek ja...@redhat.com
wrote:
On Sun, Jun 16, 2013 at 01:08:12PM -0600, Sandra Loosemore wrote:
This patch fixes the PR23623 regression. In conjunction with part
2
On Mon, Jun 17, 2013 at 11:53 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch makes it possible to fold through aliases. It may seem
unimportant, but we
run into those cases in C++ where extra name aliases may get used by
devirtualization
machinery. The patch also fixes the
Hello Everyone,
Is this patch OK for trunk?
Thanks,
Balaji V. Iyer.
-Original Message-
From: Iyer, Balaji V
Sent: Wednesday, June 12, 2013 1:22 PM
To: gcc-patches@gcc.gnu.org
Cc: anna.m.tikhon...@gmail.com
Subject: [PATCH] for for c/PR57541
Hello Everyone,
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
On Mon, 17 Jun 2013 13:12:09 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Sun, Jun 16, 2013 at 9:26 PM, Jakub
On Mon, Jun 17, 2013 at 01:27:38PM +0100, Julian Brown wrote:
Well -- I'm certainly no expert on the C++ memory model, but I am under
the impression (that I can't seem to verify by googling ;-)) that
accesses to adjacent bitfields during volatile access of a particular
bitfield are forbidden.
On 06/17/2013 02:27 PM, Julian Brown wrote:
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour
On Mon, Jun 17, 2013 at 2:38 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 06/17/2013 02:27 PM, Julian Brown wrote:
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
IIUC,
On 06/17/2013 06:05 AM, Jan Hubicka wrote:
It is my understanding that C++ standard enforces one definition rule for
types, too (to enable sane mangling?) and that we can basically match types
by their name and contextes (namespaces/outer classes)?
Yes. Also for template instantiations and
OK.
Jason
On 06/17/2013 06:05 AM, Jan Hubicka wrote:
It is my understanding that C++ standard enforces one definition rule for
types, too (to enable sane mangling?) and that we can basically match types
by their name and contextes (namespaces/outer classes)?
Yes. Also for template instantiations and
Hi,
also one quick question. I was dumping on when my odr tests fails and only
case I do not understand is the case where decls_same_for_odr ends up comparing
IDENTIFIER_NODE and TYPE_DECL of the same name. Does this mean that they are
different in class hiearchy or do I miss some equality case?
On 06/17/2013 09:07 AM, Jan Hubicka wrote:
Yes. Also for template instantiations and inline functions
(basically, decls with TREE_COMDAT set). That isn't very
Can't those be just merged based on assembler name?
Yes, though they can have local classes that are also subject to the ODR.
I
On 06/17/2013 09:09 AM, Jan Hubicka wrote:
also one quick question. I was dumping on when my odr tests fails and only
case I do not understand is the case where decls_same_for_odr ends up comparing
IDENTIFIER_NODE and TYPE_DECL of the same name.
Hmm, I would guess that it comes from TYPE_NAME
On 06/17/2013 09:07 AM, Jan Hubicka wrote:
Yes. Also for template instantiations and inline functions
(basically, decls with TREE_COMDAT set). That isn't very
Can't those be just merged based on assembler name?
Yes, though they can have local classes that are also subject to the ODR.
I
On 06/17/2013 09:09 AM, Jan Hubicka wrote:
also one quick question. I was dumping on when my odr tests fails and only
case I do not understand is the case where decls_same_for_odr ends up
comparing
IDENTIFIER_NODE and TYPE_DECL of the same name.
Hmm, I would guess that it comes from
Hi,
This patch sets STACK_ARGUMENTS_SIZE with 0 for AArch64 as variadic
arguments to 'bar' are passed in registers on this target.
OK for the trunk?
Thanks,
Yufeng
gcc/testsuite/
* gcc.dg/torture/stackalign/builtin-apply-2.c: set
STACK_ARGUMENTS_SIZE with 0 if __aarch64__
On 06/17/2013 09:35 AM, Jan Hubicka wrote:
To get meaningful warnings, we need to know what decls/types are subject
to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
We can LTO ODR and non-ODR languages together.
Basically everything in C++ is subject to the ODR.
On 06/17/2013 09:35 AM, Jan Hubicka wrote:
To get meaningful warnings, we need to know what decls/types are subject
to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
We can LTO ODR and non-ODR languages together.
Basically everything in C++ is subject to the ODR.
On Mon, 17 Jun 2013, Jan Hubicka wrote:
On 06/17/2013 09:35 AM, Jan Hubicka wrote:
To get meaningful warnings, we need to know what decls/types are subject
to ODR. Do you think you can make C++ FE to drop a flag so middle-end know?
We can LTO ODR and non-ODR languages together.
On Mon, 17 Jun 2013, Jan Hubicka wrote:
On 06/17/2013 09:35 AM, Jan Hubicka wrote:
To get meaningful warnings, we need to know what decls/types are subject
to ODR. Do you think you can make C++ FE to drop a flag so middle-end
know?
We can LTO ODR and non-ODR languages together.
On Mon, 17 Jun 2013, Marek Polacek wrote:
This improves the diagnostics messages in case we're using initial
declarations in the for loop, but we're not using C99 or newer standard;
in this case we shouldn't forget about =c11 and =gnu11, where the
initial declaration is fine as well.
Ok
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
suggestion, but how about disabling the option by default for C++ on
Hi!
Looks good, though I'd appreciate Joseph to look at this from the
option handling POV. Some nits from me below:
On Fri, Jun 14, 2013 at 09:04:40PM +0200, Marek Polacek wrote:
--- gcc/opts.c.mp 2013-06-14 19:23:02.300554991 +0200
+++ gcc/opts.c2013-06-14 20:00:30.377638168
Hi,
This patch adds a r-w alternative to the aarch64_dup_lanemode pattern and
updates the testcase gcc.target/aarch64/scalar_intrinsics.c accordingly.
The patch has been successfully tested on a full regression run in
aarch64-none-elf.
OK for trunk?
-
Thanks
Sofiane
On 17/06/13 16:03, Sofiane Naci wrote:
Hi,
This patch adds a r-w alternative to the aarch64_dup_lanemode pattern and
updates the testcase gcc.target/aarch64/scalar_intrinsics.c accordingly.
The patch has been successfully tested on a full regression run in
aarch64-none-elf.
OK for trunk?
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
+; What the sanitizer should instrument
+Variable
+unsigned int flag_sanitize
Can't you just add Var(flag_sanitize) to the line after fsanitize= ?
I think that would create a string variable, whereas an integer is what's
wanted here.
--
gcc/testsuite/ChangeLog
2013-06-17 Sebastian Huber sebastian.hu...@embedded-brains.de
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
Okay.
Thanks, David
P.S. Please explicitly copy me on patches.
On Mon, Jun 17, 2013 at 03:52:54PM +, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
+; What the sanitizer should instrument
+Variable
+unsigned int flag_sanitize
Can't you just add Var(flag_sanitize) to the line after fsanitize= ?
I think that would
Hi!
This instruction has the predicates/constraints wrong, the r/m argument is
the middle-one, the value from which it should be extracted, rather than
the packed start/length argument. This got broken with PR50766, where the
patch hasn't touched just BMI2, but for unknown reasons also this BMI
Hi!
The following patch shows a performance regression caused by the C++ changes
to evaluate side-effects in x += foo (); first and only then do the
addition. Previously if x was say int and foo () returned unsigned long
long, convert_to_integer would narrow the addition to unsigned int, but
as
On 06/16/2013 11:55 PM, Kai Tietz wrote:
+static bool
+ix86_function_attribute_inlinable_p (const_tree fndecl ATTRIBUTE_UNUSED)
+{
+ return true;
+}
This is hook_bool_const_tree_true.
I have an idea that perhaps the default ought to be true, and that the few
targets (like mep) that have an
Hello Everyone,
This patch will make one of the array notation tests a runnable one
instead of a compile only. I have also changed the return values from just '1'
to distinct values so that it is easier to debug. This patch is committed as
obvious.
Here is the ChangeLog entry:
Hi!
lex_raw_string right now only undoes phase {1,2} transformations in between
Rdelim( and )delim, while it should undo them everywhere between R and
the final . The following patch implements that, and adds testsuite
coverage for that. Bootstrapped/regtested on x86_64-linux and i686-linux,
ok
On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
suggestion, but how about
On Mon, 17 Jun 2013, Jakub Jelinek wrote:
The following patch shows a performance regression caused by the C++ changes
to evaluate side-effects in x += foo (); first and only then do the
addition. Previously if x was say int and foo () returned unsigned long
long, convert_to_integer would
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Richard Henderson
Sent: Thursday, June 13, 2013 12:19 PM
To: Aldy Hernandez
Cc: Iyer, Balaji V; gcc-patches@gcc.gnu.org; Jason Merrill (ja...@redhat.com)
Subject: Re:
On 06/17/2013 10:00 AM, Iyer, Balaji V wrote:
In hindsight, I could have for __sec_reduce_max and __sec_reduce_min. I was
more familiar with conditional expression. Out of curiosity, is there a big
performance benefit of using max/min expr over conditional?
There can be. The COND-MIN/MAX
On 06/12/13 16:36, Jakub Jelinek wrote:
On Wed, Jun 12, 2013 at 10:38:00AM -0700, Richard Henderson wrote:
On 06/12/2013 10:30 AM, Jakub Jelinek wrote:
So the built-ins would take address of this decl, something else?
Perhaps address, perhaps just referenced uninitialized?
True, assuming
On 06/17/2013 10:13 AM, Aldy Hernandez wrote:
- data.simduid = tree_low_cst (gimple_call_arg (stmt, 0), 1);
+ data.simduid = gimple_call_arg (stmt, 0);
Doesn't this copy the ADDR_EXPR from the call into simduid?
simduid_to_vf::hash (const value_type *p)
{
- return p-simduid;
On Mon, 2013-06-17 at 11:18 +0200, Richard Biener wrote:
On Fri, Jun 14, 2013 at 11:17 PM, David Malcolm dmalc...@redhat.com wrote:
ggc_pch_write_object's parameter d is marked with ATTRIBUTE_UNUSED,
but in fact it is used in 4 places at the end of the function.
Successfully bootstrapped
On Mon, Jun 17, 2013 at 10:12:41AM +0200, Jan Hubicka wrote:
CPU: AMD64 family10, speed 2100 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
unit mask of 0x00 (No unit mask) count 75
samples %app name symbol name
On 06/17/2013 10:18 AM, Jan Hubicka wrote:
Does ODR hold also for extern C declarations in C++?
Yes.
In C, you can treat all structurally identical types as the same, right?
In next step we can sort out other reasons they
are not merged by Richard's merging code but stil equivalent in C++
2013/6/17 Richard Henderson r...@redhat.com:
On 06/16/2013 11:55 PM, Kai Tietz wrote:
+static bool
+ix86_function_attribute_inlinable_p (const_tree fndecl ATTRIBUTE_UNUSED)
+{
+ return true;
+}
This is hook_bool_const_tree_true.
Right, we could define macro to this ...
I have an idea
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
I suppose it's OK to fix the regression, though really we should be
eliminating these early convert_to_* optimizations (optimizing later on
GIMPLE if possible) rather than adding to them.
My thought as well. How hard is it to fix this in gimple
On Fri, Jun 14, 2013 at 11:08 AM, Sriraman Tallam tmsri...@google.com wrote:
On Fri, Jun 14, 2013 at 1:43 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Jun 14, 2013 at 4:52 AM, Sriraman Tallam tmsri...@google.com wrote:
On Thu, Jun 13, 2013 at 12:40 PM, Jan Hubicka
Current trunk cannot build LTO kernels now, with your patch,
as reported earlier.
Please fix ASAP. I'm surprised that you checked in a patchkit
with such serious reported problems.
-Andi
backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c: In function 'unlzo':
On Mon, Jun 17, 2013 at 01:44:25PM -0400, Jason Merrill wrote:
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
I suppose it's OK to fix the regression, though really we should be
eliminating these early convert_to_* optimizations (optimizing later on
GIMPLE if possible) rather than adding to
2. I left the cstdlib include in system.h, because removing it will
result in errors due to an inclusion of algorithm. It's probable
that both can be removed, but I didn't test it with this patch.
You mean you don't need algorithm anymore in logic.cc? I think we want
the cstdlib include in
Hello Everyone,
I am adding a new execution test to the array notation suite. In array
notation's __sec_reduce_max_ind and __sec_reduce_min_ind builtin functions, if
there is a tie for max/min value, then the higher index should be returned. In
this case, all the values are the same,
Ping.
Thanks,
Sharad
On Wed, Jun 5, 2013 at 11:18 AM, Sharad Singhai sing...@google.com wrote:
Ping.
Thanks,
Sharad
On Tue, May 28, 2013 at 11:35 AM, Sharad Singhai sing...@google.com wrote:
Sorry, my patch had bad formatting in one of the functions
(output_gcov_file). Here is the
On 06/17/2013 02:09 PM, Jakub Jelinek wrote:
On Mon, Jun 17, 2013 at 01:44:25PM -0400, Jason Merrill wrote:
On 06/17/2013 12:54 PM, Joseph S. Myers wrote:
I suppose it's OK to fix the regression, though really we should be
eliminating these early convert_to_* optimizations (optimizing later on
Ping? I think these are the most recent versions of the unreviewed
patches in the series:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00287.html
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00760.html
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01085.html
There are also these two parts that
On 06/17/2013 02:10 PM, Andrew Sutton wrote:
You mean you don't need algorithm anymore in logic.cc? I think we want
the cstdlib include in general if we're going to support people using the
C++ standard library.
I don't. Those decisions are above my pay grade, so I'm doing my best
not to make
On Mon, 2013-06-17 at 10:41 +0200, Eric Botcazou wrote:
My mistake. It's because arm_legitimize_address cannot re-factor [r105 +
r165*4 + (-2064)] into rx = r105 + (-2064); [rx + r165*4]. Do you
suggest that this kind of transformation should be done in backend? I can
think of some
Hi,
while triaging this PR (the original issue is already fixed) Jonathan
added to the audit trail the attached testcase, which we are still
mishandling. It seems to me that something is wrong in
instantiation_dependent_expression_p: when finish_decltype_type is
called the first time by the
On 06/17/2013 04:08 PM, Paolo Carlini wrote:
+ if (TREE_CODE (TREE_TYPE (*tp)) == ARRAY_TYPE
+ !TYPE_DOMAIN (TREE_TYPE (*tp))
+ DECL_INITIAL (*tp)
+ type_dependent_expression_p (DECL_INITIAL (*tp)))
+ return *tp;
I think this approach makes sense, but it
Andi Kleen a...@firstfloor.org wrote:
Current trunk cannot build LTO kernels now, with your patch,
as reported earlier.
Please fix ASAP. I'm surprised that you checked in a patchkit
with such serious reported problems.
Instructions for reproducing this issue appreciated. I've never built lto
Hello,
I tried to compile LTO kernel with latest gcc, applied patch by
Jan http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334#c6:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab.c:644
On Thu, Jun 13, 2013 at 11:37 AM, Alan Modra amo...@gmail.com wrote:
Revised patch with offsettable_ok_by_alignment change, avoiding dumb
idea of using statement expressions. This one actually bootstraps and
passes regression testing.
* config/rs6000/rs6000.h (enum data_align): New.
Earlier today I wrote:
On 06/17/2013 08:41 AM, Joseph S. Myers wrote:
On Mon, 17 Jun 2013, Julian Brown wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour and the C++ memory model is a
recognised deficiency in the ARM EABI. It might be an unpopular
Hi,
On 06/17/2013 10:30 PM, Jason Merrill wrote:
On 06/17/2013 04:08 PM, Paolo Carlini wrote:
+ if (TREE_CODE (TREE_TYPE (*tp)) == ARRAY_TYPE
+ !TYPE_DOMAIN (TREE_TYPE (*tp))
+ DECL_INITIAL (*tp)
+ type_dependent_expression_p (DECL_INITIAL (*tp)))
+return *tp;
I
On Mon, Jun 17, 2013 at 2:20 PM, Jason Merrill ja...@redhat.com wrote:
I have not thought deeply about constrained friend declarations. What
would a friend temploid look like?
I was thinking something like
template class T struct A {
T t;
requires AddableT()
friend A
On 06/17/13 12:23, Richard Henderson wrote:
On 06/17/2013 10:13 AM, Aldy Hernandez wrote:
- data.simduid = tree_low_cst (gimple_call_arg (stmt, 0), 1);
+ data.simduid = gimple_call_arg (stmt, 0);
Doesn't this copy the ADDR_EXPR from the call into simduid?
2013/6/18 David Edelsohn dje@gmail.com:
gcc/testsuite/ChangeLog
2013-06-17 Sebastian Huber sebastian.hu...@embedded-brains.de
PR target/55033
* gcc.target/powerpc/pr55033.c: Fix options.
Okay.
Thanks, David
P.S. Please explicitly copy me on patches.
Hi, Sebastian,
Since David
I'd like to apply the following set of patches supporting powerpc64le
to the 4.8 branch. David has stated that he's happy with the idea,
even though technically these are not regressions. OK?
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01374.html
OK
/Marcus
On 17 June 2013 14:43, Yufeng Zhang yufeng.zh...@arm.com wrote:
Hi,
This patch sets STACK_ARGUMENTS_SIZE with 0 for AArch64 as variadic
arguments to 'bar' are passed in registers on this target.
OK for the trunk?
Thanks,
Yufeng
gcc/testsuite/
*
90 matches
Mail list logo
