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
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 {
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 ja...@redhat.com 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
Jonathan Wakely jwakely@gmail.com 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 jwakely@gmail.com 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 ebotca...@adacore.com 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
On Sun, Dec 11, 2011 at 6:03 PM, Steven Bosscher stevenb@gmail.com 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
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;
} sent
@@ -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 should be
On 12/10/2011 12:05 PM, Kai Tietz wrote:
2011-12-10 Kai Tietz kti...@redhat.com
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 jwakely@gmail.com writes:
On 12 December 2011 09:18, Andreas Schwab wrote:
Jonathan Wakely jwakely@gmail.com 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
On Mon, Dec 12, 2011 at 12:02, Janne Blomqvist
blomqvist.ja...@gmail.com 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
Richard Henderson r...@redhat.com 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
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
Here is a patch wich introduces new pass 'ree' based on pass
'implicit_zee' as was discussed above.
Thanks.
2011-11-22 Enkovich Ilya ilya.enkov...@intel.com
PR target/50038
* implicit-zee.c: Delete.
* ree.c: New file.
* Makefile.in: Replace implicit-zee.c with
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 much
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
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).
As
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 kti...@redhat.com
PR libstdc++/511135
* libsupc++/cxxabi.h
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
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.
As
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
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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
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 ging...@adacore.com
* mlib-tgt-specific-xi.adb: (Get_Target_Prefix): Simplify code.
Index:
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,
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).
As for
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
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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
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 cel...@adacore.com
* prj-nmsc.adb (Get_Directories): For a non
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:
2011/12/12 Kai Tietz ktiet...@googlemail.com:
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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
On 12 December 2011 11:29, Kai Tietz ktiet...@googlemail.com wrote:
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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
On 12 December 2011 10:08, Andreas Schwab wrote:
Jonathan Wakely jwakely@gmail.com writes:
On 12 December 2011 09:18, Andreas Schwab wrote:
Jonathan Wakely jwakely@gmail.com writes:
On 11 December 2011 22:22, Fabien Chêne wrote:
Consequently, I propose to deprecate them with a
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
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 message
Any update?
On 5 December 2011 15:14, Michael Zolotukhin
michael.v.zolotuk...@gmail.com 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.
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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
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 mira...@adacore.com
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 how
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:
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 michael.v.zolotuk...@gmail.com 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
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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,
On Mon, Dec 12, 2011 at 02:16:04PM +0200, Ira Rosen wrote:
Michael Zolotukhin michael.v.zolotuk...@gmail.com 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
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 paolo.carl...@oracle.com:
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
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 era...@google.com 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 Ramanera...@google.com 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
On Mon, Dec 12, 2011 at 08:17, Paolo Carlini paolo.carl...@oracle.com wrote:
On 12/12/2011 02:14 PM, Diego Novillo wrote:
On Sun, Dec 11, 2011 at 19:05, Easwaran Ramanera...@google.com wrote:
Bootstraps and no test regressions. OK for google/gcc-4_6 branch?
Any reason not to put this in
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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
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
On Mon, Dec 12, 2011 at 12:40 PM, Eric Botcazou ebotca...@adacore.com 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
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 d...@adacore.com
*
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 bits/cxxabi_tweaks.h
#include
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 bits/cxxabi_tweaks.h
On Mon, Dec 12, 2011 at 5:25 AM, Paolo Carlini paolo.carl...@oracle.com 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.
On Mon, Dec 12, 2011 at 08:43, Dmitriy Vyukov dvyu...@google.com 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
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 +
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
===
---
2011/12/12 Paolo Carlini paolo.carl...@oracle.com:
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 do
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:
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
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 182219)
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 would
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 wouldn't be
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
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
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
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 long N
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
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
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:
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=gccview=revrev=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
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
On Mon, 12 Dec 2011, Paolo Carlini wrote:
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
OK.
Jason
1 - 100 of 143 matches
Mail list logo
