Hi!
As discussed in the PR, this patch hardcodes more sizeof (thread)
sizes for various glibc versions and checks at runtime which one to use.
While I don't like the hardcoding at all and Kostya is asking for some glibc
API to query it, having hardcoded values that are just wrong is worse than
thi
Hi,
this patch fixes two bugs I introducedinto get_binfo_at_offset in the previous
changes.
First BINFO_OFFSET is pointer to INTEGER_CST and not integer as the code
assumes.
Second the code gets confused by presence of empty classes (such as in
testcase) that
may interpose with non-empty.
I fixe
Hi,
while implementing checks in can_refer_decl_in_current_unit_p I had primarily
symbols
with HIDDEN visibility in mind. I just noticed that libstdc++ makes quite few
symbols
with default visbility specified by hand. I see no reason for disabling
optimization
here.
Bootstrapped/regtested x86
Hi,
while merging nodes in lto-symtab, we need to copy the force_output and
forced_by_abi flags.
Thanks to Markus who noticed the issue.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (rev
Hi,
this patch solves the actual ICE in PR59831 by using ipa-devirt instead of
gimple_extract_devirt_binfo_from_cst as discussed in the first post.
Honza
PR ipa/59831
* ipa-cp.c (ipa_get_indirect_edge_target_1): Use ipa-devirt
to figure out targets of polymorphic calls wit
Original Message
Subject: [PATCH][PING] Fix for PR59600 (prohibit inlining if
no_sanitize_address)
Date: Tue, 28 Jan 2014 09:13:10 +0400
From: Yury Gribov
To: GCC Patches
Original Message
Subject: [PATCH] Fix for PR59600
Date: Tue, 21 Jan 2014 14:42:31 +040
On Feb 3, 2014, at 3:52 PM, Joseph S. Myers wrote:
> On Mon, 3 Feb 2014, Andrew Pinski wrote:
>> On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote:
>>> On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote:
>>>
If the presence of the build
tree makes writing some tests significant
Ping? I'm attaching a marginally cleaner version of the test. I've had
a look at integrating this into aapcs64.exp but got defeated in the
end. If go-torture-execute took a list of sources as c-torture-execute
does, then I think adding something like this to aapcs64.exp would work:
# Test passi
Hi,
while playing around with devirtualization I tried to make it to always produce
builtin_unreachable (). This makes early inliner to ICE, since the callgraph
edges
are not properly updated after folding. This is because
cgraph_update_edges_for_call_stmt
is called on a wrong statement.
Does s
On Mon, Feb 03, 2014 at 03:18:49PM -0800, Richard Henderson wrote:
> The problem with this pr is that the -uninit pass could get itself
> into a loop while processing nodes. Within this loop, it would
> allocate memory, therefore the visible symptom was allocation
> failure instead of a non-termin
On Mon, 3 Feb 2014, Andrew Pinski wrote:
> On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote:
> > On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote:
> >
> >> If the presence of the build
> >> tree makes writing some tests significantly simpler, I think that is
> >> OK.
> >
> > I would li
The problem with this pr is that the -uninit pass could get itself
into a loop while processing nodes. Within this loop, it would
allocate memory, therefore the visible symptom was allocation
failure instead of a non-terminating loop.
Amusingly, the case that prods the -uninit pass into this beha
Ping:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01715.html
On 02/01/14 02:58, Jakub Jelinek wrote:
I think AND is necessary for certain variants of the Alpha. In
theory a shift-add might be possible here, but I don't know if it
happens in practice.
Well, from what I can read in simplify-rtx.c, it only adds CONST around
PLUS/MINUS, not around anything
On 02/03/14 01:55, Laurent Alfonsi wrote:
Jeff, All,
As you suggested, I have extended my testing around this fix to prevent
race condition issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602#c8
All my tests passed successfully. Is it ok for trunk ?
Yes, thanks for running those tes
On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo wrote:
> On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote:
>
>> If the presence of the build
>> tree makes writing some tests significantly simpler, I think that is
>> OK.
>
> I would like to discourage that. Testing an already installed GCC f
Hi,
On Mon, 13 Jan 2014 10:26:03, Joey Ye wrote:
>
> Bernd,
>
> If that's the case, can you please firstly fix invoke.texi where the
> behavior of strict-volatile-bitfields is described? At least my
> interpretation of current doc doesn't explain the behavior of the case
> we are discussing. Also
Committed to branch dmalcolm/jit:
Expose the debug string facility to client code, to make it easier to
write client code. In doing so, it makes sense to simply expose the
ultimate base class of "contextual object" as gcc_jit_object, to better
express which objects are "contextual", and to suppor
Hi,
this is the first half of the original fix to the PR, bit expanded in length.
The main change is simple: we now devirtualize when aggregate propagation tells
us the virtual table pointer value. This is done to prevent fold() doing it
during inliner's function saving that confuses the cgraph on
On 02/03/14 12:15, Jakub Jelinek wrote:
On Mon, Feb 03, 2014 at 11:11:31AM -0800, Ian Lance Taylor wrote:
On Mon, Feb 3, 2014 at 10:03 AM, Paul Pluzhnikov wrote:
We test GCC without access to the build tree (we only have convenient access to
install and source trees).
Building libgomp.c/affi
On Mon, Feb 03, 2014 at 11:11:31AM -0800, Ian Lance Taylor wrote:
> On Mon, Feb 3, 2014 at 10:03 AM, Paul Pluzhnikov
> wrote:
> >
> > We test GCC without access to the build tree (we only have convenient
> > access to
> > install and source trees).
> >
> > Building libgomp.c/affinity-1.c and lib
On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor wrote:
> If the presence of the build
> tree makes writing some tests significantly simpler, I think that is
> OK.
I would like to discourage that. Testing an already installed GCC for
which no build tree exists is a very useful feature.
Interna
On Mon, Feb 3, 2014 at 10:03 AM, Paul Pluzhnikov wrote:
>
> We test GCC without access to the build tree (we only have convenient access
> to
> install and source trees).
>
> Building libgomp.c/affinity-1.c and libgomp.c++/affinity-1.C fails in
> such testing, because of '#include "config.h"' whi
Hi,
On 02/03/2014 05:55 PM, Jason Merrill wrote:
On 02/03/2014 11:52 AM, Paolo Carlini wrote:
Note, anyway, that unfortunately it's pretty easy to construct an ICE on
valid too, which doesn't seem a regression, but should be also looked
at.
struct B { };
template struct A : virtual B
{
A
On 02/03/2014 11:52 AM, Paolo Carlini wrote:
Note, anyway, that unfortunately it's pretty easy to construct an ICE on
valid too, which doesn't seem a regression, but should be also looked at.
struct B { };
template struct A : virtual B
{
A();
A(const A&);
};
template A::A(const A&) = def
Greetings,
We test GCC without access to the build tree (we only have convenient access to
install and source trees).
Building libgomp.c/affinity-1.c and libgomp.c++/affinity-1.C fails in
such testing, because of '#include "config.h"' which is nowhere to be
found.
Is that a bug?
Should I open a
On 02/03/2014 12:46 PM, Marc Glisse wrote:
The C version of default_conversion does not convert a function_decl to
a pointer (that's done earlier, during parsing), it ICEs.
Ah, I see. The patch is OK, then.
Jason
On Mon, 3 Feb 2014, Jason Merrill wrote:
On 01/18/2014 05:33 PM, Marc Glisse wrote:
So when we have: __attribute__((nonnull(bar,bar)))
the parser will keep bar as an identifier for the first argument, but
parse the second one as an expr-list and thus find the associated
function_decl.
OK, tha
Hi Jeff, Hi Alex,
Currently the mainline MN10300 toolchain does not build the
libstdc++-v3 library because:
/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1213:5:
error: unable to find a register to spill in class 'EXTENDED_REGS'
mn10300-elf/mn10300-elf/libstdc++-v3/include/
On Mon, Feb 3, 2014 at 2:55 AM, Rainer Orth
wrote:
> Ian Lance Taylor writes:
>
>> On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth
>> wrote:
>>>
>>> Given that there were no other comments, I'd like to install the patch
>>> now. Ian, could you please install the ltmain.sh patch in libgo/config,
>
Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be
replaced by a move somewhere.
So I'm all for fixing this but I don't really know where to start. Do
you have any suggestions? Julian's patch now looks more like a workaround...
-Y
On 02/03/14 10:11, Nick Clifton wrote:
Hi Jeff, Hi Alex,
Currently the mainline MN10300 toolchain does not build the
libstdc++-v3 library because:
/libstdc++-v3/include/bits/locale_facets_nonio.tcc:1213:5:
error: unable to find a register to spill in class 'EXTENDED_REGS'
On 01/18/2014 05:33 PM, Marc Glisse wrote:
So when we have: __attribute__((nonnull(bar,bar)))
the parser will keep bar as an identifier for the first argument, but
parse the second one as an expr-list and thus find the associated
function_decl.
OK, that makes sense. But why do we need to handl
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Dutch team of translators. The file is available at:
http://translationproject.org/latest/cpplib/nl.po
(This file, 'cpplib-4.9-b20140202.n
cpplib-4.9-b20140202.nl.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On 02/03/2014 05:17 PM, Jason Merrill wrote:
Use vec_safe_is_empty instead of checking the two representations of
an empty vector separately. OK with that change.
Ah nice. Thanks.
Note, anyway, that unfortunately it's pretty easy to construct an ICE on
valid too, which doesn't seem a regressi
On Fri, Jan 31, 2014 at 10:43 PM, Brooks Moses wrote:
> The gcc_update file is missing an entry for
> gcc/config/aarch64/aarch64.md; this patch adds it.
>
> Ok for trunk?
OK.
Diego.
Use vec_safe_is_empty instead of checking the two representations of an
empty vector separately. OK with that change.
Jason
> The subreg being replaced is believable, but not the zero_extend.
> That would mean we had a simple movhi pattern, not a zero-extend pattern.
Sorry, you are right. It's just subreg without zero_extend!
-Y
Hi,
in this ICE on invalid regression, after a sensible error message about
the invalid base type we crash in implicit_declare_fn at the gcc_assert:
else if (trivial_p && cxx_dialect >= cxx11
&& (kind == sfk_copy_constructor
|| kind == sfk_move_constructor))
gcc_assert
Hi all,
This patch will ensure testsuite/gcc.target/arm/fixed_float_conversion.c
is checked only when "-mfpu=vfp3 -mfloat-abi=softfp" is applicable for
the target.
Accordingly, two procs (check_effective_target_arm_vfp3_ok and
add_options_for_arm_vfp3) are added into
gcc/testsuite/lib/targe
On Fri, Jan 31, 2014 at 10:19:12AM -0800, H.J. Lu wrote:
> On Fri, Jan 31, 2014 at 10:12 AM, Joseph S. Myers
> wrote:
> > On Fri, 31 Jan 2014, Andrew Pinski wrote:
> >
> >> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
> >> > Hi,
> >> >
> >> > For 64-bit Android, long double is 128-bit IEEE-754
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Russian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/ru.po
(This file, 'cpplib-4.9-b20140202
cpplib-4.9-b20140202.ru.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Mon, Feb 03, 2014 at 04:42:39PM +0100, Richard Biener wrote:
>
> This fixes PR60012 by considering TBAA for all DDRs in vectorizer
> dependence analysis because the vectorizer can rely on at least
> covering two scalar iterations.
>
> It _should_ be a regression from 4.4 but I can't make a tes
On Mon, Feb 3, 2014 at 4:29 PM, Teresa Johnson wrote:
> This patch fixes a bug in the dumping code, whereby an inner loop
> index variable was the same as the outer loop index variable, and the
> redef caused an infinite loop.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
This fixes PR60012 by considering TBAA for all DDRs in vectorizer
dependence analysis because the vectorizer can rely on at least
covering two scalar iterations.
It _should_ be a regression from 4.4 but I can't make a testcase
that has two TBAA disambiguatable types and is vectorized with 4.4
it
[this time to the list]
On 03/02/14 15:41, Yury Gribov wrote:
> > Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be
> > replaced by a move somewhere.
>
> Actually the whole (zero_extend:SI (subreg:HI ...)) part is replaced by
> (const_int 1). It still ends up in constant p
> Uggh - what a mess. Surely that zero_extend:SI (const_int 1) should be
> replaced by a move somewhere.
Actually the whole (zero_extend:SI (subreg:HI ...)) part is replaced by
(const_int 1). It still ends up in constant pool though.
-Y
This patch fixes a bug in the dumping code, whereby an inner loop
index variable was the same as the outer loop index variable, and the
redef caused an infinite loop.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
2014-02-03 Teresa Johnson
* tree-vect-slp.c (vect_s
Hi Jakub!
On 31.01.2014 15:45, Ilmir Usmanov wrote:
Hi Jakub!
Thank you for review and quick answer.
The above are OpenACC specific clauses, so they should have OACC_LIST_*?
I just followed Thomas's style recomendations:
If we're adding new names for implementing OpenACC things, maybe we
sho
On 03/02/14 15:14, Yury Gribov wrote:
> > Additionally I'm not really sure
> > why there is an additional load from the constant pool here - what is
> > the constant in this case ?
> > Given it is atmost a 16 bit constant
> > surely that should be loaded with a single mov(w) instruction
> > i
On Mon, Feb 3, 2014 at 3:14 PM, Yury Gribov wrote:
>> Additionally I'm not really sure
>> why there is an additional load from the constant pool here - what is
>> the constant in this case ?
>> Given it is atmost a 16 bit constant
>> surely that should be loaded with a single mov(w) instruction
>>
> Additionally I'm not really sure
> why there is an additional load from the constant pool here - what is
> the constant in this case ?
> Given it is atmost a 16 bit constant
> surely that should be loaded with a single mov(w) instruction
> in armv7 land.
I've made some investigations with 4.8.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Brazilian Portuguese team of translators. The file is available at:
http://translationproject.org/latest/cpplib/pt_BR.po
(This file, 'cppl
cpplib-4.9-b20140202.pt_BR.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hi!
On Mon, 3 Feb 2014 13:56:48 +0400, Ilya Tocar wrote:
> > In r207132, I have now committed a merge of trunk r206958 (2014-01-23).
> > Compared to a pristine trunk r206958 build, there is one regression:
> >
> > FAIL: g++.dg/gomp/declare-simd-1.C -std=c++98 (internal compiler error)
> >
Dear all,
The attached patch to trunk svn.rev 207422 is slightly improving the
documentation
of plugins (notably the few features & bugfixes I have introduced in 4.9)
gcc/ChangeLog entry
2014-02-03 Basile Starynkevitch
* doc/plugins.texi (Plugin callbacks): Mention PLUGIN_IN
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Ukrainian team of translators. The file is available at:
http://translationproject.org/latest/cpplib/uk.po
(This file, 'cpplib-4.9-b201402
cpplib-4.9-b20140202.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Just noticed this typo while reading the man page.
Committed as obvious.
2014-02-03 Markus Trippelsdorf
* doc/invoke.texi: (fprofile-reorder-functions): Fix typo.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 268abf680653..5c396007a984 100644
--- a/gcc/doc/invoke.texi
+
Hello,
On 14.08.2013 17:12, Andrey Belevantsev wrote:
Hello,
As noted in Bugzilla, the problem is this PR is the rare case of removing
the unconditional jump that is used for traversing CFG when simplifying
control flow. We rescan the remaining successors when we know the flow
below the curren
Hi all,
There is a slight issue with the libatomic Makefile for arm linux ifunc targets.
It adds an explicity -march=armv7-a option to the command line to enable
building the exclusive instruction variants in libatomic. However, if the
multilib machinery tries to add an -mcpu option that confl
Hi all,
This patch updates the thumb2_movhi_insn pattern for the -mrestrict-it rules. I
had somehow missed it when doing the -mrestrict-it work last year, and it is
possible to generate a deprecated IT block form in ARMv8 Thumb2 codegen without
this patch.
Tested arm-none-eabi and bootstrapp
Hi all,
I've regenerated arm-tables.opt in config/arm. I should have done that when
committing the -march=armv7ve patch (r207237). I've regenerated it, made sure
that the tests that were failing due to this PASS and committed it as r207418.
Sorry for the noise,
Kyrill
2014-02-03 Kyrylo Tka
Ian Lance Taylor writes:
> On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth
> wrote:
>>
>> Given that there were no other comments, I'd like to install the patch
>> now. Ian, could you please install the ltmain.sh patch in libgo/config,
>> or should I do so myself?
>
> I'll do it. Thanks.
Could y
On Mon, 3 Feb 2014, James Greenhalgh wrote:
> Will and I were trying to understand the semantics of volatile asm
> statements (we didn't succeed!) when we came across documentation
> for:
>
> gimple_asm_clear_volatile
>
> This function looks like it is long gone, so this patch removes the
> doc
Hi,
I agree to changelog change. Could this patch, please, be submitted as I
do not have rights to do so.
Kind regards,
Alex
On 30/01/14 22:36, Marcus Shawcroft wrote:
On 30 January 2014 15:28, Alex Velenko wrote:
Hi,
This patch fixes shift right pattern, as it failed on -O0 after shift
righ
cpplib-4.9-b20140202.sv.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/cpplib/sv.po
(This file, 'cpplib-4.9-b20140202
On 02/03/14 09:58, Renlin Li wrote:
Hi all,
This is a simple patch which fix a type error found in
gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
Okay for trunk?
Ok.
Ramana
Regards,
Renlin Li
gcc/testsuite/ChangeLog:
2014-02-03 Renlin Li
* gcc.target/arm/ftest-armv7a-thumb
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/gcc-
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'cpplib' has been made available
to the language teams for translation. It is archived as:
http://translationproject.org/POT-files/c
On 02/02/14 19:02, Renlin Li wrote:
Hi all,
This is a simple patch which resolves
testsuite/gcc.target/aarch64/aapcs64/ret-func-1.c regression.
Basically, no special operations are needed for vector type i32in128
or f32in64 in big-endian mode any more due the aarch64 back-end change.
Okay
Status
==
After two months of Stage 3 the trunk is now in release-branch mode
which means only patches fixing regressions and documentation issues
are appropriate.
We're getting a lot of bugs fixed and thus the quality data below
shows we are on track for a release around the beginning of Ap
Hi all,
This is a simple patch which fix a type error found in
gcc/testsuite/gcc.target/arm/ftest-armv7a-thumb.c
Okay for trunk?
Regards,
Renlin Li
gcc/testsuite/ChangeLog:
2014-02-03 Renlin Li
* gcc.target/arm/ftest-armv7a-thumb.c: Change aramv7-a to armv7-a.diff --git a/gcc/tests
> In r207132, I have now committed a merge of trunk r206958 (2014-01-23).
> Compared to a pristine trunk r206958 build, there is one regression:
>
> FAIL: g++.dg/gomp/declare-simd-1.C -std=c++98 (internal compiler error)
> FAIL: g++.dg/gomp/declare-simd-1.C -std=c++11 (internal compiler er
These are statistically significant differences: increasing by 0.23%
for the version 4.8.0, increasing by 0.21% for the version 4.8.1,
decreasing by 0.686% for trunk.
These are new row numbers:
2013-11-05 Roman Gareev :
> 2013/10/31 Florian Weimer :
>> On 10/20/2013 02:55 PM, Roman Gareev wrote:
Hello,
On 01.02.2014 19:16, H.J. Lu wrote:
Hi,
init_regs_for_mode accesses global_regs before checking if regno is OK
for a mode, which leads to buffer overflow. This patch moves
HARD_REGNO_MODE_OK for checking global_regs. There is no functional
change. OK for trunk?
This is fine, you'd n
Hi,
Will and I were trying to understand the semantics of volatile asm
statements (we didn't succeed!) when we came across documentation
for:
gimple_asm_clear_volatile
This function looks like it is long gone, so this patch removes the
documentation.
Checked to ensure gimple.texi still build
On 01/17/2014 11:26 AM, Florian Weimer wrote:
On 01/08/2014 03:57 PM, Florian Weimer wrote:
What about the attached version? It still does not exactly match your
original suggestion because gimple_call_lhs (stmt) can be NULL_TREE if
the result is ignored and this case needs instrumentation, as
Jeff, All,
As you suggested, I have extended my testing around this fix to prevent
race condition issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58602#c8
All my tests passed successfully. Is it ok for trunk ?
Thanks,
Laurent
On 10/03/13 17:01, Laurent Alfonsi wrote:
Hi All,
We hav
>> the attached patch fixes an OOP-related 4.7-only regression. Pretty
>> much straightforward, for details see PR.
>>
>> Regtested on x86_64-unknown-linux-gnu. Ok for 4.7?
>>
> Yes, thanks.
Thanks, Mikael. Committed as r207417.
Cheers,
Janus
83 matches
Mail list logo
