--- Comment #1 from redi at gcc dot gnu dot org 2010-09-17 01:25 ---
The 'typename' should not be necessary, and 4.5 and 4.6 compile it without
problems
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45698
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 01:09 ---
patch posted.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-17 01:07 ---
testing patch.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-17 01:05 ---
OK, problem is that we both devirtualize and clone the destination function.
Then when producing clone, we run into:
cgraph_update_edges_for_call_stmt_node (struct cgraph_node *node,
--- Comment #2 from bredelin at ucla dot edu 2010-09-17 00:53 ---
Created an attachment (id=21815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21815&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
--- Comment #1 from bredelin at ucla dot edu 2010-09-17 00:52 ---
Created an attachment (id=21814)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21814&action=view)
The problem file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
-libstdcxx-time=yes --enable-plugin
--enable-gold --with-plugin-ld=ld.gold --with-tune=generic --disable-werror
--enable-checking=yes --program-suffix=-4.6
Thread model: posix
gcc version 4.6.0 20100916 (experimental) (GCC)
The version of 4.5 is:
$ g++-4.5 -v
Using built-in specs.
COLLECT_GCC=/usr/b
The first case works without any errors:
#include
template
class A {
};
template
class B : A > {
std::tuple t;
};
Now, altering the tuple to hold a struct derived from Types also works:
template
struct C_M { };
template
class C : A > {
std::tuple...> t;
};
However, declaring the s
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-17 00:32 ---
Fixed.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #7 from hubicka at gcc dot gnu dot org 2010-09-17 00:28 ---
Gold shipped with SLES:
GNU gold (GNU Binutils; SUSE Linux Enterprise 11 2.20.0.20100122-0.7.9) 1.
is known to have problems leading to PR45194
The following version: GNU gold (GNU Binutils 2.20.51.20100706) 1.9
wor
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-09-17 00:27 ---
Hmm, so actually it is really difference in gold.
System gold on evans is
GNU gold (GNU Binutils; SUSE Linux Enterprise 11 2.20.0.20100122-0.7.9) 1.
while one I use is
GNU gold (GNU Binutils 2.20.51.20100706) 1.9
yo
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-17 00:06 ---
(In reply to comment #2)
> I don't understand why the continuation character should be removed. For the C
> parser that character is not special (only for the C preprocessor it is), nor
> it confuses its line number
--- Comment #2 from John dot Tytgat at aaug dot net 2010-09-17 00:04
---
I don't understand why the continuation character should be removed. For the C
parser that character is not special (only for the C preprocessor it is), nor
it confuses its line number accountancy. Or am I mistake
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-16 23:55 ---
C preprocessor is not a generic preprocessor. The continuation character is
removed so the correct line number is used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
typedef unsigned char uint8_t;
void f(uint8_t __restrict__ foo[]) {
// no warnings/errors
}
void f2(unsigned char __restrict__ foo[]) {
// doesn't compile::
// test.cc:6: error: __restrict__ qualifiers cannot be applied to unsigned
char
}
The two functi
Using gcc 4.6.0 20100915 trunk revision 164317
Using the preprocessor on following piece:
--8<--
error_identifiers: \
kErr_AlreadyWaitingForGDB("Already waiting for a GDB to connect")
--8<--
gcc -E gives me:
--8<--
# 1 "test-preprocess.c"
# 1 ""
# 1 ""
# 1 "test-preprocess.c"
error-iden
--- Comment #3 from ekuznetsov at divxcorp dot com 2010-09-16 23:08 ---
Created an attachment (id=21813)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21813&action=view)
Output of gcc -v -O3 gcc-bug.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
--- Comment #49 from LpSolit at netscape dot net 2010-09-16 22:51 ---
(In reply to comment #48)
> The current bugzilla has
> extra separating lines with the column names. The new installation does not.
Yeah, it is so by design. Not something I'm going to reimplement.
Note that we fina
--- Comment #13 from t7 at gmail dot com 2010-09-16 22:33 ---
(In reply to comment #12)
> Can you try compiling it with
> --param ggc-min-expand=0 --param ggc-min-heapsize=0
> ? Perhaps you'll trigger it then more reliably...
>
Without it:
GGC heuristics: --param ggc-min-expand=30
--- Comment #12 from jakub at gcc dot gnu dot org 2010-09-16 22:28 ---
Can you try compiling it with
--param ggc-min-expand=0 --param ggc-min-heapsize=0
? Perhaps you'll trigger it then more reliably...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #11 from t7 at gmail dot com 2010-09-16 22:06 ---
But too bad this file 'gtype-desc.c' is automatically generated at build time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #10 from t7 at gmail dot com 2010-09-16 22:03 ---
Program received signal SIGSEGV, Segmentation fault.
gt_ggc_mx_cpp_macro (x_p=) at gtype-desc.c:2078
2078 ((*x).params[i0]) ? HT_IDENT_TO_GCC_IDENT (HT_NODE
(((*x).params[i0]))) : NULL;
(gdb) bt
#0 gt_ggc
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-09-16 22:00 ---
GC issues normally don't show at different times depending on the layout of
memory and such. Sometimes it depends on env variables being slightly
different.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, GC, ice-on-valid-code
Summary|Dangling reference ab
--- Comment #8 from t7 at gmail dot com 2010-09-16 21:58 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug.
>
This is very odd, becaus
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 21:57 ---
Caused by my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163555
change, so will look into it tomorrow.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21560&action=view
doesn't break it, only the version that tries
$ebx is left uninitialized for not-equal comparison.
Compilation flags: -O1
it passes = exit code 0 = with -O0
it fails = exit code 1 = with -O1
PASS: gcc (GCC) 4.4.5 20100916 (prerelease)
FAIL: gcc (GCC) 4.5.2 20100916 (prerelease)
PASS: gcc (GCC) 4.6.0 20100916 (experimental)
FAIL: gcc-4.5.1-3
--- Comment #26 from burnus at gcc dot gnu dot org 2010-09-16 21:30 ---
Subject: Bug 43665
Author: burnus
Date: Thu Sep 16 21:30:05 2010
New Revision: 164348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164348
Log:
2010-09-16 Tobias Burnus
PR fortran/43665
--- Comment #2 from pluto at agmk dot net 2010-09-16 21:02 ---
ha, my gcc was built with: export CXXFLAGS="-O2"; ./configure
--disable-shared..."
and this CXXFLAGS afaics affects libstdc++.a debuginfo level.
with CXXFLAGS="-O2 -g2" the python pretty printer works fine.
testcase compiled
--- Comment #1 from jpr at csc dot fi 2010-09-16 19:31 ---
Created an attachment (id=21812)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21812&action=view)
failing fortran code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45694
Hi,
(i first reported this to mingw32-w64's bug tracker:
http://sourceforge.net/tracker/?func=detail&aid=3067541&group_id=202880&atid=983354
and was forwarded here)
The attached fortran program aborts() (a host associated variable
changes value from host to hostee without asking) using
gfortran -O
Between 20100607 and 20100624, all Tru64 UNIX V5.1B EH tests started to fail,
e.g.
FAIL: g++.old-deja/g++.mike/eh33.C execution test
This testcase segfaults like this:
Program received signal SIGSEGV, Segmentation fault.
__cxa_call_unexpected (exc_obj_in=0x70)
at /vol/gcc/src/hg/trunk/local/
Since the test objc/execute/exceptions/throw-nil.m has been introduced at
revision 164024, it has failed on *-apple-darwin* with -m32, see
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00816.html
http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00835.html
--
Summary: FAIL: objc/ex
--- Comment #11 from dherring at tentpost dot com 2010-09-16 18:54 ---
FWIW, the example given in the C++ draft spec, section 9.5, fails to compile in
g++, even under version 4.5 with the -std=c++0x flag. (This example has been
there for a few years.)
Coupled with requirements such as
--- Comment #6 from ian at macky dot net 2010-09-16 17:44 ---
Subject: Re: Floating point comparison failure
Thanks everyone. I usually do fuzzy floating-point comparison, except in
certain special circumstances. I will switch to using double constants;
I'm trying for a code that is
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-09-16 17:36 ---
Hmm, the problem is that foo is virtual self recursive function.
We inline it and then indirect inlining decide that it can devirtualize the
self recursive call since it knows the operand has proper type.
At that tim
--- Comment #5 from spop at gcc dot gnu dot org 2010-09-16 17:21 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from spop at gcc dot gnu dot org 2010-09-16 17:19 ---
Subject: Bug 45680
Author: spop
Date: Thu Sep 16 17:19:25 2010
New Revision: 164345
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164345
Log:
Fix PR45680.
2010-09-16 Reza Yazdani
PR bootstrap/4568
--- Comment #5 from paolo dot carlini at oracle dot com 2010-09-16 17:15
---
Thanks Jakub.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-16 17:13 ---
i?86 is a FLT_EVAL_METHOD 2 target, so for strict C compliance all floating
operations and constants are supposed to be evaluated in the precision
of long double. The assignment of the constant to a double var or expl
--- Comment #138 from pinskia at gcc dot gnu dot org 2010-09-16 17:08
---
*** Bug 45691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-16 17:08 ---
*** This bug has been marked as a duplicate of 323 ***
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2010-09-16 17:08
---
As an even more general rule, remember to always specify your target: in this
case, for example, I can't reproduce at all the behavior on x86_64 -m64, only
with -m32.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #7 from manu at gcc dot gnu dot org 2010-09-16 17:04 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug.
>
I think this is cove
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 17:02 ---
pr323?
As a general rule: never compare floating points for equality, use
abs(a-b)http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45691
After upgrading to gcc 4.5.0 from 3.3.4, some of my floating point code fails.
Searched for and could not find a matching bug. It boils down to this very
simple example:
#include
#define MY_PI 3.14159265358979323846
int main()
{
double z = MY_PI;
puts(z == MY_PI ? "==" : "!=");
--- Comment #6 from ktietz at gcc dot gnu dot org 2010-09-16 16:56 ---
(In reply to comment #4)
> (In reply to comment #2)
> > http://gcc.gnu.org/bugs/#need
>
> Since this is a bug in the preprocessor it is hard to get a preprocessed
> source
> that causes a bug.
>
That's true. Inter
--- Comment #13 from rearnsha at gcc dot gnu dot org 2010-09-16 16:54
---
(In reply to comment #12)
> I think it's likely there really is a miscompilation. I've not been able to
> get very far trying to set up a native compiler to run on qemu, so it would
> help if you could try to nar
--- Comment #4 from ro at gcc dot gnu dot org 2010-09-16 16:43 ---
Fixed for 4.6.0.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
URL|
--- Comment #3 from ro at gcc dot gnu dot org 2010-09-16 16:37 ---
Subject: Bug 44763
Author: ro
Date: Thu Sep 16 16:37:01 2010
New Revision: 164341
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164341
Log:
Record PR middle-end/44763 in ChangeLog.
Modified:
trunk/gcc/Chang
--- Comment #17 from rguenther at suse dot de 2010-09-16 16:06 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, jamborm at gcc dot gnu dot org wrote:
>
>
> --- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-16 16:00
> ---
> (In reply to comment #15)
>
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-09-16 16:00
---
(In reply to comment #15)
> Like
>
> Index: gimplify.c
> ===
> --- gimplify.c (revision 164333)
> +++ gimplify.c (working copy)
> @@ -2477,10 +2477
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-09-16 14:55
---
Like
Index: gimplify.c
===
--- gimplify.c (revision 164333)
+++ gimplify.c (working copy)
@@ -2477,10 +2477,13 @@ gimplify_call_expr (tree *expr_p,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Keywords||wrong-code
--- Comment #21 from hjl dot tools at gmail dot com 2010-09-16 14:30
---
(In reply to comment #20)
> The patch in comment #4 makes memcpy folding not lie about alignment.
X86 only cares about alignment for vector modes.
Can we combine 2 patches into one?
> cfgexpand still lies about a
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-09-16 14:22
---
The patch in comment #4 makes memcpy folding not lie about alignment.
cfgexpand still lies about alignment though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #19 from hjl dot tools at gmail dot com 2010-09-16 14:17
---
(In reply to comment #17)
> That's true. But many expanders can make use of DECL_ALIGN information, e.g.
> to choose faster code. If cfgexpand keeps doing what it does now, namely
> bumping DECL_ALIGN of variable
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-16 14:13
---
(In reply to comment #16)
> (In reply to comment #13)
>
> > With that patch the assignment generated from memcpy doesn't need more
> > that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
> > decl to 1
--- Comment #17 from jakub at gcc dot gnu dot org 2010-09-16 14:08 ---
That's true. But many expanders can make use of DECL_ALIGN information, e.g.
to choose faster code. If cfgexpand keeps doing what it does now, namely
bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY ev
--- Comment #10 from pluto at agmk dot net 2010-09-16 14:04 ---
(In reply to comment #9)
> Are you sure you haven't modified your GCC sources?
i'm testing gcc-4.5 from svn branch, with gdb-7.2 and binutils-2.20.51.0.11.
filled as PR45690.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from pluto at agmk dot net 2010-09-16 14:01 ---
Created an attachment (id=21811)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21811&action=view)
source, makefile and precompiled binaries.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690
hi,
on the recent 4.5 branch i have a problems with dwarf4 and pretty printers.
here's steps to reproduce:
$ make
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++
t.cpp -gdwarf-3 -g2 -o t-dw3
/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/bin/x86_64-gnu-linux-g++
t.
--- Comment #16 from hjl dot tools at gmail dot com 2010-09-16 13:59
---
(In reply to comment #13)
> With that patch the assignment generated from memcpy doesn't need more
> that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
> decl to 128 so expand uses aligned instructio
--- Comment #15 from hjl dot tools at gmail dot com 2010-09-16 13:54
---
Created an attachment (id=21810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21810&action=view)
A patch
This patch adds HARD_ALIGNMENT_MODE_P and works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #14 from jakub at gcc dot gnu dot org 2010-09-16 13:54 ---
The reason why cfgexpand does increase the alignment is that it believes that
the base slot will be at least PREFERRED_STACK_BOUNDARY bytes aligned, which is
true on all targets but i?86/x86-64, which apparently somet
--- Comment #12 from bernds at gcc dot gnu dot org 2010-09-16 13:50 ---
(In reply to comment #6)
> So stage1 chooses adds but stage2 and stage3 choose lsls for << of the lower
> half of a long long. Since the behaviour of a stageN xgcc depends on both the
> gcc source code and the compi
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-16 13:39
---
(In reply to comment #12)
> (In reply to comment #4)
> > Created an attachment (id=21809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809&action=view) [edit]
> > patch to fix "half STRICT_ALIGNMENT" targe
--- Comment #12 from hjl dot tools at gmail dot com 2010-09-16 13:32
---
(In reply to comment #4)
> Created an attachment (id=21809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809&action=view) [edit]
> patch to fix "half STRICT_ALIGNMENT" targets memcpy folding
>
> Might nee
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-16 13:21
---
This code:
if (TREE_CODE (srcvar) == ADDR_EXPR
&& var_decl_component_p (TREE_OPERAND (srcvar, 0))
&& tree_int_cst_equal (TYPE_SIZE_UNIT (srctype), len)
&& (!STRICT_ALIGNMENT
--- Comment #10 from dominiq at lps dot ens dot fr 2010-09-16 13:14 ---
(1) The patch in comment #7 fixes this pr without regression.
(2) If I replace
type(t), dimension(1), parameter :: a1 = (/ t(1) /)
type(t), dimension(1), parameter :: a = reshape ( (/ a1 /), (/ 1 /) )
wi
--- Comment #7 from janus at gcc dot gnu dot org 2010-09-16 13:14 ---
Fixed with r164338. Closing.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-16 13:13 ---
Subject: Bug 45674
Author: janus
Date: Thu Sep 16 13:12:59 2010
New Revision: 164338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164338
Log:
2010-09-16 Janus Weil
PR fortran/45674
* inte
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-16 13:10
---
When __builtin_memcpy increases the alignment of source
or destination, it should update needed stack alignment if
source or destination is on stack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #3 from dominiq at lps dot ens dot fr 2010-09-16 13:09 ---
MAXLOC and MINLOC are also missing (see pr25104).
> They are not, as there, afaik, are no simplifiers yet.
>
> Hence, with your patch they will be accepted, but you'd end up with wrong code
> at the end, as the funct
--- Comment #9 from hjl dot tools at gmail dot com 2010-09-16 13:05 ---
If __builtin_memcpy generates instructions which
require bigger alignment than alignments of
source or destination, it should increase the
alignment of source or destination.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #20 from dominiq at lps dot ens dot fr 2010-09-16 13:03 ---
The test in comment #0 now gives (with/without -std=g95)
pr25104.f90:3.5:
CASE(MAXLOC(K,1))
1
Error: transformational intrinsic 'maxloc' at (1) is not permitted in an
initialization expression
for 4.4.4, 4.5.
--- Comment #8 from hjl dot tools at gmail dot com 2010-09-16 13:02 ---
This also failed:
---
typedef float V __attribute__ ((vector_size (16)));
V g;
float d[4] = { 4, 3, 2, 1 };
int
main ()
{
V e;
__builtin_memcpy (&e, &d, sizeof (d));
V f = { 5, 15, 25, 35 };
e = e * f;
g
--- Comment #14 from rguenther at suse dot de 2010-09-16 12:51 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, hubicka at ucw dot cz wrote:
> --- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 ---
> Subject: Re: Missed devirtualization
>
> > I'm lost
--- Comment #13 from hubicka at ucw dot cz 2010-09-16 12:48 ---
Subject: Re: Missed devirtualization
> I'm lost in this PR - for what testcase what statement needs folding
> (and what pending patches do I need to apply to see that)?
PR is tracking missed optimization in the testcase in
--- Comment #12 from rguenther at suse dot de 2010-09-16 12:31 ---
Subject: Re: Missed devirtualization
On Thu, 16 Sep 2010, hubicka at gcc dot gnu dot org wrote:
> --- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25
> ---
> Hmm, so do you have any idea wher
--- Comment #11 from hubicka at gcc dot gnu dot org 2010-09-16 12:25
---
Hmm, so do you have any idea where folding should be added for this particular
case?
It always seemed to me that it would make sense to add verifier that all
statements are folded (locally, not by looking at SSA g
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-16 12:10 ---
(In reply to comment #3)
> Thanks for the quick fix!
Well, it was *your* fix, so *I* should thank *you* :)
Anyway, I think the patch in comment #2 qualifies as obvious, and has no
regressions, as noted by Dominique.
--- Comment #6 from hubicka at gcc dot gnu dot org 2010-09-16 12:09 ---
PR 45679 also reproduce during -O3 build. I am testing patch for it now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-16 11:57 ---
For the ix86/x86_64 alignment issue, I believe the problem here is that
max_align = MAX (crtl->max_used_stack_slot_alignment,
PREFERRED_STACK_BOUNDARY);
is fine for !SUPPORTS_STACK_ALIGNMEN
--- Comment #11 from laurent at guerby dot net 2010-09-16 11:49 ---
With --with-arch=armv5te --with-tune=xscale I get the comparison failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyword
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-09-16 11:14 ---
They are not, as there, afaik, are no simplifiers yet.
Hence, with your patch they will be accepted, but you'd end up with wrong code
at the end, as the functions are not properly simplified and thus not constant.
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-09-16 11:07
---
Fixed for trunk sofar.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-09-16 11:06
---
Subject: Bug 45623
Author: rguenth
Date: Thu Sep 16 11:06:25 2010
New Revision: 164333
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164333
Log:
2010-09-16 Richard Guenther
PR tree-optimizatio
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 10:50 ---
Missing some else indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #1 from dominiq at lps dot ens dot fr 2010-09-16 10:42 ---
pasto!-(
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
Summary|CSHIFT an
While playing with modifications of PR4581, I tried
module m
implicit none
type t
integer :: i
end type t
type(t), dimension(2), parameter :: a1 = (/ t(1), t(2) /)
type(t), dimension(2), parameter :: d = cshift ( a1, 1 )
end module m
and got
pr45081_red.f90:7.43:
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-16 10:40 ---
Re: #c4, shouldn't there be srcvar = NULL_TREE; somewhere for the
STRICT_ALIGNMENT non-aligned case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #1 from dascandy at gmail dot com 2010-09-16 10:23 ---
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
The link where the typo is to be found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
> HP-UX system header files may use version level functioning for some system
> calls.
This is a very amusing (what I assume to be) typo in the documentation of
function-level versioning.
Not sure this is the right bug tracker but this is one that I know...
--
Summary: Typo in __a
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-16 10:18 ---
Created an attachment (id=21809)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809&action=view)
patch to fix "half STRICT_ALIGNMENT" targets memcpy folding
Might need this patch to fix as well. i?86 / x86_6
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-16 10:17 ---
DECL_ALIGN of d is set to 128 (but appearantly it isn't ensured it'll end up
that way). DECL_ALIGN is adjusted here:
Old value = 32
New value = 128
expand_one_stack_var_at (decl=0x75ae90a0, offset=-16)
at /
--- Comment #9 from paul dot richard dot thomas at gmail dot com
2010-09-16 09:43 ---
Subject: Re: [4.3/4.4/4.5/4.6 Regression] ICE in
gfc_conv_array_initializer, at fortran/trans-array.c:4208
Thanks! Paul
On Thu, Sep 16, 2010 at 9:06 AM, dominiq at lps dot ens dot fr
wrote:
>
>
>
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-16 09:35 ---
Subject: Bug 45686
Author: jakub
Date: Thu Sep 16 09:35:02 2010
New Revision: 164330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164330
Log:
PR bootstrap/45686
* fold-const.c (fold_checksum_
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 09:30 ---
With seeing .clone in fn names I suppose this is ipa-cp or ipa-sra.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
1 - 100 of 109 matches
Mail list logo
