--- Comment #78 from bonzini at gnu dot org 2009-05-08 06:51 ---
Subject: Bug 33928
Author: bonzini
Date: Fri May 8 06:51:12 2009
New Revision: 147270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147270
Log:
2009-05-08 Paolo Bonzini
PR rtl-optimization/33928
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-05-08 06:27 ---
Subject: Bug 37577
Author: tkoenig
Date: Fri May 8 06:27:37 2009
New Revision: 147269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147269
Log:
2009-05-08 Thomas Koenig
PR fortran/37577
--- Comment #2 from bje at gcc dot gnu dot org 2009-05-08 05:38 ---
I've been building cross-compilers for a long time and I have never heard that!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40065
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 05:22 ---
GCC can assume %qE means anything from just printing E in quotes (which is what
is happening here, it is assuming %qE does not take an argument). I don't see
an issue really except you really should be compiling a c
When GCC cannot recognise a format specifier, it produces spurious warnings.
For example:
gcc/coverage.c:364: warning: unknown conversion type character E in format
gcc/coverage.c:364: warning: format %qs expects type char *, but argument 3
has type tree
gcc/coverage.c:364: warning: too m
--- Comment #3 from janis at gcc dot gnu dot org 2009-05-07 22:34 ---
Subject: Bug 39037
Author: janis
Date: Thu May 7 22:34:08 2009
New Revision: 147259
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147259
Log:
gcc/
PR c/39037
* c-common.h (mark_valid_location
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-07 22:18 ---
And this has been fixed for 4.4.1. Really these inline-asm could be converted
into use of intrinsics.
*** This bug has been marked as a duplicate of 39543 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-05-07 22:18
---
*** Bug 40064 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
Opened: 2009-05-07 16:49 CEST
I reported this with mplayer's bugzilla
(http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1461)
and was told:
--- Comment #1 From Diego Biurrun 2009-05-07 22:40:22 CEST [reply]
---
These are gcc bugs, more so if it worked with previous gcc versions. Go repor
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2009-05-07 22:15
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2009-05-07 22:14
---
Subject: Bug 38830
Author: fxcoudert
Date: Thu May 7 22:14:23 2009
New Revision: 147258
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147258
Log:
PR fortran/38830
* gfortran.texi: Docume
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2009-05-07 22:03
---
We're left with the following:
../../../trunk/libgfortran/io/list_read.c: In function nml_read_obj:
../../../trunk/libgfortran/io/list_read.c:2464: warning: comparison between
bt and enum
../../../trunk/l
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-05-07 22:02
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-07 22:01
---
Subject: Bug 39576
Author: fxcoudert
Date: Thu May 7 22:01:34 2009
New Revision: 147257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147257
Log:
PR fortran/39576
* error.c (error_print)
--- Comment #32 from dominiq at lps dot ens dot fr 2009-05-07 22:00 ---
Presently invalid recursive I/Os are accepted by gfortran without any
diagnostic at run time. It could be helpful to implement such a diagnostic with
something such as -fcheck=recursive_IO.
Note that xlf gives a run
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-07 21:50
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-07 21:48
---
Subject: Bug 36382
Author: fxcoudert
Date: Thu May 7 21:48:14 2009
New Revision: 147256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147256
Log:
PR fortran/36382
* invoke.texi: Document
--- Comment #2 from janus at gcc dot gnu dot org 2009-05-07 21:44 ---
Here is a preliminary patch which correctly rejects the code in comment #0:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision
--- Comment #9 from janis at gcc dot gnu dot org 2009-05-07 21:43 ---
Subject: Bug 39986
Author: janis
Date: Thu May 7 21:43:32 2009
New Revision: 147255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147255
Log:
PR middle-end/39986
* dfp.c (encode_decimal32, de
--- Comment #18 from fxcoudert at gcc dot gnu dot org 2009-05-07 21:42
---
Subject: Bug 22423
Author: fxcoudert
Date: Thu May 7 21:42:22 2009
New Revision: 147254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147254
Log:
PR fortran/22423
* io/transfer.c (read
--- Comment #1 from paolo dot carlini at oracle dot com 2009-05-07 21:42
---
Attachment missing, Dave...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #8 from janis at gcc dot gnu dot org 2009-05-07 21:39 ---
Subject: Bug 39986
Author: janis
Date: Thu May 7 21:38:46 2009
New Revision: 147253
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147253
Log:
PR middle-end/39986
* dfp.c (encode_decimal32, de
--- Comment #9 from meissner at linux dot vnet dot ibm dot com 2009-05-07
21:33 ---
Created an attachment (id=17824)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17824&action=view)
Updated patch that fixes some internal compiler errors
I discovered in further testing, that vect_
--- Comment #8 from meissner at gcc dot gnu dot org 2009-05-07 21:19
---
Subject: Bug 40049
Author: meissner
Date: Thu May 7 21:18:54 2009
New Revision: 147252
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147252
Log:
Support vector rotates; Fix bug 40049 which caused runtime
Compile the enclosed with g++-4 fu.cpp -o /tmp/fu
--
Summary: Internal Compiler Error with -std=gnu++0x
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: una
--- Comment #5 from ubizjak at gmail dot com 2009-05-07 20:37 ---
(In reply to comment #0)
> I do not see any way to explicitly blacklist the opcode, and setting -march to
> i486, i386, or native does not avoid the problem.
>
> Could this be added as an architecture, or is there an exi
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2009-05-07 20:11
---
Another thing you might want to do is change libgfortran.h in your source to
replace this:
#if HAVE_COMPLEX_H
# include
#else
#define complex __complex__
#endif
with this:
# include
#undef complex
#define co
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2009-05-07 20:05
---
As long as we don't support IEEE arithmetic (with the intrinsic module),
getting IEEE results is not required by the standard. Making this an
enhancement, for later :)
--
fxcoudert at gcc dot gnu dot org chang
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-07 19:09 ---
Are you sure that an implicit copy constructor is not supposed to be created
here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39126
--- Comment #1 from gbrammer at gmx dot de 2009-05-07 19:05 ---
Still happens with "g++-4.4 (Debian 4.4.0-4) 4.4.1".
Here's a version with printfs in the destructor and constructors:
extern "C" { int printf(const char *format, ...); }
struct Foo {
Foo(Foo && from) { printf("move co
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-05-07 18:34
---
$> cat ice.f90
MODULE module_foo
TYPE :: foo_node
TYPE(foo_node_private), POINTER :: p
END TYPE
TYPE :: foo_node_private
TYPE(foo_node), DIMENSION(-1:1) :: link
END TYPE
TYPE :: foo
TYPE(foo
--- Comment #4 from sascha-web-gcc dot gnu dot org at silbe dot org
2009-05-07 18:00 ---
Seems like the relogin required because of NAT IP address change garbled the
text. Here it is again, hopefully properly formatted now:
This also affects (at least) the AMD Geode LX series of proce
--- Comment #15 from dfranke at gcc dot gnu dot org 2009-05-07 18:00
---
There's a new ICE with -fwhole-file that crept in since yesterday (20090505,
using the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html).
I'll try to get a reduced testcase.
--
dfranke at gcc dot g
--- Comment #3 from sascha-web-gcc dot gnu dot org at silbe dot org
2009-05-07 17:54 ---
This also affects (at least) the AMD Geode LX series of processors, used e.g.
in the OLPC XO-1 (i.e. a large number of computers). o...@debxo:~$ cat
/proc/cpuinfo processor : 0 vendor_id
--- Comment #77 from steven at gcc dot gnu dot org 2009-05-07 17:50 ---
Re. comment #75: Just the fact that an option is enabled in both releases
doesn't mean the pass behind it is doing the same thing in both releases. What
the scheduler does, depends heavily on the code you feed it. S
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-07 16:52 ---
Look for DEEP_BRANCH_PREDICTION in config/i386/*. On i386/i486/i586 doing
call 1f; 1:
is just fine, but on several newer CPUs it confuses return prediction logic
(more calls than rets), so when optimizing for those CP
--- Comment #76 from bonzini at gnu dot org 2009-05-07 16:37 ---
It should be possible to modify fwprop to avoid excessive memory usage (doing
its own dataflow, basically, instead of using UD chains)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #75 from lucier at math dot purdue dot edu 2009-05-07 16:31
---
Subject: Re: [4.3/4.4/4.5 Regression] 30% performance slowdown in
floating-point code caused by r118475
On May 7, 2009, at 12:21 PM, bonzini at gnu dot org wrote:
> --- Comment #74 from bonzini at gnu d
--- Comment #34 from f dot knauf at mmkf dot de 2009-05-07 16:30 ---
I can confirm the behaviour for sparc-sun-solaris2.8, the first program
mentioned in the last comment complains as follows:
***
mudflap violation 1 (check/write): time=1241712982.495997 ptr=ffbefac4 size=4
pc=ff288
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2009-05-07
16:30 ---
Subject: Re: [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using
Sun ld
hjl dot tools at gmail dot com writes:
> The difference is in how to get PC for -fPIC:
>
> bash-3.2$ cat p.c
> void
> fo
--- Comment #74 from bonzini at gnu dot org 2009-05-07 16:21 ---
Ok. One step at a time. :-) To recap, here is the situation:
- the CSE optimization you mention was *not* removed, it was moved to fwprop,
so it does not run at -O1.
- once this was done, the way to go is to tune new op
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-07 16:08 ---
Created an attachment (id=17823)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17823&action=view)
unincluded testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
Needs more than 2GB of ram at -O3.
--
Summary: [4.3/4.4/4.5 Regression] high memory usage and compile
time in SCEV cprop with -O3
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Keywords: memory-hog, compile-time-hog
--- Comment #73 from lucier at math dot purdue dot edu 2009-05-07 16:04
---
Created an attachment (id=17822)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17822&action=view)
time for 31957, with rename-registers no-move-loop-invariants forward-propagate
--
http://gcc.gnu.org/
--- Comment #72 from lucier at math dot purdue dot edu 2009-05-07 16:03
---
Created an attachment (id=17821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17821&action=view)
time for 31957, with rename-registers no-move-loop-invariants
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #71 from lucier at math dot purdue dot edu 2009-05-07 16:02
---
Created an attachment (id=17820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17820&action=view)
time for 31957, with rename-registers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #70 from lucier at math dot purdue dot edu 2009-05-07 16:00
---
Created an attachment (id=17819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17819&action=view)
time report related to comment 69, time for PR 31957 with no options
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #69 from lucier at math dot purdue dot edu 2009-05-07 15:57
---
Well, adding -frename-registers by itself to -O1 and not
-fforward-propagate and -fno-move-loop-invariants doesn't help (loop is given
below, along with complete compile options), the time is
140 ms
--- Comment #11 from rahul at icerasemi dot com 2009-05-07 15:57 ---
Confirmed issue resolved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40057
--- Comment #10 from jakub at gcc dot gnu dot org 2009-05-07 15:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jakub at gcc dot gnu dot org 2009-05-07 15:53 ---
Subject: Bug 40057
Author: jakub
Date: Thu May 7 15:53:11 2009
New Revision: 147245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147245
Log:
PR middle-end/40057
* dojump.c (prefer_and_bit_te
--- Comment #68 from steven at gcc dot gnu dot org 2009-05-07 15:40 ---
Be careful with -frename-registers, it is quadratic in the size of a basic
block. For Bradley's test cases it will certainly give a slow-down.
I have tried a rewrite of -frename-registers, but I keep running into tr
--- Comment #8 from jakub at gcc dot gnu dot org 2009-05-07 15:36 ---
Subject: Bug 40057
Author: jakub
Date: Thu May 7 15:36:23 2009
New Revision: 147242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147242
Log:
PR middle-end/40057
* dojump.c (prefer_and_bit_te
--- Comment #7 from jakub at gcc dot gnu dot org 2009-05-07 15:28 ---
Subject: Bug 40057
Author: jakub
Date: Thu May 7 15:27:40 2009
New Revision: 147241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147241
Log:
PR middle-end/40057
* dojump.c (prefer_and_bit_te
--- Comment #5 from matz at suse dot de 2009-05-07 15:13 ---
Subject: Re: [4.5 Regression] casts loose alignment
info
On Thu, 7 May 2009, rguenth at gcc dot gnu dot org wrote:
> And if something should look through conversions it is get_pointer_alignment
Yes, this is actually used i
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-07 15:06 ---
And if something should look through conversions it is get_pointer_alignment
which funnily has
/* We rely on TER to compute accurate alignment information. */
if (!(optimize && flag_tree_ter))
return 0;
eh
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-07 14:58 ---
This patch is correct.
Alternatively, you could define the dimension_number variable unconditionally
(remove #ifndef and #endif around it), initialize it to 0 and not initialize it
in for init expression. For MIPS_DEB
--- Comment #2 from burnus at gcc dot gnu dot org 2009-05-07 14:51 ---
Stupid but working fix: Reverting the patch for PR 39791 on MIPS_DEBUGGING_INFO
only. I think that's the safest to do - even if it is not the most elegant way
of doing it. I don't like backporting Rev. 137975 which wo
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-07 14:39 ---
Confirmed. I need to understand what MIPS_DEBUGGING_INFO means - and why it is
not present in 4.4 - but maybe reverting it and suggesting in PR fortran/39791
to use 4.4/4.5 is be safer/better alternative. - Thanks for
--- Comment #15 from jv244 at cam dot ac dot uk 2009-05-07 14:32 ---
(In reply to comment #13)
> Is there a self contained (one file) source that I could use?
have you had a chance to look into the issue / is there anything I can help
with ? I'd like to get this ready for -fwhole-file
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build
Known to work||4.3.3
--- Comment #3 from Fons dot Rademakers at cern dot ch 2009-05-07 13:55
---
Explicit template instantiation also works for us in this case. However, would
be nice to see this regression fixed. No blocker anymore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40056
--- Comment #67 from bonzini at gnu dot org 2009-05-07 13:40 ---
I'm thinking of enabling -frename-registers on x86; since it does not enable
the first scheduling pass, the live ranges will be shorter and the register
allocator may reuse the same register over and over with no freedom on
gmake[3]: Entering directory `/usr/ports/lang/gcc43/work/build/gcc'
gcc43 -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-stri
--- Comment #3 from matz at gcc dot gnu dot org 2009-05-07 13:28 ---
How alignment is dealt with in was explained by Joseph in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954#c10
A conversion sequence implicitely maintains the largest found alignment.
Looking through casts would not
--- Comment #7 from hjl dot tools at gmail dot com 2009-05-07 13:22 ---
Gcc 4.4.1 revision 147214 gave:
FAIL: gcc.dg/dfp/pr39986.c scan-assembler .long\t(-1572863965|-1308622825)\n
FAIL: gcc.dg/dfp/pr39986.c scan-assembler .long\t(-1572863965|-1308622825)\n
FAIL: gcc.dg/dfp/pr39986.c s
--- Comment #6 from jakub at gcc dot gnu dot org 2009-05-07 13:19 ---
Created an attachment (id=17818)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17818&action=view)
gcc44-pr40057.patch
Fix I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40057
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-07 13:15 ---
Actually a cast to a lower alignment is valid (to an bigger alignment is
questionable if the pointer is not already aligned).
And this is a regression from the 4.4 as these testcases passed. Really expand
should loo
--- Comment #6 from hjl dot tools at gmail dot com 2009-05-07 13:15 ---
Only the testcase was checked into 4.4 branch:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00163.html
The dfp.c change is missing on 4.4 branch.
--
hjl dot tools at gmail dot com changed:
What|Remo
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-07 13:02 ---
A bug in do_jump and prefer_and_bit_test. Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-07 12:56 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #16 from matz at gcc dot gnu dot org 2009-05-07 12:39 ---
I see that in your reports only
gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb. (-m32)
gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb. (-m32)
are left (and I myself also can't
These testcase on powerpc:
gcc.target/powerpc/405-dlmzb-strlen-1.c scan-assembler dlmzb. (-m32)
gcc.target/powerpc/440-dlmzb-strlen-1.c scan-assembler dlmzb. (-m32)
fail since expand from SSA. That's because TER can't work around a frontend
deficiency anymore. The code therein is:
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-07 12:25 ---
The implicit instantiation of function templates could be inlined at which
point, it does not need to be emitted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40056
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 11:39 ---
Can you try with a later compiler ? 4.2.x no longer exists. As long as your
headers were fine I don't see why this shouldn't have built.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 11:37 ---
Can you try with a later compiler which is in the release train now and get
back ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-07 11:33 ---
Indeed, I can reproduce with 32-bit HWI 20090414 4.4 branch, building now head
of 4.4 branch with 32-bit HWI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40057
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-07 11:29 ---
Can't reproduce with x86_64-linux 4.4.0 with -m32, perhaps a 32-bit HWI issue,
will check...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40057
Compiling this code with "g++-4.4 -O -Wall -g kk.cpp
-fdiagnostics-show-option"...
==
struct S
{
int a;
};
int main()
{
S s;
int i;
bool arr[1];
arr[s.a] =true; /*line 11: missed*/
arr[i] = true;
/* if (s.a)
return 1;
*/
return 0;
}
==
produces
kk.cpp
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-07 11:19 ---
Works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40057
--- Comment #1 from rahul at icerasemi dot com 2009-05-07 11:11 ---
Suspect tree-ter optimisation pass. Compiling with -O1 -fno-tree-ter produces
the right result. Using -fdump-tree-optimized shows SSA-Gimple to change from
shiftTest (const ulonglong var)
{
int D.1842;
:
if (var >>
struct Base {
Base();
int i;
char c;
};
template
struct actor : public BaseT {
actor(BaseT const& base);
char c;
};
template
actor::actor(BaseT const& base)
: BaseT(base) {}
actor
foo(const Base c)
{
return actor(c);
}
with -O2 we inline the constructor and get
actor foo(Base) D.20
The following code compiled with GCC 4.4 and -O1 produces a wrong result for
the SHIFT and AND operation. Bit 31 of the variable 'var' in fucntion shiftTest
computes to '1' instead of a '0'.
Compiling with -O0 however, produces the right result.
#include "stdio.h"
typedef unsigned long long ulo
--- Comment #1 from Fons dot Rademakers at cern dot ch 2009-05-07 10:01
---
Created an attachment (id=17817)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17817&action=view)
Source file (-E output) demonstrating the reported issue.
Btw, this bug shows up on MacOS X 10.5.6, Linux
The attached file TStreamerInfoReadBuffer.cxx fails to instantiate template
functions when compiled with -O2. With -O or -g things work as expected. This
is a regression that does not appear in <4.4.0.
Compile the attached file with:
g++ -O2 -m64 -c TStreamerInfoReadBuffer.cxx -o TStreamerInfoRe
The following code failed with the message (no options are given to the
compiler):
instance.cc: In function 'int main()':
instance.cc:30: error: no matching function for call to 'c_struct::c_struct(a0_type&)'
instance.cc:14: note: candidates are: c_struct::c_struct(const c_struct&)
--- Comment #1 from alexandre dot hamez at gmail dot com 2009-05-07 09:45
---
Created an attachment (id=17816)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17816&action=view)
Associated temporary file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40055
--- Comment #21 from paolo dot carlini at oracle dot com 2009-05-07 09:39
---
As agreed with Benjamin, please apply it to the branch too and close the PR in
two days or so. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-07 09:36 ---
Of course this only works if logicals are zero-extended.
We manage to fold
int foo(unsigned char b)
{
return b | 0xff;
}
but not
int bar(unsigned char b)
{
return b & (~0 << 8);
}
appearantly because the C F
--- Comment #20 from singler at gcc dot gnu dot org 2009-05-07 09:19
---
Fixed in mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-07 08:58 ---
C testcase:
int foo(_Bool b)
{
return b | 1;
}
int bar(_Bool b)
{
return b & -2;
}
should both be folded to return a constant but instead are never optimized,
not even at RTL level.
Due to C semantics we get
--- Comment #4 from ramana at gcc dot gnu dot org 2009-05-07 08:10 ---
*** Bug 40053 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 08:10 ---
*** This bug has been marked as a duplicate of 40031 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-07 08:07 ---
In the standard:
R602 variable is designator
or expr
C602 (R602) expr shall be a reference to a function that has a pointer
result."
Which can then be used in assignment sta
See section 6.2 in ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1729.pdf.
In principle functions which return a pointer work already (even with procedure
pointers). AFAICS, the only thing missing is using these functions as lvalue,
as in this example:
real, dimension(1:100), target :: array
real, po
--- Comment #9 from jakub at gcc dot gnu dot org 2009-05-07 07:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
Between revisions 146892 and 147052 libstdc++ build started failing on native
arm-linux-gnueabi (compile farm gcc50) :
/bin/sh ../libtool --tag CC --tag disable-shared --mode=compile
/home/guerby/build/./gcc/xgcc -B/home/guerby/build/./gcc/
-B/n/50/guerby/install-trunk-147052/armv5tel-unknown-linu
1 - 100 of 101 matches
Mail list logo
