Re: codegen differences for increment of a volatile int
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, May 04, 2006 at 02:45:50PM -0700, Gary Funck wrote:
> Beginning with this simple example,
>
> 1 int j;
> 2 volatile int jv;
> 3 void p()
> 4 {
> 5++j;
> 6++jv;
> 7 }
>
> when compiled with "gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)"
> the following code results:
>
> inclj
> movljv, %eax
> incl%eax
> movl%eax, jv
[...]
> Is there a technical reason that the use of "volatile" would
> dictate the second form of increment that first loads the
> value from memory into a register? I would think that a
> systems programmer might expect the opposite behavior, where
> "volatile" would imply the single instruction form of increment
> (which is non-interruptible on single processor systems).
Systems programmers should know better than to expect a particular
implementation of volatile. :)
How, for example, would you suggest GCC generate code for this?
volatile int qwerty;
void p()
{
printf("qwerty = %d\n", ++qwerty);
}
You could get a (uniprocessor non-interruptible) single-instruction
incl qwerty
but then you'd have to read the value again to be able to print it:
movl %eax, qwerty
at which point you've lost your "one evaluation is one read cycle"
semantics which some people might find even more important than
(uniprocessor!) atomicity.
Don't forget that if you really wanted SMP-safe modification of
volatiles you'd have to use the "lock" prefix too.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/
iD8DBQFEWwO1wyMv24BBd/gRAjZ8AKCj86xSMkLzuAGuE5uJPOxsaJqVSQCfdbPx
/1Q+TLqzUE/p2vltjqOtk8I=
=2Bcj
-END PGP SIGNATURE-
Re: [PATCH] Strange ACATS fails in acats.log
> In the same vein as my 20050418 patch, may be the following will help. > Tested on x86_64-linux. Looks reasonable to me. Of course it would be nice if the underlying bug were fixed at some point, but that's another issue. > 2005-05-15 Laurent GUERBY <[EMAIL PROTECTED]> > > * ada/acats/run_all.sh: Use sync when main not found.
Re: Toolchain relocation
Daniel Jacobowitz wrote:
On Sat, Apr 15, 2006 at 09:46:24AM +0100, Dave Murphy wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Here's another attempt at a patch which fixes the problem for me,
including the translation of the include paths. I'm still not sure this
is correct
set_std_prefix is called quite early on and sets the root of the
installed toolchain. Since update_path checks for a match against
std_prefix before translating the paths translation only happens on
paths that don't actually require it. Checking against the configured
prefix instead fixes this problem for the gcc executable. The check of
standard_exec_prefix/just_machine_suffix/specs uses the hard coded
standard_exec_prefix causes another access to the old location. Using
the translated gcc_exec_prefix fixes this.
cc1 and cc1plus never call set_std_prefix so their calls to update_path
are not aware that the toolchain has been moved. I noticed that gcc sets
GCC_EXEC_PREFIX to a string which it later uses in the call to
set_std_prefix. Moving the putenv from gcc.c to set_std_prefix in
prefix.c and adding a call to set_std_prefix in toplev.c with the string
from GCC_EXEC_PREFIX fixes this.
Updating and using GCC_EXEC_PREFIX like this feels like the wrong thing
to do though. Would it be better to use another name for this purpose,
STD_PREFIX for example?
I've also been looking for a PR in bugzilla but can't seem to find one
for this issue. Could someone point me in the right direction if there
is one?
Dave
diff -Naurb gcc-4.1.0/gcc/gcc.c gcc-4.1.0-arm/gcc/gcc.c
--- gcc-4.1.0/gcc/gcc.c Sat Jan 21 18:29:08 2006
+++ gcc-4.1.0-arm/gcc/gcc.c Fri May 5 10:18:31 2006
@@ -3250,8 +3250,6 @@
gcc_libexec_prefix = make_relative_prefix (argv[0],
standard_bindir_prefix,
standard_libexec_prefix);
- if (gcc_exec_prefix)
- putenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL));
}
else
gcc_libexec_prefix = make_relative_prefix (gcc_exec_prefix,
@@ -6148,10 +6146,10 @@
/* We need to check standard_exec_prefix/just_machine_suffix/specs
for any override of as, ld and libraries. */
- specs_file = alloca (strlen (standard_exec_prefix)
+ specs_file = alloca (strlen (gcc_exec_prefix)
+ strlen (just_machine_suffix) + sizeof ("specs"));
- strcpy (specs_file, standard_exec_prefix);
+ strcpy (specs_file, gcc_exec_prefix);
strcat (specs_file, just_machine_suffix);
strcat (specs_file, "specs");
if (access (specs_file, R_OK) == 0)
diff -Naurb gcc-4.1.0/gcc/prefix.c gcc-4.1.0-arm/gcc/prefix.c
--- gcc-4.1.0/gcc/prefix.c Sat Jun 25 03:02:01 2005
+++ gcc-4.1.0-arm/gcc/prefix.c Fri May 5 10:18:51 2006
@@ -246,13 +246,16 @@
The returned string is always malloc-ed, and the caller is
responsible for freeing it. */
+
+static const char *old_prefix = PREFIX;
+
char *
update_path (const char *path, const char *key)
{
char *result, *p;
- const int len = strlen (std_prefix);
+ const int len = strlen (old_prefix);
- if (! strncmp (path, std_prefix, len)
+ if (! strncmp (path, old_prefix, len)
&& (IS_DIR_SEPARATOR(path[len])
|| path[len] == '\0')
&& key != 0)
@@ -354,4 +357,6 @@
set_std_prefix (const char *prefix, int len)
{
std_prefix = save_string (prefix, len);
+
+ putenv (concat ("GCC_EXEC_PREFIX=", std_prefix, NULL));
}
diff -Naurb gcc-4.1.0/gcc/toplev.c gcc-4.1.0-arm/gcc/toplev.c
--- gcc-4.1.0/gcc/toplev.c Sat Feb 4 22:13:20 2006
+++ gcc-4.1.0-arm/gcc/toplev.c Wed Apr 26 16:49:36 2006
@@ -82,6 +82,7 @@
#include "value-prof.h"
#include "alloc-pool.h"
#include "tree-mudflap.h"
+#include "prefix.h"
#if defined (DWARF2_UNWIND_INFO) || defined (DWARF2_DEBUGGING_INFO)
#include "dwarf2out.h"
@@ -1434,6 +1435,10 @@
progname = p;
xmalloc_set_program_name (progname);
+
+ p = getenv("GCC_EXEC_PREFIX");
+ set_std_prefix (p, strlen(p));
+
hex_init ();
GCC 4.0.1 compilation errors
Hi GCC_HELP, We recently started porting a C++ project from gcc-3.2.1 to gcc-4.0.1. We initially ran into several problems. The code that compiled easily with gcc-3.2.1 would not compile with gcc-4.0.1. Later we found that code compiled till gcc-3.3.6 version, but since the gcc-3.4.0 version the code wouldn't compile. The major errors are with template, name lookup but there are also certain errors with finding definitions from header files which are included and are in include path. Can you please point some links where these issues are discussed and any documents where these issues are explained and we can easily resolve these compilation errors. Any help wud be appreciated. Thanks and regards, _Nik
gfortran testsuite regression, gfortran.dg/entry_3.f90
Hi all, The following regression appeared between 20060504 and 20060505 on i686-linux. It is filed as PR 27443,and appears to be a consequence of a new optimization pass introduced by revision 113518. FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer -funroll-loops FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gfortran.fortran-torture/execute/entry_3.f90 compilation, -O3 -g Regards, FX
[off topic] fallow code removal
Hi everyone, My apologies for posting off topic. I'm desperate. One of my project's general on-going tasks is to eliminate dead code. Sort of following the Extreme Programming principle. Does anyone know of any tool that can help identify fallow routines? Can GCC itself help facilitate finding fallow routines that would be candidates for removal? Note: there are hundreds of SSO's and DSO's involved, all written in C or C++. Which makes finding fallow routines that much more difficult. Any suggestions, pointers or recommendations for tools, tips and/or techniques would be appreciated. The "intimate knowledge of your code base" works in the small, but fails in the large. Doesn't scale. Sincerely, --Eljay
doh
Sorry, I didn¹t mean to cross post my off-topic post to this forum. I meant it to go to gcc-help only. Mea culpa, --Eljay
Documentation of vector intrinsics / SSE2
Hi, I'm trying to learn about GCC's support for vector arithmetic and found the section "Using vector instructions through built-in functions", which answers a lot of questions, but unfortunately does not address things like gathering scalar values into a vector type or reading scalars out of such a variable, which I think is quite important for everyone who wants to use this nice extension. More X86-specific, the section "X86 Built-in Functions" documents builtins for MMX, 3DNow, SSE, SSE3, but appears to omit the vector intrinsics for SSE2 like, e.g., __builtin_ia32_sqrtpd(). I would volunteer to expand the documentation in these two places if an insider could point me to a place where I can find the necessary information. Cheers, Martin
RE: codegen differences for increment of a volatile int
> From: Bernd Jendrissek
> Sent: Friday, May 05, 2006 12:50 AM
[...]
> Systems programmers should know better than to expect a particular
> implementation of volatile. :)
>
> How, for example, would you suggest GCC generate code for this?
>
> volatile int qwerty;
>
> void p()
> {
> printf("qwerty = %d\n", ++qwerty);
> }
>
> You could get a (uniprocessor non-interruptible) single-instruction
> incl qwerty
> but then you'd have to read the value again to be able to print it:
> movl %eax, qwerty
> at which point you've lost your "one evaluation is one read cycle"
> semantics which some people might find even more important than
> (uniprocessor!) atomicity.
>
> Don't forget that if you really wanted SMP-safe modification of
> volatiles you'd have to use the "lock" prefix too.
All good points, and I agree. I just mentioned this idea, because
GCC is choosing the single instruction memory to memory form in
some situations, and I was surprised that it chose this form in
the non-volatile case, because it made more sense to me to prefer
it in the volatile case - if it were to prefer it all in one
situation over another.
The current GCC main branch compiler offers a new rendition
of the generated code at -O2:
movljv, %eax
addl$1, j
addl$1, %eax
movl%eax, jv
where, when incrmenting the non-volatile 'j', it chosses 'addl'
over 'incl'.
Re: Status of SEE and Autovectorization patches?
> That certainly does suggest a bug in the SEE patches. They needn't do > anything useful on IA32/AMD64, but they should presumably either (a) not > cause a bootstrap failure on these architectures, or (b) be disabled on > these architectures. Agree. I will check the bootstrapping on x86. (a) seems preferable but if not feasible in a short time frame, it will be (b). Mircea
create_tmp_var_raw (gimplify.c) inadventently asserts 'volatile' on temps
While following GCC's handling of 'volatile' and other type
qualifiers, I noticed that the gimplify pass created temporaries
with a type with 'volatile' asserted if the underlying type also
had 'volatile' asserted.
Temporaries are created by the create_tmp_var_raw() procedure
in gimplify.c, which reads as follows:
tree
create_tmp_var_raw (tree type, const char *prefix)
{
tree tmp_var;
tree new_type;
/* Make the type of the variable writable. */
new_type = build_type_variant (type, 0, 0);
TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type);
tmp_var = build_decl (VAR_DECL, prefix ? create_tmp_var_name (prefix) :
NULL,
type);
[...]
Note above that an unqualified type, new_type, is created but
then subsequently not used in the call to build_decl. Because of
this omission, if 'type' originally had any qualifiers set
(such as volatile), they'll be propagated to the temporary, which
might have some unexpected effects on subsequent optimizations
and code generation.
The fix, I think, is to pass 'new_type':
Index: gimplify.c
===
--- gimplify.c (revision 113552)
+++ gimplify.c (working copy)
@@ -449,7 +449,7 @@
TYPE_ATTRIBUTES (new_type) = TYPE_ATTRIBUTES (type);
tmp_var = build_decl (VAR_DECL, prefix ? create_tmp_var_name (prefix) :
NULL,
- type);
+ new_type);
/* The variable was declared by the compiler. */
DECL_ARTIFICIAL (tmp_var) = 1;
(If this analysis is correct and it is recommended that I file a
bug report on this, or post a patch, please let me know.)
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
On Fri, May 05, 2006 at 01:05:55PM +0200, Fran?ois-Xavier Coudert wrote: > Hi all, > > The following regression appeared between 20060504 and 20060505 on > i686-linux. It is filed as PR 27443,and appears to be a consequence of > a new optimization pass introduced by revision 113518. > It is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 H.J.
Re: Status of SEE and Autovectorization patches?
On 5/5/06, Mircea Namolaru <[EMAIL PROTECTED]> wrote: > That certainly does suggest a bug in the SEE patches. They needn't do > anything useful on IA32/AMD64, but they should presumably either (a) not > cause a bootstrap failure on these architectures, or (b) be disabled on > these architectures. Agree. I will check the bootstrapping on x86. (a) seems preferable but if not feasible in a short time frame, it will be (b). It looks like there are SEE related ICEs for SPEC CPU2000 on x86_64 at least. One of them looks like /gcc/spec/sb-vangelis-head-64/x86_64/install-200605042254/bin/gcc -c -o check_route.o -DSPEC_CPU2000 -O3 check_route.c check_route.c: In function 'pin_and_chan_adjacent': check_route.c:527: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Program received signal SIGSEGV, Segmentation fault. 0x0082c839 in hash_descriptor_pre_extension (p=Variable "p" is not available. ) at /gcc/spec/sb-vangelis-head-64/gcc/gcc/see.c:837 837 rtx set = single_set (extension->se_insn); (sorry, no debug info available here) Richard.
Re: Status of SEE and Autovectorization patches?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mircea Namolaru wrote:
>> That certainly does suggest a bug in the SEE patches. They needn't do
>> anything useful on IA32/AMD64, but they should presumably either (a) not
>> cause a bootstrap failure on these architectures, or (b) be disabled on
>> these architectures.
>
> Agree. I will check the bootstrapping on x86. (a) seems preferable but
> if not feasible in a short time frame, it will be (b).
FWIW, while normal bootstrap completes successfully for me
(c,c++,java on i686-pc-linux-gnu), I get a few failures in the
libjava testsuite due to the new SEE code.
The $GCC_SIR_DIR/libjava/testsuite/libjava.lang/TLtest.java
testcase fails to compile at -O3 and results in an ICE for
me:
- -- 8< --
(gdb) r
Starting program: /home/ranmath/src/gcc/build/gcc/jc1 TLtest.java -fhash-synchro
nization -fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-
inline-functions -quiet -dumpbase TLtest.java -march=pentium4 -auxbase TLtest -O
3 -I/home/ranmath/src/gcc/build/i686-pc-linux-gnu/libjava/libgcj-4.2.0.jar -o /t
mp/cc6b7oji.s
Program received signal SIGSEGV, Segmentation fault.
0x083bc4d0 in hash_descriptor_pre_extension (p=0xbfffcea8)
at /home/ranmath/src/gcc/gcc/gcc/see.c:837
837 rtx set = single_set (extension->se_insn);
(gdb) l
832
833 static hashval_t
834 hash_descriptor_pre_extension (const void *p)
835 {
836 const struct see_pre_extension_expr *extension = p;
837 rtx set = single_set (extension->se_insn);
838 rtx rhs = NULL;
839
840 gcc_assert (set);
841 rhs = SET_SRC (set);
(gdb) p p
$1 = (const void *) 0xbfffcea8
(gdb) p ((struct see_pre_extension_expr *)p)->se_insn
$2 = (rtx) 0x0
(gdb) bt
#0 0x083bc4d0 in hash_descriptor_pre_extension (p=0xbfffcea8)
at /home/ranmath/src/gcc/gcc/gcc/see.c:837
#1 0x083f2e87 in htab_find_slot (htab=0x8542888, element=0xbfffcea8,
insert=INSERT) at /home/ranmath/src/gcc/gcc/libiberty/hashtab.c:657
#2 0x083bcff5 in see_seek_pre_extension_expr (extension=0x0,
type=DEF_EXTENSION) at /home/ranmath/src/gcc/gcc/gcc/see.c:1036
#3 0x083bd0eb in see_set_prop_unmerged_def (slot=0x85ad39c, b=0x85ad2f8)
at /home/ranmath/src/gcc/gcc/gcc/see.c:2280
#4 0x083f25d6 in htab_traverse_noresize (htab=0x85ad318,
callback=0x83bd05a , info=0x85ad2f8)
at /home/ranmath/src/gcc/gcc/libiberty/hashtab.c:729
#5 0x083bcf21 in see_handle_extensions_for_one_ref (stn=0x858b778, data=0x0)
at /home/ranmath/src/gcc/gcc/gcc/see.c:2986
#6 0x083f3660 in splay_tree_foreach_helper (sp=0x85ad2d8, node=0x858b778,
fn=0x83bcd70 , data=0x0)
at /home/ranmath/src/gcc/gcc/libiberty/splay-tree.c:218
#7 0x083bf3b0 in see_main () at /home/ranmath/src/gcc/gcc/gcc/see.c:3021
#8 0x083bfac4 in rest_of_handle_see ()
at /home/ranmath/src/gcc/gcc/gcc/see.c:3754
#9 0x082b4b14 in execute_one_pass (pass=0x849e2e0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:864
#10 0x082b4c44 in execute_pass_list (pass=0x849e2e0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:911
- ---Type to continue, or q to quit---
#11 0x082b4c57 in execute_pass_list (pass=0x849c2a0)
at /home/ranmath/src/gcc/gcc/gcc/passes.c:912
#12 0x080972e5 in tree_rest_of_compilation (fndecl=0xb73e5900)
at /home/ranmath/src/gcc/gcc/gcc/tree-optimize.c:418
#13 0x082f1032 in cgraph_expand_function (node=0xb745d080)
at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:1102
#14 0x082f256d in cgraph_assemble_pending_functions ()
at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:354
#15 0x082f222a in cgraph_finalize_function (decl=0xb73e5900, nested=0 '\0')
at /home/ranmath/src/gcc/gcc/gcc/cgraphunit.c:480
#16 0x08070bd1 in finish_method (fndecl=0xb73e5900)
at /home/ranmath/src/gcc/gcc/gcc/java/decl.c:2147
#17 0x08063468 in java_expand_classes () at parse.y:7678
#18 0x08089b37 in java_parse_file (set_yydebug=0)
at /home/ranmath/src/gcc/gcc/gcc/java/jcf-parse.c:1316
#19 0x08299f05 in toplev_main (argc=17, argv=0xbfffd2a4)
at /home/ranmath/src/gcc/gcc/gcc/toplev.c:999
#20 0x08094a6b in main (argc=Cannot access memory at address 0xc
) at /home/ranmath/src/gcc/gcc/gcc/main.c:35
- -- 8< --
HTH,
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://rmathew.com/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEW08MYb1hx2wRS48RApLUAJwIwhtQPemm8Hmb4m6e+Gb5chfP6wCfZplB
QPbZbn9L/h25E26XDGuXffs=
=9iHh
-END PGP SIGNATURE-
Re: Status of SEE and Autovectorization patches?
On Thu, May 04, 2006 at 01:18:37PM -0700, Mark Mitchell wrote: > H. J. Lu wrote: > > > export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 > > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" > > # /configure > > # make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 > > -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" > > > > to configure and build gcc on Linux/x86 and Linux/x86-64. > > That certainly does suggest a bug in the SEE patches. They needn't do > anything useful on IA32/AMD64, but they should presumably either (a) not > cause a bootstrap failure on these architectures, or (b) be disabled on > these architectures. > FWIW, I am for SEE. But I think it can only be turned on with -O3 in a backend. If we want to turn it on with -O3 for all targets, we should 1. Use -fsee on gcc itself first: # export BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" # /configure # make BOOT_CFLAGS="-g -O2 -fsee" CXXFLAGS="-g -O2 -fsee" FCFLAGS="-g -O2 -fsee" GCJFLAGS="-g -O2 -fsee" SYSROOT_CFLAGS_FOR_TARGET="-g -O2 -fsee" to make sure that there are no serious problems with SEE. 2. We have demonstrated that SEE helps on most major platforms. H.J.
Re: Status of SEE and Autovectorization patches?
Hi Mircea, On Fri, 5 May 2006, Mircea Namolaru wrote: > > That certainly does suggest a bug in the SEE patches. They needn't do > > anything useful on IA32/AMD64, but they should presumably either (a) not > > cause a bootstrap failure on these architectures, or (b) be disabled on > > these architectures. > > Agree. I will check the bootstrapping on x86. (a) seems preferable but > if not feasible in a short time frame, it will be (b). Given that this is more than a bootstrap problem with non-default flags, but testsuite regressions for gfortran and SPEC failures on a primary platform, I think this falls under GCC's 48 hour rule. This simply formalizes your phrase "short time frame" above, and means that it you're unlikely to come up with a solution to these problems in the next day or two, that you/we should simply disable -fsee from being turned on by default at -O3. I appreciate your efforts to actually correct the defficiencies in SEE, which is indeed preferable, but for regression breakage in stage3, its often better to simply band-aid the problem as quickly as possible, even if you're close to a fix, as a courtesy to other developers. Roger --
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 Humpf. Does that mean that the patch wasn't regtested before being applied? FX
'volatile' is propagated into constants and expression nodes (in some cases)?
Given,
1 volatile int jv;
2
3 int main ()
4 {
5++jv;
6 }
GCC (development branch, 4.0 and up) creates a tree
node for the expression ++jv that has 'volatile' asserted
in the type associated with the expression:
unit size
align 32 symtab 0 alias set -1 precision 32 min max >
side-effects
arg 0
side-effects volatile used public static common SI defer-output file
a.c line 1 size unit size
align 32>
arg 1
constant invariant 1>>
Further, 'volatile' is asserted in the type associated with the
integral constant 1, above:
(gdb) pt
constant
invariant 1>
(gdb) p 0x402f2e04
$19 = 1076833796
(gdb) pt
constant invariant 32>
unit size constant invariant 4>
align 32 symtab 0 alias set -1 precision 32 min max >
We could argue whether this causes any real harm, because the ISO C
spec. says the following:
===
6.7.3:
The properties associated with qualified types are meaningful only for
expressions that are lvalues.
6.5.16:
The type of an assignment expression is the type of the left operand unless
the left operand has qualified type, in which case it is the unqualified
version of the type of the left operand.
And hopefully subsequent passes in the compiler won't be confused
by seeing qualifiers asserted in expression nodes and in constants.
IMO it would be better if the original tree constructed from
the parsed program more closely followed the original source code,
and where possible, removed extraneous qualifiers, unless they
absolutely needed to convey correct semantics.
Above, the qualifiers on expression nodes and constants seem to come
about by a call to convert() from build_unary_op()which works its way
through to this statement in fold_convert():
if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig)
|| lang_hooks.types_compatible_p (TYPE_MAIN_VARIANT (type),
TYPE_MAIN_VARIANT (orig)))
return fold_build1 (NOP_EXPR, type, arg);
because the main variant types of the qualified "volatile int" and
unqualified "int" are the same, convert() ends up recasting 'arg'
into a qualified (volatile int) type.
I don't know if there are other cases besides pre-/post-
increment that have this problem. I think it is
also possible that the code in the development head branch
does a better job of generating expression nodes that have
their qualifiers stripped than 4.0 did for example.
Perhaps one way to gain some confidence that all possibilities
have been covered is to add assertions in build_binary_op
and build_unary_op (or build1 and build2 for that matter,
for expression class nodes) that checks that
TYPE_QUALS(t) == TYPE_UNQUALIFIED on expression nodes and
constant nodes (though perhaps TYPE_CONST is meaninful for
certain named constants?).
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
On May 5, 2006, at 7:26 AM, François-Xavier Coudert wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 Humpf. Does that mean that the patch wasn't regtested before being applied? No, it was regression tested, just not on x86-linux-gnu like most people is doing. -- Pinski
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
On 5/5/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: On May 5, 2006, at 7:26 AM, François-Xavier Coudert wrote: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 > > Humpf. Does that mean that the patch wasn't regtested before being > applied? No, it was regression tested, just not on x86-linux-gnu like most people is doing. I'm surprised, then, that on whatever target it was tested it passed because of the NEXT_INSN/PREV_INSN bug that HJ mentions in the PR. IMHO the patch should be reverted until it is fixed and tested properly... Gr. Steven
Re: gfortran testsuite regression, gfortran.dg/entry_3.f90
On Fri, May 05, 2006 at 05:28:14PM +0200, Steven Bosscher wrote: > On 5/5/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > >On May 5, 2006, at 7:26 AM, François-Xavier Coudert wrote: > > > >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437 > >> > >> Humpf. Does that mean that the patch wasn't regtested before being > >> applied? > > > >No, it was regression tested, just not on x86-linux-gnu like most > >people is > >doing. > > I'm surprised, then, that on whatever target it was tested it passed > because of the NEXT_INSN/PREV_INSN bug that HJ mentions in the PR. > > IMHO the patch should be reverted until it is fixed and tested properly... I would suggest this patch. H.J. 2006-05-05 H.J. Lu <[EMAIL PROTECTED]> * opts.c (decode_options): Don't turn on SEE for -O3. --- gcc/opts.c.see 2006-05-04 10:59:02.0 -0700 +++ gcc/opts.c 2006-05-05 08:54:22.0 -0700 @@ -510,7 +510,6 @@ decode_options (unsigned int argc, const flag_inline_functions = 1; flag_unswitch_loops = 1; flag_gcse_after_reload = 1; - flag_see = 1; } if (optimize < 2 || optimize_size)
Re: [off topic] fallow code removal
Any suggestions, pointers or recommendations for tools, tips and/or techniques would be appreciated. A couple of different ways come to mind: a) there's the binutils -ffunction-sections -Wl,-gc-sections approach where every function is put into it's own section and the total is then garbage collected by the linker with extra sections that aren't referenced are then deleted. b) the mechanism the mach-o linker uses which is similar, but since - ffunction-sections may overrun the maximum allowed number of sections, everything is divided on label boundaries and split into "atoms". Any atom not in the direct call graph or without a relocation is then deleted in the final linked image. -eric
gcc-4.1-20060505 is now available
Snapshot gcc-4.1-20060505 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060505/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 113561 You'll find: gcc-4.1-20060505.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060505.tar.bz2 C front end and core compiler gcc-ada-4.1-20060505.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060505.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060505.tar.bz2 C++ front end and runtime gcc-java-4.1-20060505.tar.bz2 Java front end and runtime gcc-objc-4.1-20060505.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060505.tar.bz2The GCC testsuite Diffs from 4.1-20060428 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [off topic] fallow code removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, May 05, 2006 at 06:20:19AM -0500, John Love-Jensen wrote: > One of my project's general on-going tasks is to eliminate dead code. > Sort of following the Extreme Programming principle. If you're doing XP then you also have a test suite that covers all the code that you *actually* need, because you wrote the tests first to reflect the requirements, and then edited the code until it passed. Compile your codebase with -fprofile-arcs -ftest-coverage, and then run the test suite. Use gcov to find code that never gets around to getting run; either it purports to implement correct behaviour under strange circumstances (fix the bug in your test suite - it is incomplete - write a test!), or someone was trying to be too cleverer and added untested (and un-run!) code: eliminate it once you agree it is indeed fallow. (I speak of wishful thinking about my own code base, not out of positive experience with this technique.) - -- It is manipulative to not be manipulative. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/ iD8DBQFEW+X5wyMv24BBd/gRAutsAJ9f6WbmIx+/hEmmc95283/bw77ZCgCfQ14T BKc5ti8qSNr4Qg9eM6e9fi8= =QqGv -END PGP SIGNATURE-
Re: codegen differences for increment of a volatile int
On Fri, May 05, 2006 at 04:29:53AM -0700, Gary Funck wrote: > ... where, when incrmenting the non-volatile 'j', it chosses 'addl' > over 'incl'. Pentium 4 is stupid that way; addl is faster. r~
