The problem is that when vect_multiple_sizes is true, then no correct
number exist (at least, theoretically). That's because number of
diagnostic messages depends on number of available vector sizes - for
now this number is usually 2 (on x86 it's 256 and 128 bit vectors), so
we could change 'xfail'
On Mon, Dec 12, 2011 at 12:00:47PM +0400, Michael Zolotukhin wrote:
> The problem is that when vect_multiple_sizes is true, then no correct
> number exist (at least, theoretically). That's because number of
> diagnostic messages depends on number of available vector sizes - for
> now this number is
Jakub Jelinek writes:
> On Sun, Dec 11, 2011 at 02:48:52PM +0100, Mikael Pettersson wrote:
> > This patch, r182112 on 4.6 branch, caused a test suite regression on
> > arm-linux-gnueabi:
> >
> > +FAIL: gcc.c-torture/execute/20050713-1.c compilation, -O2 (internal
> > compiler error)
> >
Hello!
> This patch fixes dg-final scans in tests from vect.exp suite, which
> currently fail when avx2 is used.
--- a/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
+++ b/gcc/testsuite/gcc.dg/vect/no-section-anchors-vect-31.c
@@ -88,5 +88,6 @@ int main (void)
/* { dg-final { scan-tree-
section names can be at most 16 characters for mach-o;
I applied the following as obvious (r182220)
cheers
Iain
gcc:
* config/darwin-sections.def (zobj_const_data_section): Fix over-
length section name.
Index: gcc/config/darwin-sections.def
=
On Sun, 11 Dec 2011, Ira Rosen wrote:
> On 9 December 2011 19:08, Jakub Jelinek wrote:
> > Hi!
> >
> > As mentioned in the PR, we ICE on the following testcase, because
> > there are DRs in a GIMPLE_CALL stmt and when there is just one, we
> > compute vectype for the call as if it were a load or
Jonathan Wakely writes:
> On 11 December 2011 22:22, Fabien Chêne wrote:
>>
>> Consequently, I propose to deprecate them with a warning, as clang already
>> does.
>> So that you get a warning for the following code:
>>
>> struct A { int i; };
>> struct B : A
>> {
>> A::i; // <- warning here
>>
On 12 December 2011 09:18, Andreas Schwab wrote:
> Jonathan Wakely writes:
>
>> On 11 December 2011 22:22, Fabien Chêne wrote:
>>>
>>> Consequently, I propose to deprecate them with a warning, as clang already
>>> does.
>>> So that you get a warning for the following code:
>>>
>>> struct A { int
On Sat, Dec 10, 2011 at 6:23 PM, Eric Botcazou wrote:
> Hi,
>
> this removes all the occurrences of int64_t in the host code, as well as some
> gratuitous occurrences of int32_t (there are real ones in DFP and LTO code).
> Tested on i586-suse-linux and x86_64-suse-linux. Any objections?
>
> Are t
On Sat, Dec 10, 2011 at 10:31 PM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline and 4.6 branch at -O for the SPARC.
> The compiler again generates an unaligned access for the memcpy calls in:
>
> struct event {
> struct {
> unsigned int sec;
> } sent __attrib
On Sun, Dec 11, 2011 at 6:03 PM, Steven Bosscher wrote:
> Hello,
>
> The configure scripts check for -Wno-narrowing, but GCC ignores rather
> than rejects unknown -Wno-* warnings.
>
> Fixed by checking for the positive warning, -Wnarrowing.
>
> OK for trunk?
But that will now pass -Wnarrowing ins
Hi,
On Sat, Dec 10, 2011 at 10:31:23PM +0100, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline and 4.6 branch at -O for the SPARC.
> The compiler again generates an unaligned access for the memcpy calls in:
>
> struct event {
> struct {
> unsigned int sec;
>
>@@ -993,7 +1005,7 @@ lto_resolution_read (splay_tree file_ids
>{
> int t;
> char offset_p[17];
>- int64_t offset;
>+ host_int64 offset;
> t = fscanf (resolution, "@0x%16s", offset_p);
> if (t != 1)
> internal_error ("could not parse file offset");
This s
On 12/10/2011 12:05 PM, Kai Tietz wrote:
> 2011-12-10 Kai Tietz
>
> PR libgcj/50053
> * java/lang/natClass.cc (java::lang::Class::newInstance): Special case
> member-call for 32-bit IA native Window target.
OK, thanks.
Andrew.
Jonathan Wakely writes:
> On 12 December 2011 09:18, Andreas Schwab wrote:
>> Jonathan Wakely writes:
>>
>>> On 11 December 2011 22:22, Fabien Chêne wrote:
Consequently, I propose to deprecate them with a warning, as clang already
does.
So that you get a warning for the foll
On Mon, Dec 12, 2011 at 12:02, Janne Blomqvist
wrote:
>>@@ -993,7 +1005,7 @@ lto_resolution_read (splay_tree file_ids
>> {
>> int t;
>> char offset_p[17];
>>- int64_t offset;
>>+ host_int64 offset;
>> t = fscanf (resolution, "@0x%16s", offset_p);
>> if (t != 1)
>>
Richard Henderson writes:
> On 12/11/2011 04:50 AM, Richard Sandiford wrote:
>> [Mingjie, please could you help with the Loongson question near the end?]
>
> Actually, can you tell me how to test these abi combinations? I keep
> trying to use mips-sim or mips64-sim and get linker errors complaini
On 12/11/2011 04:05 PM, Jonathan Wakely wrote:
ping
In my opinion __is_final would be definitely useful in general, for 4.8,
and 4.7 too, if isn't too late.
As regards the wider issue which is being discussed on the reflector -
beware, I didn't follow all the messages - 'final' disabling a ni
> Here is a patch wich introduces new pass 'ree' based on pass
> 'implicit_zee' as was discussed above.
Thanks.
> 2011-11-22 Enkovich Ilya
>
> PR target/50038
> * implicit-zee.c: Delete.
> * ree.c: New file.
> * Makefile.in: Replace implicit-zee.c with ree.c.
> *
On Fri, 9 Dec 2011, Richard Guenther wrote:
>
> This fixes PR46796 by making sure the types in the type variant chain
> can be looked up again using get_qualified_type.
>
> LTO bootstrap and regtest running on x86_64-unknown-linux-gnu.
Actually I didn't like that patch very much and here is a m
I changed xfails to target-checks - for now I use common
vect_multiple_sizes (though it'll fail when wider vectors emerge).
Also, I changed AVX-check to the version Uros suggested. Please check
updated patch (attached).
As for vect_multiple_sizes_32B_16B and similar - isn't it too
target-specific?
On Mon, Dec 12, 2011 at 03:00:52PM +0400, Michael Zolotukhin wrote:
> I changed xfails to target-checks - for now I use common
> vect_multiple_sizes (though it'll fail when wider vectors emerge).
> Also, I changed AVX-check to the version Uros suggested. Please check
> updated patch (attached).
>
Hi,
so as no other review happend, I changed patch as you suggested.
Tested for i686-w64-mingw32, and regression tested for
x86_64-unknown-linux-gnu. Ok for apply?
Regards,
Kai
ChangeLog
2011-12-12 Kai Tietz
PR libstdc++/511135
* libsupc++/cxxabi.h (__cxxabi_dtor_type): Ne
On 12/12/2011 12:11 PM, Kai Tietz wrote:
Hi,
so as no other review happend, I changed patch as you suggested.
Well, sorry for not noticing earlier, but here, as in many other cases,
I think it would be much cleaner to have the pre-processor games in the
mingw config header, define a macro name
On 12/12/2011, Paolo Carlini wrote:
> On 12/11/2011 04:05 PM, Jonathan Wakely wrote:
>> ping
> In my opinion __is_final would be definitely useful in general, for 4.8,
> and 4.7 too, if isn't too late.
As we've got the final keyword in 4.7 I think we really want
__is_final in the front end too.
>
On 12/12/2011 12:19 PM, Jonathan Wakely wrote:
As regards the wider issue which is being discussed on the reflector -
beware, I didn't follow all the messages - 'final' disabling a nice
optimization like EBO makes me very nervous. Really, doesn't seem part
of the intended general philosophy in th
2011/12/12 Paolo Carlini :
> On 12/12/2011 12:11 PM, Kai Tietz wrote:
>>
>> Hi,
>>
>> so as no other review happend, I changed patch as you suggested.
>
> Well, sorry for not noticing earlier, but here, as in many other cases, I
> think it would be much cleaner to have the pre-processor games in th
Avoid hard-coded constants and simply reuse the prefix for ar and ranlib.
No behavioural change.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-12-12 Tristan Gingold
* mlib-tgt-specific-xi.adb: (Get_Target_Prefix): Simplify code.
Index: mlib-tgt-specific-xi.adb
==
On some platforms, the sockets support code for the GNAT runtime library
needs to redefine C macro FD_SETSIZE to increase its value from the system
default. This must occur before any system header file is included, so that
all code sees a consistent value.
Tested on x86_64-pc-linux-gnu, committed
The First and Last selector functions return a value that depends on whether
this is complete or partial iteration. For complete iteration, the selector
function returns the logical beginning of the entire sequence of items in the
container. (To be specific, Container.First for a forward iterator,
On 12/12/2011 12:29 PM, Kai Tietz wrote:
Well, this was my initial attempt to solve it. The issue here is that
libsupc++ doesn't use the the os-header-file
Are you sure? Should include bits/c++config.h, no?
Paolo.
gcc-patches-ow...@gcc.gnu.org wrote on 12/12/2011 01:00:52 PM:
> I changed xfails to target-checks - for now I use common
> vect_multiple_sizes (though it'll fail when wider vectors emerge).
> Also, I changed AVX-check to the version Uros suggested. Please check
> updated patch (attached).
>
> A
> Well, I can live with this change (though I cannot approve anything).
> On the other hand, the real underlying problem is that expander cannot
> handle unaligned MEM_REFs where strict alignment is required. SRA is
> of course much more prone to create such situations than anything else
> but I w
2011/12/12 Paolo Carlini :
> On 12/12/2011 12:29 PM, Kai Tietz wrote:
>>
>> Well, this was my initial attempt to solve it. The issue here is that
>> libsupc++ doesn't use the the os-header-file
>
> Are you sure? Should include bits/c++config.h, no?
>
> Paolo.
Well, I tested it, and I saw that the
If an object and/or exec directory exists and is declared in a project
with no source, it was not taken into account. This patch correct this.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-12-12 Vincent Celier
* prj-nmsc.adb (Get_Directories): For a non extending project,
This patch fixes an obscure bug where gnat was failing to detect an illegal
call on an abstract operator. In particular, when the operands are of a
universal numeric type. This bug occurred only in Ada 2005 mode (and higher).
The following test should get an error:
illegal_abst_func.adb:5:24: can
2011/12/12 Kai Tietz :
> 2011/12/12 Paolo Carlini :
>> On 12/12/2011 12:29 PM, Kai Tietz wrote:
>>>
>>> Well, this was my initial attempt to solve it. The issue here is that
>>> libsupc++ doesn't use the the os-header-file
>>
>> Are you sure? Should include bits/c++config.h, no?
>>
>> Paolo.
>
> We
On 12 December 2011 11:29, Kai Tietz wrote:
> 2011/12/12 Paolo Carlini :
>> On 12/12/2011 12:11 PM, Kai Tietz wrote:
>>>
>>> Hi,
>>>
>>> so as no other review happend, I changed patch as you suggested.
>>
>> Well, sorry for not noticing earlier, but here, as in many other cases, I
>> think it woul
On 12 December 2011 10:08, Andreas Schwab wrote:
> Jonathan Wakely writes:
>
>> On 12 December 2011 09:18, Andreas Schwab wrote:
>>> Jonathan Wakely writes:
>>>
On 11 December 2011 22:22, Fabien Chêne wrote:
>
> Consequently, I propose to deprecate them with a warning, as clang
On 12/12/2011 12:50 PM, Jonathan Wakely wrote:
I think Paolo means:
#ifdef _GLIBCXX_USE_THISCALL_ON_DTOR
typedef void (__thiscall *__cxxabi_dtor_type) (void *);
#else
typedef void (*__cxxabi_dtor_type) (void *);
#endif
instead of testing __MINGW32__ and __i386__
This for sure, but I think we co
> I think there is a difference between different vector sizes, and calling
> it vect_X_vector_size_available is not sufficient. Your patch will cause
> failures on ARM. It has two vector sizes, 16 and 8 bytes. E.g., vect-33.c
> gets vectorized with the default vector size, and the alignment messag
Any update?
On 5 December 2011 15:14, Michael Zolotukhin
wrote:
> Hi Jan,
> I debugged the changes, and I think I've hunted down all the bugs.
> I slightly refactored the code - now all new SSE-related code is more
> localized. Also, I fixed some alignment issues.
> Please find the new patch in t
2011/12/12 Paolo Carlini :
> On 12/12/2011 12:50 PM, Jonathan Wakely wrote:
>>
>> I think Paolo means:
>>
>> #ifdef _GLIBCXX_USE_THISCALL_ON_DTOR
>> typedef void (__thiscall *__cxxabi_dtor_type) (void *);
>> #else
>> typedef void (*__cxxabi_dtor_type) (void *);
>> #endif
>>
>> instead of testing __
This patch removes primitive 'alignment to tagged types. This value
is now stored in the Type Specific Data record associated with each
tagged type since it is information known at compile-time.
Tested on x86_64-pc-linux-gnu, committed on trunk
2011-12-12 Javier Miranda
* a-tags.ads (
On Mon, Dec 12, 2011 at 03:57:09PM +0400, Michael Zolotukhin wrote:
> By the way, how could we check if '-mprefer-avx128' was specified from
> target-supports.exp? Is there any global-variable for command line
> options or something similar?
I'd say try some very simple vectorized loop and check h
If the expression function is not a completion, the usage names in the
expression must be determined at the point of declaration, even though the
generated body is inserted at the end of the current declaration list or
package to prevent early freezing.
The following must be rejected with:
f
On 12/12/2011 12:58 PM, Kai Tietz wrote:
Fine, nevertheless the test in os-config file for __i386__ is
required, as just for IA 32-bit this calling convention is for
interest. Neither x64 nor ARM etc requires it.
So - just out of curiosity, ultimately you are responsible for the
config files -
Michael Zolotukhin wrote on 12/12/2011
01:57:09 PM:
>
> By the way, how could we check if '-mprefer-avx128' was specified from
> target-supports.exp?
>
If I understand your question correctly, you can use check-flags (see
check_effective_target_arm_fp16_ok_nocache for example).
> Is there any
2011/12/12 Paolo Carlini :
> On 12/12/2011 12:58 PM, Kai Tietz wrote:
>>
>> Fine, nevertheless the test in os-config file for __i386__ is required, as
>> just for IA 32-bit this calling convention is for interest. Neither x64 nor
>> ARM etc requires it.
>
> So - just out of curiosity, ultimately yo
On Mon, Dec 12, 2011 at 02:16:04PM +0200, Ira Rosen wrote:
> Michael Zolotukhin wrote on 12/12/2011
> 01:57:09 PM:
>
> >
> > By the way, how could we check if '-mprefer-avx128' was specified from
> > target-supports.exp?
> >
>
> If I understand your question correctly, you can use check-flags (s
On 12/12/2011 01:19 PM, Kai Tietz wrote:
Well, this is mainly caused by different feature-set of runtimes. We
could solve things here also by probing for specific runtimes and so
using just on configure tree.
Ah, thus, it's *not* true that mingw32, at variance with mingw32-w64, is
only used for
2011/12/12 Paolo Carlini :
> On 12/12/2011 01:19 PM, Kai Tietz wrote:
>>
>> Well, this is mainly caused by different feature-set of runtimes. We
>> could solve things here also by probing for specific runtimes and so
>> using just on configure tree.
>
> Ah, thus, it's *not* true that mingw32, at va
Hi,
So updated patch is:
Looks good to me. I guess that in principle we could try to have a macro
which is the typedef itself, but what you tested seems good enough to
resolve the PR.
Thanks,
Paolo.
On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote:
> Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
Any reason not to put this in google/main for future trunk inclusion.
Should this be backported to gcc-4_6-branch?
Diego.
PS: remember to adjust the Copyright years of eh_throw.cc and
unwind-cxx.h. I would also mention the PR in the os_* files.
Paolo.
On 12/12/2011 02:14 PM, Diego Novillo wrote:
On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote:
Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
Any reason not to put this in google/main for future trunk inclusion.
Should this be backported to gcc-4_6-branch?
Note that back
On Mon, Dec 12, 2011 at 08:17, Paolo Carlini wrote:
> On 12/12/2011 02:14 PM, Diego Novillo wrote:
>>
>> On Sun, Dec 11, 2011 at 19:05, Easwaran Raman wrote:
>>
>>> Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
>>
>> Any reason not to put this in google/main for future trunk i
2011/12/12 Paolo Carlini :
> PS: remember to adjust the Copyright years of eh_throw.cc and unwind-cxx.h.
> I would also mention the PR in the os_* files.
>
> Paolo.
Thanks for the reminder about copyright. Added comment about pr and
added copyright year to files not mentioning 2011.
Applied at re
On 12/12/2011 02:21 PM, Diego Novillo wrote:
Ah, right. I missed the ABI implications.
For possible inclusion in mainline too, things don't seem completely ok:
nothing should be added to the baseline and very likely the export
should be adjusted to accommodate for different size_t on the variou
On Mon, Dec 12, 2011 at 12:40 PM, Eric Botcazou wrote:
>> Well, I can live with this change (though I cannot approve anything).
>> On the other hand, the real underlying problem is that expander cannot
>> handle unaligned MEM_REFs where strict alignment is required. SRA is
>> of course much more
Fix flags for edges from/to entry/exit basic blocks.
W/o this patch I hit internal asserts when trying to
split the edge from entry block.
Index: gcc/cgraphunit.c
===
--- gcc/cgraphunit.c(revision 182237)
+++ gcc/cgraphunit.c(
On Windows, the 'Count attribute was very slow in "Annex D" mode. This patch
fixes that efficiency problem. "Annex D" mode is invoked if there is a pragma
Task_Dispatching_Policy (FIFO_Within_Priorities).
Tested on i686-pc-mingw, committed on trunk
2011-12-12 Bob Duff
* s-taprop-mingw
On Mon, 12 Dec 2011, Kai Tietz wrote:
Index: gcc/libstdc++-v3/libsupc++/cxxabi.h
===
--- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h
+++ gcc/libstdc++-v3/libsupc++/cxxabi.h
@@ -51,6 +51,10 @@
#include
#include
+#ifndef _GLIBCXX_USE_
This is for google-main branch.
Fix compiler warnings in ThreadSanitizer tests.
Index: gcc/testsuite/ChangeLog.google-main
===
--- gcc/testsuite/ChangeLog.google-main (revision 182235)
+++ gcc/testsuite/ChangeLog.google-main (working
> Any update?
I will look into it today, but anyway I think it is stage1 material, so we have
some time to progress on it.
Honza
Hi,
On Mon, 12 Dec 2011, Kai Tietz wrote:
Index: gcc/libstdc++-v3/libsupc++/cxxabi.h
===
--- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h
+++ gcc/libstdc++-v3/libsupc++/cxxabi.h
@@ -51,6 +51,10 @@
#include
#include
+#ifndef _GLIBCXX
On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini wrote:
>> I think being able to detect a final class is good enough for now,
>> until we find out if there are real problems being encountered as
>> people make more use of C++11.
>
> Maybe. But in my opinion we should not rush. Something is wrong he
On Mon, Dec 12, 2011 at 08:43, Dmitriy Vyukov wrote:
> Fix flags for edges from/to entry/exit basic blocks.
> W/o this patch I hit internal asserts when trying to
> split the edge from entry block.
Please specify how you tested it
(http://gcc.gnu.org/contribute.html#testing). OK for trunk, if
te
Hello,
On Fri, 9 Dec 2011, Jakub Jelinek wrote:
> I had to tweak a little bit the expander conflict checking, because
> if we have a BB with two incoming EH edges and clobber stmts from both
> sunk into its beginning, then it would consider both variables (a and b
> above) to be live at the same
I have committed attached patch for
http://gcc.gnu.org/gcc-4.7/changes.html#fortran
Tobias
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.67
diff -u -p -r1.67 changes.html
---
On 12/11/11 16:51, Mike Stump wrote:
On Dec 9, 2011, at 11:45 AM, Aldy Hernandez wrote:
How about the patch below?
I'm fine with whatever you guys come up with...
Likewise. I have no preference. Whatever gets approved is ok with me.
Hi Richard,
Comments inline below..
On Sat, Dec 10, 2011 at 03:21:23PM -0800, Richard Henderson wrote:
> ---
> libitm/Makefile.am |3 +
> libitm/Makefile.in | 20 +++--
> libitm/config/arm/hwcap.cc | 67 +
> libitm/config/arm
> > I'm fine with whatever you guys come up with...
>
> Likewise. I have no preference. Whatever gets approved is ok with me.
So let's pick the Iain's proposal:
Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
===
--- gcc/testsui
2011/12/12 Paolo Carlini :
> Hi,
>
>> On Mon, 12 Dec 2011, Kai Tietz wrote:
>>
>>> Index: gcc/libstdc++-v3/libsupc++/cxxabi.h
>>> ===
>>> --- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h
>>> +++ gcc/libstdc++-v3/libsupc++/cxxabi.h
>>> @@ -
On 12 December 2011 12:42, Kai Tietz wrote:
>
> PR libstdc++/511135
> * libsupc++/cxxabi.h (__cxxabi_dtor_type): New type.
ChangeLog needs to be updated for the new type name (whether it ends
up being __cxa_dtor_type or something else).
Hi,
Ok. By looking at this, it might be better to use here a define - as
you mentioned. As I would need to copy here namespace too.
Ok, thanks. Let's make sure nothing can possibly change for != mingw, we
don't want to take risks at this time.
Paolo.
On Mon, Dec 12, 2011 at 04:20:57PM +0100, Dominique Dhumieres wrote:
> > > I'm fine with whatever you guys come up with...
> >
> > Likewise. I have no preference. Whatever gets approved is ok with me.
>
> So let's pick the Iain's proposal:
>
> Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
Hi,
On Fri, 9 Dec 2011, Georg-Johann Lay wrote:
> This is pretty much straight forward, and I don't understand the problems with
> - canonicalize stuff
> - optimize on canonicalized representation
> - lower canonicalized representation to best RTL
I don't think anyone would reject patches that d
On Mon, Dec 12, 2011 at 03:46:01PM +0100, Michael Matz wrote:
> > I had to tweak a little bit the expander conflict checking, because
> > if we have a BB with two incoming EH edges and clobber stmts from both
> > sunk into its beginning, then it would consider both variables (a and b
> > above) to
On 12 Dec 2011, at 15:47, Jakub Jelinek wrote:
On Mon, Dec 12, 2011 at 04:20:57PM +0100, Dominique Dhumieres wrote:
I'm fine with whatever you guys come up with...
Likewise. I have no preference. Whatever gets approved is ok
with me.
So let's pick the Iain's proposal:
Index: gcc/tests
Yes the testcase attached in the PR works for me but I can't change the
status because I am not the reporter (nor admin).
I will close it.
However, the testcase I have added g++.dg/tm/ctor-used.C fails. I can
fill another PR but I found this problem thanks to the PR testcase.
If you mean t
On Mon, Dec 12, 2011 at 04:18:29PM +, Iain Sandoe wrote:
> thus is everyone reasonably happy with?
>
> Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
> ===
> --- gcc/testsuite/c-c++-common/cxxbitfields-3.c (revision 1822
On 11-12-12 11:18 , dvyu...@google.com wrote:
I've done full 3 stage build for all front-ends, then 'make bootstrap',
then diff output of 'make check-gcc -j16 RUNTESTFLAGS="dg.exp"' with
non-modified version. Everything passed successfully. All that on
Linux/amd64.
OK, thanks. That's enough.
On 07/12/11 13:42, Richard Earnshaw wrote:
So it looks like the code generated for core registers with thumb2 is
pretty rubbish (no real surprise there -- to get the best code you need
to make use of the fact that on ARM a shift by a small negative number
(< -128) will give zero. This gives us
Hi,
On Mon, 12 Dec 2011, Jakub Jelinek wrote:
> Looks cleaner, yes.
> Just I wonder:
> 1) what if a bb contains no real insns (I know, they should be optimized
>out, but do we assert that etc.?) - then the EXECUTE_IF_SET_IN_BITMAP
>loop just wouldn't be done. Perhaps that is fine, it wou
On Mon, Dec 12, 2011 at 05:29:09PM +0100, Michael Matz wrote:
> On Mon, 12 Dec 2011, Jakub Jelinek wrote:
> > Just I wonder:
> > 1) what if a bb contains no real insns (I know, they should be optimized
> >out, but do we assert that etc.?) - then the EXECUTE_IF_SET_IN_BITMAP
> >loop just wou
Hi!
When idx is smaller than VEC_length (which happens when some pseudo
is set more than once in the tail call sequence), we should try to grow
the vector to smaller size than it has.
Bootstrapped/regtested on x86_64-linux and i686-linux, tested in arm cross
on the testcase mentioned in the PR wi
Hi!
On ARM because -fstrict-volatile-bitfields is on we get a warning about
volatile access to unaligned field, this patch adds -w to avoid failing
because of that warning. Regtested on x86_64-linux and i686-linux
and with arm cross on the given testcase, committed as obvious.
2011-12-12 Jakub
Richard,
I am hitting an assert in expand_vec_perm_even_odd on IA64 HP-UX with
your patch.
Using gcc.c-torture/compile/900116-1.c as a test case and compiling at
-O3 I get:
x.c: In function 'zloop':
x.c:3:1: internal compiler error: in expand_vec_perm_even_odd, at
config/ia64/ia64.c:11145
Please
Hi!
In gimple_fold_call (called from fold_stmt from replace_uses_by from cfg
cleanup) we weren't calling maybe_clean_or_replace_eh_stmt, so when
we've replaced a printf call (which can throw) with puts (which can throw
too), nothing would update EH stmts. It would be problematic calling
gimple_pu
ok for google/main.
David
http://codereview.appspot.com/5483046/
Hi,
On Mon, 12 Dec 2011, Jakub Jelinek wrote:
> Ok. So, I'm happy with your changes and rth already acked the tree-eh.c
> side, so can we just get an ack on these cfgexpand.c changes? Thanks.
Hmpf, I would have simply committed without a re-approval, but if you
think it's necessary I'll wait
Hi!
On
extern void baz (int);
template
void
f7 (int i, int x, int y)
{
#pragma omp parallel for
for (i = x - 10; i <= y + 10; i += N)
baz (i);
}
part of libgomp.c++/for-2.C testcase we now ICE, because the increment
expression contains IMPLICIT_CONV_EXPR. Fixed by also using
cp_parser_omp_
On 12/12/2011 09:03 AM, Michael Matz wrote:
> Hmpf, I would have simply committed without a re-approval, but if you
> think it's necessary I'll wait.
The revised patch is ok too.
r~
On 12/12/2011 11:19 AM, Aldy Hernandez wrote:
Yes the testcase attached in the PR works for me but I can't change the
status because I am not the reporter (nor admin).
I will close it.
Ok thanks.
However, the testcase I have added g++.dg/tm/ctor-used.C fails. I can
fill another PR but I f
> > This patch just removes/restructures some of the doxygen markup to
> > avoid warnings when generating the documentation. Most of the
> > libstdc++ headers are pretty doxygen clean now.
>
> By the way, I recently made this feature request for Doxygen:
>
> https://bugzilla.gnome.org/show_bug.c
This is not correct. First, _ITM_getTMCloneOrIrrevocable should never
appear in a __transaction_atomic (_ITM_getTMClone is ok).
But the problem here is that it fails to detect the clone because of the
alias. This is why we end up with a call to _ITM_getTMCloneOrIrrevocable.
Ah, I see.
Please
On 12/12/11 16:28, Andrew Stubbs wrote:
> On 07/12/11 13:42, Richard Earnshaw wrote:
>> So it looks like the code generated for core registers with thumb2 is
>> pretty rubbish (no real surprise there -- to get the best code you need
>> to make use of the fact that on ARM a shift by a small negative
Hi!
On this testcase we ICE starting from
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181188
because one of the basic blocks we add to bb_tail has EDGE_ABNORMAL
edge (computed goto) from a basic block that doesn't need prologue.
We try to duplicate the basic block and finally redirect that ED
On 12/12/2011 04:28 PM, Paolo Carlini wrote:
Hi,
Ok. By looking at this, it might be better to use here a define - as
you mentioned. As I would need to copy here namespace too.
Ok, thanks. Let's make sure nothing can possibly change for != mingw,
we don't want to take risks at this time.
For t
1 - 100 of 148 matches
Mail list logo
