Ian Lance Taylor wrote:
Write a one-line shell script to use as your compiler (that's what I
would do), or define an environment variable which tells gcc which
plugins to load (e.g., GCC_PLUGINS=/a/file:/another/file).
Thanks for the input.
The one-liner shell script is a very good
Basile STARYNKEVITCH wrote:
But what about the trunk, which uses tuples?
I know nothing about the tuples and the trunk and whether tuples might
affect the way plugins work. Maybe others can comment...
To be honest i was more worried about how plugins will work with the
garbage collector and
* Brendon Costa wrote on Fri, Sep 19, 2008 at 02:42:19AM CEST:
What platforms do we want to support? I can think of the following
categories:
* Windows (cygwin/mingw)
As i understand the issue (I am not very familiar with this) you can't
have unresolved references in a plugin back to the GCC
Hello,
On C structures, for attributes like const, it is enough to consider
that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
I mean:
volatile struct { unsigned char a,b,c,d; } volstruct;
void
Etienne Lorrain wrote:
On C structures, for attributes like const, it is enough to consider
that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
An object that has volatile-qualified type may
On C structures, for attributes like const, it is enough to
consider that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
An object that has volatile-qualified type may be
modified in
Etienne Lorrain wrote:
On C structures, for attributes like const, it is enough to
consider that each field inherit the attribute of the structure.
But for the volatile attribute, is it valid to treat each field as
volatile like GCC does it now?
An object that has volatile-qualified type may
I have created a new branch, alias-improvements, which will host work
to transition us to a leaner virtual-operand representation and to
fix the fallout in the optimizers.
The branch is maintained by me, patches should be marked with [alias].
Thanks,
Richard.
Hi Ho!
On Tue, 9/16/08, Ian Lance Taylor [EMAIL PROTECTED] wrote:
HOST-x-TARGET == cross-compiler
native-HOST == native compiler
BUILD-build native-HOST == native compiler built by cross-compiler
BUILD-build HOST-x-TARGET == cross-compiler built by cross-compiler
The BUILD-build system is
Ralf Wildenhues wrote:
* Windows (cygwin/mingw)
As i understand the issue (I am not very familiar with this) you can't
have unresolved references in a plugin back to the GCC executable. I.e.
Building GCC with -rdynamic will not work on this platform. Do we move
most of the GCC
On Fri, Sep 19, 2008 at 15:30, Brian Dessent [EMAIL PROTECTED] wrote:
Ralf Wildenhues wrote:
Is it really that far fetched to have the plugin not directly access
anything from the executable's symbol table but instead be passed a
structure that contains a defined set of interfaces and
Hello All,
(a meta question: do we need to reply-to all, or should the gcc@ list be
enough to discuss plugins, and the only destination of this interesting
discussion?).
Brendon Costa wrote:
Basile STARYNKEVITCH wrote:
But what about the trunk, which uses tuples?
I know nothing about the
There is a very simple function:
/ func.c **/
#include netinet/in.h
uint16_t my_htons(uint16_t hostshort)
{
return htons(hostshort);
}
/**/
$ cc func.c -Wconversion -Werror -c -o func.o
Exit 0
$ cc func.c -O1 -Wconversion -Werror -c -o func.o
On Fri, Sep 19, 2008 at 5:03 PM, Andriy Gapon [EMAIL PROTECTED] wrote:
There is a very simple function:
/ func.c **/
#include netinet/in.h
uint16_t my_htons(uint16_t hostshort)
{
return htons(hostshort);
}
/**/
$ cc func.c -Wconversion
void f(int x)
{
char c = x ? '|' : '/';
}
$ cc1: warnings being treated as errors
char.c: In function 'f':
char.c:3: error: conversion to 'char' from 'int' may alter its value
Exit 1
If I replace 'x' with a constant (0 or 1) in the condition, then the
code compiles.
I think gcc
Brian Dessent [EMAIL PROTECTED] writes:
Is it really that far fetched to have the plugin not directly access
anything from the executable's symbol table but instead be passed a
structure that contains a defined set of interfaces and callbacks?
Yes, that is pretty far fetched. Simply writing
Basile STARYNKEVITCH wrote:
(a meta question: do we need to reply-to all, or should the gcc@ list be
enough to discuss plugins, and the only destination of this interesting
discussion?).
Reply-to-all is the common standard on the list. If you don't want a
personal copy then set the Reply-to:
2008/9/19 Richard Guenther [EMAIL PROTECTED]:
The computation __x) 8) 0xff) | (((__x) 0xff) 8)) is promoted
to int as of C language standards rules and the store to __v truncates it.
The warning isn't clever enough to see that this doesn't happen due to
the masking applied, and in
2008/9/19 Andriy Gapon [EMAIL PROTECTED]:
If I replace 'x' with a constant (0 or 1) in the condition, then the code
compiles.
I think gcc should be smarter here.
This should be fixed in any recent GCC 4.4. snapshot. But I cannot
test it myself to be sure, if someone would be so kind to check
When we instantiate char_type_node in tree.c:build_common_tree_nodes
we very explicitly create a char_type_node that is signed or unsigned
based on the value of -funsigned-char, but instead of make
char_type_node point to signed_char_type_node or
unsigned_char_type_node, we explicitly instantiate
Ben == Ben Elliston [EMAIL PROTECTED] writes:
Ben Do you think that the current order of .exps should be preserved
Ben in the resultant .sum and .logs?
I personally don't have a use for this.
I just think that the order ought to be stable across checks of the
same build.
Tom
Yes char, unsigned char and signed char are three distant types.
Unlike the other interger types in C/C++. That is they are
incompatable types.
Thanks,
Andrew Pinski
Sent from my iPhone
On Sep 19, 2008, at 9:36 AM, Diego Novillo [EMAIL PROTECTED]
wrote:
When we instantiate
On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo wrote:
When we instantiate char_type_node in tree.c:build_common_tree_nodes
we very explicitly create a char_type_node that is signed or unsigned
based on the value of -funsigned-char, but instead of make
char_type_node point to
On Fri, Sep 19, 2008 at 12:55, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Fri, Sep 19, 2008 at 12:36:12PM -0400, Diego Novillo wrote:
When we instantiate char_type_node in tree.c:build_common_tree_nodes
we very explicitly create a char_type_node that is signed or unsigned
based on the value of
Brian Dessent wrote:
Basile STARYNKEVITCH wrote:
I'm not sure that pre-compiled headers (pch) should even work with
plugins. The reasonable solution is to disable them when any plugin is
used [...]
There's already an existing requirement that the compiler options used
when precompiling the
On Fri, 19 Sep 2008, Brendon Costa wrote:
1) Dont allow additional search paths for plugins
I think we do want to allow the user to specify such a path on the
compiler command line, in addition to searching the standard libsubdir or
libexecsubdir location.
3) Somehow embed something in all
Brendon Costa wrote:
Joseph S. Myers wrote:
I think this is a bad idea on grounds of predictability.
I can understand this view and was initially reluctant to suggest the
auto-load feature for this same reason. However i can not see another
solution that can be used instead of this to
Taras wrote:
However, I do think it's awesome to be able to store plugin results in
the resulting binary to do LTO-style analyses. How well is that working
for you?
I would be delighted if that would be easily possible, but I remember
having asked at some LTO related session or meeting if
Brendon Costa wrote:
* Automatically loaded plugins as well as explicit user requested plugins
I would like to propose that we allow automatic loading of certain
plugins in addition to the explicit request for loading of plugins using
the -fplugin=name command line option.
I think we agree
On Fri, Sep 19, 2008 at 13:16, Basile STARYNKEVITCH
[EMAIL PROTECTED] wrote:
I would be delighted if that would be easily possible, but I remember having
asked at some LTO related session or meeting if LTO can be extended to add
some additional data, and the answer was we don't want to do
I think 'make -j' is the way to go, since it lets the user easily
control the amount of parallelism.
As I said before, make -j is a complete non-starter for me, as it restricts
the paralelism to a single machine and thus would actually reduce the
parallelism from what I have now with multilibs.
On Fri, 19 Sep 2008, Manuel López-Ibáñez wrote:
This should be fixed in any recent GCC 4.4. snapshot. But I cannot
test it myself to be sure, if someone would be so kind to check this
for me, I would appreciate it.
Confirmed on i386-unknown-freebsd6.3 using soures as of 20 hours ago.
Gerald
Hello all,
I am looking for a boiled down version of the ia64/32 instruction set
which I could extract instruction/flag dependencies from. As a last
resort I will use the Intel Software Developer PDFs. Based on my
understanding, the ia64.md and i386.md don't exactly give this information.
Basile STARYNKEVITCH [EMAIL PROTECTED] writes:
I am much more worried about passes and plugins (and I am very
surprised to be almost the only one mentioning passes in plugin
discussions). I feel it is a major issue (not a matter of coding, much
more a matter of convention understanding). So
On Fri, 2008-09-19 at 18:32 +0100, Joern Rennecke wrote:
I think 'make -j' is the way to go, since it lets the user easily
control the amount of parallelism.
As I said before, make -j is a complete non-starter for me, as it restricts
the paralelism to a single machine and thus would
m32c-elf-gcc -mcpu=m32c (16 bit ints, 24 bit pointers) miscompiles
this:
int *foo (int *a, int b)
{
return a-b;
}
as this:
_foo:
enter #0 ; 30prologue_enter_24
pushm r1,r3,a0; 31pushm
; end of prologue ; 32prologue_end
Sorry to nitpick, but there is nothing Mozilla-specific in
dehydra/treehydra. There are users outside of Mozilla.
Sorry, i didn't realise this.
However, I do think it's awesome to be able to store plugin results in
the resulting binary to do LTO-style analyses. How well is that working
for
On Mon, Sep 15, 2008 at 2:54 PM, Peng Yu [EMAIL PROTECTED] wrote:
Hi,
I have the following program. When I step in to test's constructor, I
would be able to print the variable three. It says
(gdb) n
7 T three = 3;
(gdb) n
8 std::cout three std::endl;
(gdb) p
On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote:
Basile STARYNKEVITCH [EMAIL PROTECTED] writes:
I am much more worried about passes and plugins (and I am very
surprised to be almost the only one mentioning passes in plugin
discussions). I feel it is a major issue (not a matter of coding,
Hi,
following invalid code compiles w/o error with gfortran 4.4.0
program test
real, pointer :: a(:), b(:)
a(:) = b(:)
end program test
works as expected with earliear versions.
$ gfortran -v
Using built-in specs.
Target: i586-pc-linux-gnu
Configured with:
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-09-19 06:22
---
The infinite loop in ipa-reference is solved now. Is the sixtrack problem
remaining and if so, would be possible to test the proposed patch?
We probably could track it as independent PR and close this one.
Honza
The following shows a problem on the Alpha whereby
the division 2/3 made on floats is flagged as exact.
Here are the details:
$ cat sf.cc
#include fenv.h
#include cstdio
int main() {
float x = 2;
float y = 3;
feclearexcept(FE_INEXACT);
x = x / y;
printf(%d %.1000g\n,
--- Comment #1 from bagnara at cs dot unipr dot it 2008-09-19 07:04 ---
Created an attachment (id=16359)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16359action=view)
Assembly code generated with g++ -S -mieee-with-inexact sf.cc
--
gcc is complaining about an ambiguous overloading of operator
in the statement (last non-trivial line)
return std::pow(a,2.0);
where no such operator appears. (I haven't seen a macro definition of 'pow'
which pulls in '')
If I replace the statement above by
return ::pow(a,2.0);
the
--- Comment #1 from jarausch at igpm dot rwth-aachen dot de 2008-09-19
07:33 ---
Created an attachment (id=16360)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16360action=view)
preprocessed failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
--- Comment #2 from jarausch at igpm dot rwth-aachen dot de 2008-09-19
07:35 ---
gcc -v -save-temps -c TEST3.C
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
Reported by Arjen Markus.
http://gcc.gnu.org/ml/fortran/2008-09/msg00327.html
The following program causes an ICE (insert_bbt(): Duplicate key found!) when
compiled with gfortran 4.1 to 4.4.
a) The unmodified program seems to be invalid as NAG f95 and ifort show:
Error: ENTRY point GLOCAL is
--- Comment #14 from uros at gcc dot gnu dot org 2008-09-19 08:02 ---
Subject: Bug 37544
Author: uros
Date: Fri Sep 19 08:01:07 2008
New Revision: 140484
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140484
Log:
PR rtl-optimization/37544
* regrename.c
--- Comment #1 from jpr at csc dot fi 2008-09-19 08:20 ---
Small update: this bug is already present in 4.3.1.
The 4.2.x series seems OK.
Juha
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-19 08:36 ---
Indeed ;) Honza, mention this PR in the changelog please.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2008-09-19 09:00 ---
Hah! I never did like ENTRY in Modules:-(
Changing the actual argument reference to 'glocal' to appear after the ENTRY,
by use of a GOTO, allows the horror below to run correctly.
Thus, in the reporter's version,
--- Comment #3 from sam at gcc dot gnu dot org 2008-09-19 09:05 ---
Could you try a more recent GCC version and check whether the bug is still
present or not? It compiles fine with GCC 4.3.1 on x86_64/Debian GNU/Linux.
--
sam at gcc dot gnu dot org changed:
What
--- Comment #2 from jpr at csc dot fi 2008-09-19 09:25 ---
This invalid peace of code gives an ICE:
program test
integer, pointer :: a(:),b(:)
a(1) = b(1)
end program test
gfortran -c test.f90
test.f90: In function 'test':
test.f90:3: internal compiler error: in gimplify_expr, at
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-19 09:34 ---
Shorter testcase:
#include cmath
class super_real {
public:
super_real (double);
};
bool operator (int i, const super_real a);
double square(double a) {
return std::pow(a,2.0);
}
--
rguenth at gcc
--- Comment #15 from uros at gcc dot gnu dot org 2008-09-19 10:06 ---
Subject: Bug 37544
Author: uros
Date: Fri Sep 19 10:04:46 2008
New Revision: 140487
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140487
Log:
PR rtl-optimization/37544
* regrename.c
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-19 10:12 ---
program test
real, pointer :: a(:), b(:)
a(:) = b(:)
end program test
That program is invalid.
R735 pointer-assignment-stmt
is data-pointer-object [ (bounds-spec-list) ] = data-target
or
--- Comment #16 from ubizjak at gmail dot com 2008-09-19 11:11 ---
Fixed everywhere.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
Unfortunately there is no simple testcase for this,
but compiling mplayer I get a lot of crashes related to
stack corruption
i.e. a function allocates in the stack 8 bytes
and later gdb says that it cannot access to a byte that instead is bound
I've tested with --stack-size on the linker but
--- Comment #4 from singler at gcc dot gnu dot org 2008-09-19 11:38 ---
Subject: Bug 37470
Author: singler
Date: Fri Sep 19 11:37:16 2008
New Revision: 140490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140490
Log:
2008-09-19 Johannes Singler [EMAIL PROTECTED]
PR
--- Comment #5 from singler at gcc dot gnu dot org 2008-09-19 11:44 ---
Fixed.
--
singler at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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 #37 from b0ntrict0r at yandex dot ru 2008-09-19 12:22 ---
Created an attachment (id=16361)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361action=view)
Updated patch
Could someone test updated patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
On trunk at Thu Sep 18 22:45:12 UTC 2008 (revision 140476)
$ gnatchop ../trunk/gcc/testsuite/ada/acats/support/rep*
$ gnatchop ../trunk/gcc/testsuite/ada/acats/tests/c6/c650001.a
$ gnatmake -gnat95 -f -O1 c650001.adb
...
gnatlink c650001.ali
./c650001.o: In function `_ada_c650001':
--- Comment #4 from bitti at iki dot fi 2008-09-19 12:12 ---
(In reply to comment #3)
Similar to Bug 15764.
I ran again into this bug in gcc 4.3.2. Any idea when there's time to fix it?
Matti Rintala
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
--- Comment #4 from jdecs at mssblue dot net 2008-09-19 13:03 ---
(In reply to comment #3)
Could you try a more recent GCC version
I can try. The last time I tried to find updates to GCC, GIT, and GNAT, there
were dependency problems on 64 bit systems.
I have also been in touch with
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-19 13:17
---
It's a fallout of the recent changes to the inlining machinery.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from b0ntrict0r at yandex dot ru 2008-09-19 13:18 ---
(In reply to comment #0)
This keyword seems to be Microsoft specific, right?
--
b0ntrict0r at yandex dot ru changed:
What|Removed |Added
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-19 13:18
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from amacleod at redhat dot com 2008-09-19 13:27 ---
Created an attachment (id=16362)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16362action=view)
patch to fix the bug
Looking a little closer, Im going to change Honza's patch a little. Since the
checks are no
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-19 13:33 ---
Created an attachment (id=16363)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16363action=view)
Fix for both aspects of PR
The bit in decl.c fixes the duplicate key business and that in resolve.c flags
up the
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-19 13:58 ---
The problem is const_vector_from_tree called on:
vector_cst 0x73375e10
type vector_type 0x733ed540 __vector signed int
type integer_type 0x7332d540 int sizes-gimplified public SI
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-19 14:12 ---
vect_get_vec_def_for_operand has:
tree vectype = STMT_VINFO_VECTYPE (stmt_vinfo);
int nunits = TYPE_VECTOR_SUBPARTS (vectype);
...
/* Case 1: operand is a constant. */
case vect_constant_def:
...
--- Comment #3 from anhvofrcaus at gmail dot com 2008-09-19 14:23 ---
On the second attempt to build gcc-4.4-20080912 using the latest binutils along
with gmp-4.2.2 and mpfr-2.3.2, this problem goes away. In summary, GNAT works
fines now.
Additional note: c, ada, and c++ languages are
Hi,
I have tried various OpenMP examples on the web and got them all to work fine.
When I tried to parallelize some software that is part of a larger project, I
have had a problem; OpenMP reports only one processor available and so I get
only 1 thread. More details follow.
I am running on an dual
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-19 14:43 ---
I tried setting the environment variable OMP_NUM_THREADS to 2 and got 2
threads, but only one processor was running the job.
this suggests your operating system is limiting your job to one CPU.
--
rguenth at
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-09-19 15:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-09-19 15:06
---
Subject: Bug 36343
Author: rguenth
Date: Fri Sep 19 15:04:36 2008
New Revision: 140492
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140492
Log:
2008-09-19 Richard Guenther [EMAIL PROTECTED]
PR
gfortran -v
GNU Fortran (GCC) 4.4.0 20080919 (experimental)
[~/tmp]$gfortran test.f90 -floop-block -O2
test.f90: In function 'main':
test.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html
--- Comment #4 from anhvofrcaus at gmail dot com 2008-09-19 15:24 ---
/home/voax/linux/build-4.4.0/./prev-gcc/xgcc
-B/home/voax/linux/build-4.4.0/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-19 16:00 ---
This regression is caused by compare/branch fuse optimization.
Gcc 4.3 is OK. Turn it off fixes it.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-19 16:01 ---
Caused by http://gcc.gnu.org/viewcvs?view=revrevision=140415
C++ FE has a weird habit of sticking error_mark_node in DECL_INITIAL, in this
case in finalize_nrv_r:
if (DECL_INITIAL (dp-var)
model: posix
gcc version 4.4.0 20080919 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic'
/usr/local/gnutest/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 gen-type-bound.f03
-quiet -dumpbase gen-type-bound.f03 -mtune=generic -auxbase gen-type-bound
-version -fintrinsic-modules-path
/usr
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-19 16:39 ---
Created an attachment (id=16364)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16364action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
The following failures
FAIL: objc.dg/stubify-1.m (test for excess errors)
ERROR: objc.dg/stubify-1.m: error executing dg-final: couldn't open
stubify-1.s: no such file or directory
FAIL: objc.dg/stubify-2.m (test for excess errors)
FAIL: objc.dg/stubify-2.m scan-rtl-dump-not jump
--- Comment #2 from rrpeter at sandia dot gov 2008-09-19 16:59 ---
Subject: Re: OpenMP thinks that I have 1 processor
on an 8 processor pc
rguenth at gcc dot gnu dot org wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-19 14:43
---
I tried setting the
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-19 17:02 ---
Self-contained testcase, which will work even for non-ascii compatible
exec-charset:
/* PR tree-optimization/37573 */
struct S
{
unsigned int *a;
unsigned int b;
unsigned int c[624];
};
static unsigned char
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 17:37 ---
FWIW -- on trunk, debug_str is controlled by -fmerge-debug-strings,
which is enabled by default (on supporting platforms).
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from amacleod at redhat dot com 2008-09-19 17:38 ---
Subject: Bug 37567
Author: amacleod
Date: Fri Sep 19 17:37:13 2008
New Revision: 140494
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140494
Log:
PR middle-end/37567
* tree-ssa-ter.c
--- Comment #3 from tromey at gcc dot gnu dot org 2008-09-19 17:42 ---
I'm closing this.
It is fixed on mainline and is not apparently a regression.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-19 17:52 ---
The data dependence on the previous loop is clearly not considered, the loop is
vectorized as if c on the rhs and c on the lhs were different non-overlapping
arrays.
--
Consider this code:
#include string
std::string s;
I compiled this with -g and examined the resulting dwarf.
's' is represented as:
124e8: Abbrev Number: 63 (DW_TAG_variable)
24e9 DW_AT_name: s
24eb DW_AT_decl_file : 1
24ec DW_AT_decl_line : 3
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-19 18:03 ---
(In reply to comment #1)
Root cause is that instruction length of fused jcc is set to 16, which prevent
the block from merging and copying. For some reason Core2 runs poorly with a
unmerged branch block under
Sent from my iPhone
On Sep 19, 2008, at 10:58 AM, tromey at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
Consider this code:
#include string
std::string s;
I compiled this with -g and examined the resulting dwarf.
's' is represented as:
124e8: Abbrev Number: 63 (DW_TAG_variable)
24e9
--- Comment #1 from pinskia at gmail dot com 2008-09-19 18:11 ---
Subject: Re: New: g++ should emit different debug info for variable's type
Sent from my iPhone
On Sep 19, 2008, at 10:58 AM, tromey at gcc dot gnu dot org
[EMAIL PROTECTED]
wrote:
Consider this code:
#include
In a case such as this, GCC ought to be able to prove that the signed variable
is positive and therefore suppress signed and unsigned warnings. I see this
in both C and C++.
#define MAX(a,b) ((a) (b) ? (a) : (b))
#define MIN(a,b) ((a) (b) ? (a) : (b))
unsigned int
constrain(unsigned int
--- Comment #2 from jason at redhat dot com 2008-09-19 18:14 ---
Subject: Re: [4.4 regression] ICE returning
a struct
jakub at gcc dot gnu dot org wrote:
IMHO either we relax the checking, allowing DECL_INITIAL to be error_mark_node
even for !TREE_STATIC, or finalize_nrv_r would
--- Comment #5 from janis at gcc dot gnu dot org 2008-09-19 18:24 ---
The operand of a postincrement and friends must be a modifiable lvalue. The
type check code for both C and C++ calls get_unwidened, which removes the cast
when it's a different size but leaves the cast when it's the
--- Comment #7 from dominiq at lps dot ens dot fr 2008-09-19 18:32 ---
Although I know this is not the right way to fix pr34310 I have done the
following change to /usr/include/objc/Protocol.h:
--- /usr/include/objc/Protocol.h-orig 2008-09-19 17:16:42.0 +0200
+++
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 18:59 ---
Consider this code:
#include string
std::string zardoz1;
using std::string;
string zardoz2;
In this case, IMO, 'whatis' should print 'std::string' for zardoz1,
but just 'string' for zardoz2.
This is simply not
1 - 100 of 140 matches
Mail list logo
