Re: trunk's genmodes crashes on Ubuntu/Lucid (alpha2 snapshot) not on Debian/Sid [both AMD64 architecture]
Basile STARYNKEVITCH wrote:
Hello
When building the gcc trunk revision 156557 on Ubuntu lucid AMD64 (the
alpha of the next Ubuntu release, which I upgraded just today on Febr
06, 2010), I am getting a repeatable SIGSEGV from genmodes
This is very probably an strcmp bug inside Ubuntu/Lucid
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/518314
Sorry for the noise.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: trunk's genmodes crashes on Ubuntu/Lucid (alpha2 snapshot) not on Debian/Sid [both AMD64 architecture]
On 02/07/10 01:02, Basile STARYNKEVITCH wrote: Basile STARYNKEVITCH wrote: Hello When building the gcc trunk revision 156557 on Ubuntu lucid AMD64 (the alpha of the next Ubuntu release, which I upgraded just today on Febr 06, 2010), I am getting a repeatable SIGSEGV from genmodes This is very probably an strcmp bug inside Ubuntu/Lucid https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/518314 Sorry for the noise. you should be able to build gcc without issues i.g. just built over here(just make sure you have gettext, textinfo, etc.. all build tools); Justin P. Mattock
Re: trunk's genmodes crashes on Ubuntu/Lucid (alpha2 snapshot) not on Debian/Sid [both AMD64 architecture]
On Sun, Feb 7, 2010 at 1:02 AM, Basile STARYNKEVITCH bas...@starynkevitch.net wrote: Basile STARYNKEVITCH wrote: Hello When building the gcc trunk revision 156557 on Ubuntu lucid AMD64 (the alpha of the next Ubuntu release, which I upgraded just today on Febr 06, 2010), I am getting a repeatable SIGSEGV from genmodes This is very probably an strcmp bug inside Ubuntu/Lucid https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/518314 Glibc 2.11 may have multiple versions of strmp for different processors. You need to report: 1. 32bit or 64bit. 2. Which SSE extensions are available. -- H.J.
The Linux binutils 2.20.51.0.6 is released
This is the beta release of binutils 2.20.51.0.6 for Linux, which is
based on binutils 2010 0205 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.20.51.0.4 release, no diffs against the previous
release will be provided.
You can enable both gold and bfd ld with --enable-gold=both. Gold will
be installed as ld.gold and bfd ld will be installed as ld.bfd. By
default, ld.gold will be installed as ld. You can use the configure
option, --enable-gold=both/bfd to choose bfd ld as the default linker,
ld. IA-32 binary and X64_64 binary tar balls are configured with
--enable-gold=both/bfd --enable-plugins --enable-threads.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.20.51.0.3 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.20.51.0.5:
1. Update from binutils 2010 0205.
2. Support x86 XSAVE extended state core dump.
3. Add an option, -mavxscalar=, to x86 assembler to encoding AVX
scalar instructios with VL=256 and update x86 disassembler.
4. Add xsave64/xrstor64 to x86 assembler/disassembler.
5. Add all the possible aliases for VPCOM* insns to x86 assembler.
5. Fix --gc-sections to detect unresolved symbol in DSO. PR 11218.
6. Support number of ELF program segments 64K.
7. Support BSD4.4 extended archive write.
8. Report error on bad section name with objdump -j. PR 11225.
9. Linker now checks if all files are present and indicates those missing.
PR 4437.
10. Allow adding section from empy file with objcopy.
11. Update C++ demangler to support vector.
12. Improve gold.
13. Improve arm support.
14. Improve hppa support.
15. Improve ppc support.
16. Improve s390 support.
Changes from binutils 2.20.51.0.4:
1. Update from binutils 2010 0115.
2. Optimize x86 assembler/disassembler.
3. Add a new program, elfedit, to edit ELF files. PR 11131.
4. Add --dyn-syms to readelf. PR 11146.
5. Remove Warning: from objcopy error message. PR 11130.
6. Fix linker --gc-sections with undefined __start_XXX/__stop_XXX symbols.
PR 11133.
7. Fix linker --gc-sections with SHT_NOTE section. PR 11143.
8. Fix a c++filt bug. PR 11137.
9. Fix assembler listing. PR 11122.
10. Improve gold. Change --enable-gold to --enable-gold=[both[/{gold,bfd}]].
11. Improve arm support.
12. Improve mips support.
13. Improve ppc support.
14. Improve MacOS support.
Changes from binutils 2.20.51.0.3:
1. Update from binutils 2009 1214.
Re: Problem with stores and loads from unions and proposed fix
Hi, On Sat, 6 Feb 2010, Richard Guenther wrote: CSE detects that the same subexpression is used in two places and substitutes a reaching register for the reference to u32.word without noticing that the memory has been modified by the bit field reference. Adding a call to invalidate_any_buried_refs(dest) flags the memory reference in such a way that it is not ignored and the erroneous CSE optimization is not done. Thanks to anyone who can help determine whether this is a problem for other gcc versions and getting a fix into the gcc source. Please specify the GCC version this happens with and show the RTL before gcse. In private communication it became clear that the set in question was a bitmap set: (set (ZERO_EXTRACT (MEM:SI (REG:SI fp) (CONST_INT 8) (CONST_INT 24) ) ... rhs ... ) This is an rmw set, hence includes a use. Similarly mishandled would be (set (MEM (MEM ...)) rhs ) (the inner MEM is a use and needs to be invalidated). I think it's quite clear that the invalidate_any_buried_refs call for the destination is missing. The comment in front of this if, of why it's okay to ignore aliasing seems confused, this doesn't involve aliasing at all. Ciao, Michael.
Re: Why auto variables NOT overlap on stack?
On Sun, 7 Feb 2010, Ding Curie wrote: I'm using GCC 3.4.5 (mingw-vista special r3). I downloaded the latest mingw; I take it for granted that latest mingw uses latest GCC. That may not be a correct assumption. In general, please go to http://gcc.gnu.org to see which version of GCC are current; http://gcc.gnu.org/releases.html my prove useful, too. Gerald
gcc-4.3-20100207 is now available
Snapshot gcc-4.3-20100207 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20100207/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 156587 You'll find: gcc-4.3-20100207.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20100207.tar.bz2 C front end and core compiler gcc-ada-4.3-20100207.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20100207.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20100207.tar.bz2 C++ front end and runtime gcc-java-4.3-20100207.tar.bz2 Java front end and runtime gcc-objc-4.3-20100207.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20100207.tar.bz2The GCC testsuite Diffs from 4.3-20100131 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
Jie Zhang appointed bfin maintainer
It is my pleasure to announce that, also based on the recommendation of Bernd as an existing maintainer, the steering committee has appointed Jie Zhang maintainer of the bfin port. Thanks for your contributions over the last five(?) years, Jie. Please adjust the MAINTAINERS file accordingly, and Happy Hacking! Gerald
Re: Jie Zhang appointed bfin maintainer
On 02/08/2010 08:53 AM, Gerald Pfeifer wrote: It is my pleasure to announce that, also based on the recommendation of Bernd as an existing maintainer, the steering committee has appointed Jie Zhang maintainer of the bfin port. Thanks for your contributions over the last five(?) years, Jie. Yes. I have worked on Blackfin port for nearly 5 years with Bernd. Please adjust the MAINTAINERS file accordingly, and Happy Hacking! Thanks! I have updated the the MAINTAINERS file with the attached patch. Jie * MAINTAINERS: Add myself as a maintainer for the bfin port. Index: MAINTAINERS === --- MAINTAINERS (revision 156592) +++ MAINTAINERS (working copy) @@ -48,6 +48,7 @@ avr port Anatoly Sokolov ae...@post.ru avr port Eric Weddington eric.wedding...@atmel.com bfin port Bernd Schmidt bernd.schm...@analog.com +bfin port Jie Zhang jie.zh...@analog.com cris port Hans-Peter Nilsson h...@axis.com crx port Pompapathi V Gadad pompapathi.v.ga...@nsc.com fr30 port Nick Clifton ni...@redhat.com @@ -493,7 +494,6 @@ Canqun Yang can...@nudt.edu.cn Joey Ye joey...@intel.com Kenneth Zadeck zad...@naturalbridge.com -Jie Zhang jie.zh...@analog.com Shujing Zhao pearly.z...@oracle.com Jon Ziegler j...@apple.com Roman Zippel zip...@linux-m68k.org
[Bug libfortran/42742] Handle very large format strings correctly
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-02-07 08:00 --- Fixed on trunk. Will back port to 4.4 in a few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 08:26 --- C90 has implicit declarations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #3 from schwab at linux-m68k dot org 2010-02-07 09:15 --- Use -Werror-implicit-function-declaration. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug c/42991] New: cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
I just tried to compile the Linux kernel 2.6.33-rc6 under valgrind with the C compiler version 4.5 snapshot 20100128 and valgrind said ==17102== Conditional jump or move depends on uninitialised value(s) ==17102==at 0x56D105: expand_debug_expr (cfgexpand.c:2487) ==17102==by 0x56C912: expand_debug_expr (cfgexpand.c:2876) ==17102==by 0x570D54: gimple_expand_cfg (cfgexpand.c:2981) ==17102==by 0x722ECA: execute_one_pass (passes.c:1561) ==17102==by 0x723154: execute_pass_list (passes.c:1616) ==17102==by 0x818C94: tree_rest_of_compilation (tree-optimize.c:413) ==17102==by 0x99A420: cgraph_expand_function (cgraphunit.c:1543) ==17102==by 0x99CE44: cgraph_optimize (cgraphunit.c:1622) ==17102==by 0x99D3A4: cgraph_finalize_compilation_unit (cgraphunit.c:1093) ==17102==by 0x4B0602: c_write_global_declarations (c-decl.c:9537) ==17102==by 0x7C7AFB: toplev_main (toplev.c:1065) ==17102==by 0x6568A7C: (below main) (in /lib64/libc-2.10.1.so) ==17102== Line 2487 of cfgexpand.c is if (bitsize == 0) return NULL; Preprocessed source code attached. Flags -Os -g required. -- Summary: cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug c/42991] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
--- Comment #1 from dcb314 at hotmail dot com 2010-02-07 10:25 --- Created an attachment (id=19817) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19817action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-07 10:58 --- Which means that likely DEBUG_DECLs do not have DECL_SIZE set properly. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Keywords||wrong-debug Summary|cfgexpand.c:2487: |[4.5 Regression] |Conditional jump or move|cfgexpand.c:2487: |depends on uninitialised|Conditional jump or move |value(s)|depends on uninitialised ||value(s) Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug target/42981] internal compiler error: in default_secondary_reload, at targhooks.c:660
--- Comment #5 from mikpe at it dot uu dot se 2010-02-07 11:17 --- (In reply to comment #4) A bisection has identified this as a regression on 4.4 branch triggered by r147081, the fix for PR39914. The same change was committed to trunk too, but for some reason doesn't trigger the ICE there. Trunk also ICEd on this test case for a while, but that was fixed by r147282, one of several fixes to fwprop/df-problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
[Bug c++/42992] New: [C++0x] =default erases virtual declaration of a destructor.
Hello,
Following code :
#include iostream
struct A {
virtual ~A()=default;
};
struct B : public A {
virtual ~B() {
std::cout B destructor\n;
}
};
int main() {
B* b = new B;
A* pA = b;
delete pA;
return 0;
}
outputs nothing, B destructor is not called as if A destructor was not
considered as virtual.
However, following code works fine :
#include iostream
struct A {
virtual ~A();
};
A::~A()=default;
struct B : public A {
virtual ~B() {
std::cout B destructor\n;
}
};
int main() {
B* b = new B;
A* pA = b;
delete pA;
return 0;
}
It outputs B destrucor.
Having to separate virtual declaration from default definition seems to be out
of spec.
Bug found with MinGW/gcc 4.4.1..
Compilation command :
mingw32-g++.exe -Wall -fexceptions -Wmain -pedantic -W -g -std=c++0x -c
main.cpp -o obj\Debug\main.o
mingw32-g++.exe -o bin\Debug\TestCpp.exe obj\Debug\main.o
Best Regards
Albert.
--
Summary: [C++0x] =default erases virtual declaration of a
destructor.
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: albrt2000 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42992
[Bug c++/42992] [C++0x] =default erases virtual declaration of a destructor.
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-07 11:43 --- *** This bug has been marked as a duplicate of 42983 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42992
[Bug c++/42983] [C++0x] Defaulted virtual destructor isn't virtual
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-07 11:43 --- *** Bug 42992 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||albrt2000 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42983
[Bug target/42981] internal compiler error: in default_secondary_reload, at targhooks.c:660
--- Comment #6 from mikpe at it dot uu dot se 2010-02-07 11:54 --- gcc-4.5-20100204 ICEs with -O1 -fno-forward-propagate -fPIC -mthumb on the original test case. So r147282, which enabled fwprop at -O1, merely masked the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42981
[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments
--- Comment #4 from xavier dot guerin at imag dot fr 2010-02-07 12:32
---
I checked GCC 4.4.2 and the issue still exists. It's extremely easy to check,
and I actually pinned the issue. I don't mind helping more (and I guess I'll
have to do it by myself anyway), but I'm completely ignorant concerning
compilation stuff.
Basically, the issue is as follows. Let's say we have this situation (note that
he behavior of function() is irrelevant) compiled for a mips32 architecture :
int function (int n, ...)
{
}
int main (void)
{
int32_t i32;
int64_t i64_0, i64_1;
function (3, i64_0, i32, i64_1);
return 0;
}
## Caller behavior ##
In that case, main prepare the va_list. Right before calling function(), the
stack looks like this:
SP-40 [ X | X | X | X | n | X | upper (i64_1) | lower (i64_1) | X | RA ] SP
whereas upper (i64_0) and lower (i64_0) are stored in registers a2 and a3.
Please note that GCC inserts a bubble between 'n' and 'upper(i64_1)'. At
first, I supposed this was for double-word alignment purpose, but in my case
the address of 'upper (i64_1)' is not double-word aligned.
## Callee behavior ##
Anyhow, the callee is waiting for the following stack pattern when mashalling
the varargs:
SP-40 [ X | X | X | X | n | upper (i64_1) | lower (i64_1) | X | X | RA ] SP
which is the same configuration but without the bubble. As see it, the callee
code must be correct since it refers to the algorithm described in function
mips_gimplify_va_arg_expr(), line 5235 of the mips.c files, while the caller
code wrongfully inserts a bubble to correct a padding problem that does not
exit.
I think this should shed some lights on the issue I'm encountering. Maybe
somehow could tell me where I can found the va_list preparation code in the
mips.c file.
Thanks in advance for your help,
Xavier
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640
[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-07 12:43 --- There are btw a load of va-arg testcases in the testsuite and testresults on mips-unknown-elf do not show any problems on the 4.3 or the 4.4 branch or on trunk (as reported by Mike Stein). Thus, please provide an executable testcase that aborts if miscompiled and that shows the broken behavior on mips-elf with an unmodified GCC source tree. You can also double-check testresults on your target, specifically the various gcc.c-torture/execute/va-arg*.c testcases - which are also a good example on how a reproducable testcase should look like both for inclusion in the testsuite and for reproducing and fixing this bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|mips-sls-dnaos |mips-*-elf Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640
[Bug libfortran/42742] Handle very large format strings correctly
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2010-02-07 13:37 --- Closing, not needed on 4.4 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42742
[Bug tree-optimization/42956] [4.4/4.5 Regression] internal compiler error: Segmentation fault with -O1
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-07 13:43 --- Subject: Bug 42956 Author: rguenth Date: Sun Feb 7 13:42:52 2010 New Revision: 156571 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156571 Log: 2010-02-07 Richard Guenther rguent...@suse.de PR middle-end/42956 * gimplify.c (gimple_fold_indirect_ref): Avoid generating new ARRAY_REFs on variable size element or minimal index arrays. Complete. * tree-ssa-loop-ivopts.c (find_interesting_uses_address): Use gimple_fold_indirect_ref. * gcc.c-torture/compile/pr42956.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr42956.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-07 13:43 --- Fixed for 4.5.0 sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.3 4.5.0 |4.4.3 Known to work|4.3.5 4.4.2 |4.3.5 4.4.2 4.5.0 Summary|[4.4/4.5 Regression]|[4.4 Regression] internal |internal compiler error:|compiler error: Segmentation |Segmentation fault with -O1 |fault with -O1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug tree-optimization/42956] [4.4 Regression] internal compiler error: Segmentation fault with -O1
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-02-07 13:43 --- P1 for a regression on a release branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42956
[Bug c/42993] New: simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)
I just tried to compile the Linux kernel 2.6.33-rc6 under valgrind with the C compiler version 4.5 snapshot 20100128 and valgrind said ==2968== Conditional jump or move depends on uninitialised value(s) ==2968==at 0x7A6925: delegitimize_mem_from_attrs (simplify-rtx.c:244) ==2968==by 0x961517: ix86_delegitimize_address (i386.c:10883) ==2968==by 0x93E5F6: emit_note_insn_var_location (var-tracking.c:6515) ==2968==by 0xCB84D7: htab_traverse_noresize (hashtab.c:753) ==2968==by 0x941376: emit_notes_for_changes (var-tracking.c:6741) ==2968==by 0x946A67: vt_emit_notes (var-tracking.c:7106) ==2968==by 0x94A602: variable_tracking_main (var-tracking.c:7637) ==2968==by 0x722ECA: execute_one_pass (passes.c:1561) ==2968==by 0x723154: execute_pass_list (passes.c:1616) ==2968==by 0x723166: execute_pass_list (passes.c:1617) ==2968==by 0x723166: execute_pass_list (passes.c:1617) ==2968==by 0x818C94: tree_rest_of_compilation (tree-optimize.c:413) ==2968== Line 244 of simplify-rtx.c is if (bitsize != GET_MODE_BITSIZE (mode) || (bitpos % BITS_PER_UNIT) || (toffset !host_integerp (toffset, 0))) decl = NULL; Preprocessed source code attached. Flags -Os -g required. -- Summary: simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993
[Bug c/42993] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)
--- Comment #1 from dcb314 at hotmail dot com 2010-02-07 14:33 --- Created an attachment (id=19818) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19818action=view) C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #4 from vyg84 at mail dot ru 2010-02-07 14:46 --- I think some moments should be cleared. I used Anjuta 2.28.1.0 C console project, include file initially was only stdio.h. I'm not strcitly sure with what language standart my program was compiled, but it is very likely with C99, I didn't found any standart modifying options like ansi and std=. If it is C89 (by my opinion this such implicit declarations is a doubtable feature) why didn't linker showed any error messages like Unresolved external: 'atof' for example. By my opinion in this case the progrm should't be assemble at all because of its actual unpredictability. And why did 'atoi' worked ) ? -- vyg84 at mail dot ru changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug middle-end/42993] [4.5 Regression] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-07 14:47 --- Probably the same issue as PR42991. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Component|c |middle-end Summary|simplify-rtx.c:244: |[4.5 Regression] simplify- |Conditional jump or move|rtx.c:244: Conditional jump |depends on uninitialised|or move depends on |value(s)|uninitialised value(s) Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-07 14:49 --- The linker didn't complain because atof is in libc which is linked in. atoi does work because any unprototyped function is treated as int function(); thus the unprototyped atof results in int atof(); which leads the compiler to insert a conversion from the presumed integer return type to the floating-point result. Which is what causes your observation. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-07 14:54 --- Btw, with -std=c99 -pedantic-errors you will get an error for missing prototypes (not so with -std=c89 or the default, which is -std=gnu89, because as was said C89 allows unprototyped functions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug middle-end/42961] [4.5 regression] IRA register preferencing bug
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.4 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42961
[Bug middle-end/42973] [4.4/4.5 regression] IRA apparently systematically making reload too busy on 2 address instructions with 3 operands
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-07 15:03 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.3 4.5.0 Known to work||4.3.4 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:03:02 date|| Summary|[4.5 regression] IRA|[4.4/4.5 regression] IRA |apparently systematically |apparently systematically |making reload too busy on 2 |making reload too busy on 2 |address instructions with 3 |address instructions with 3 |operands|operands http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42973
[Bug debug/42977] [4.5 Regression] -fcompare-debug failure with -O2 -finline-functions -fomit-frame-pointer -ftracer -fsched2-use-superblocks -fPIC
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-07 15:06 ---
Confirmed. The difference is from scheduling:
--- t.gk.gkd2010-02-07 16:05:02.0 +0100
+++ t.gkd 2010-02-07 16:05:01.0 +0100
@@ -1900,6 +1900,9 @@
(insn:TI# 0 0 t.C:403 (set (reg/f:SI 0 ax [389])
(plus:SI (reg/f:SI 7 sp)
(const_int 79 [0x4f])))# {*lea_1} (nil))
+(insn:TI# 0 0 t.C:403 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
+(reg/f:SI 0 ax [389]))# {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 0 ax
[
389])
+(nil)))
(insn:TI# 0 0 t.C:403 (set (mem/f/i:SI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S4 A32])
(reg/f:SI 4 si [517]))# {*movsi_1} (expr_list:REG_EQUAL (plus:SI
(reg/f
:SI 20 frame)
@@ -1911,9 +1914,6 @@
(expr_list:REG_EQUAL (plus:SI (reg/f:SI 20 frame)
(const_int -5 [0xfffb]))
(nil
-(insn:TI# 0 0 t.C:403 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
-(reg/f:SI 0 ax [389]))# {*movsi_1} (expr_list:REG_DEAD (reg/f:SI 0 ax
[
389])
-(nil)))
(call_insn:TI# 0 0 t.C:403 (parallel [
(call (mem:QI (symbol_ref:SI
(_ZN4Glib12SignalProxy2Iv7ustringS1_E
7connectEN4sigc4slotIvNS3_3nilES5_S5_S5_EE) [flags 0x41] function_decl #
conn
ect) [0 S1 A8])
(const_int 12 [0xc]))
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:06:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
[Bug middle-end/42988] [4.5 regression] 2 libgomp test failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-07 15:06 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:06:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42988
[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-07 15:22 ---
No, this is not really debug-expr related. We have
struct crypto_tfm {
...
void *__crt_ctx[] __attribute__ ((__aligned__(__alignof__(unsigned long
long;
};
and the FIELD_DECL for __crt_ctx has DECL_SIZE == 0, so get_inner_reference
on a COMPONENT_REF of __crt_ctx will leave us with *pbitsize uninitialized.
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-02-07 15:22:59
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-07 15:29 --- *** Bug 42993 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug middle-end/42993] [4.5 Regression] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-02-07 15:29 --- The fix for 42991 also fixes this bug. *** This bug has been marked as a duplicate of 42991 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #7 from vyg84 at mail dot ru 2010-02-07 17:07 --- I agree with all above but in my case linker should raise error unresolved external: int atof(char* ) without having in glibc int atof(char* ) (but should not for double atof(char* )). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug c/42990] warning: implicit declaration of function 'xxx' instead of error: ...
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-02-07 17:10 --- Except C linkage does not have that information stored anywhere :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42990
[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-07 17:18 --- Subject: Bug 42991 Author: rguenth Date: Sun Feb 7 17:18:22 2010 New Revision: 156575 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156575 Log: 2010-02-07 Richard Guenther rguent...@suse.de PR middle-end/42991 * expr.c (get_inner_reference): Always initialize *pbitsize. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug debug/42991] [4.5 Regression] cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s)
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-07 17:18 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42991
[Bug middle-end/42993] [4.5 Regression] simplify-rtx.c:244: Conditional jump or move depends on uninitialised value(s)
--- Comment #4 from dcb314 at hotmail dot com 2010-02-07 18:13 --- (In reply to comment #2) Probably the same issue as PR42991. Does fixing 42991 also fix this problem ? I suspect it might be worth checking this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42993
[Bug libstdc++/16896] Use of non-reserved names in stl_list.h
--- Comment #9 from paolo at gcc dot gnu dot org 2010-02-07 18:37 --- Subject: Bug 16896 Author: paolo Date: Sun Feb 7 18:36:48 2010 New Revision: 156578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156578 Log: 2010-02-07 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/16896 * include/bits/stl_list.h (_List_node_base::transfer): Rename to _M_transfer. (_List_node_base::reverse): Rename to _M_reverse. (_List_node_base::hook): Rename to _M_hook. (_List_node_base::unhook): Rename to _M_unhook; adjust callers. * include/bits/list.tcc: Adjust callers. * src/list.cc: Adjust. * src/compatibility.cc: Likewise. * src/compatibility-list.cc: New. * src/compatibility-debug_list.cc: Likewise. * src/compatibility-parallel_list.cc: Likewise. * src/Makefile.am: Add. * src/Makefile.in: Regenerate. * config/abi/pre/gnu.ver: Export _M_* symbols. * src/hash.cc: Rename to hash-aux.cc. * src/compatibility-ldbl.cc: Adjust. * src/compatibility-c++0x.cc: Likewise. * src/hash_tr1.cc: Likewise. * src/hashtable.cc: Rename to hashtable-aux.cc. * src/hashtable_c++0x.cc: Adjust. * src/hashtable_tr1.cc: Likewise. * src/limits_c++0x.cc: Fold... * src/limits.cc... here. Added: trunk/libstdc++-v3/src/compatibility-debug_list.cc trunk/libstdc++-v3/src/compatibility-list.cc trunk/libstdc++-v3/src/compatibility-parallel_list.cc trunk/libstdc++-v3/src/hash-aux.cc - copied unchanged from r156570, trunk/libstdc++-v3/src/hash.cc trunk/libstdc++-v3/src/hashtable-aux.cc - copied unchanged from r156570, trunk/libstdc++-v3/src/hashtable.cc Removed: trunk/libstdc++-v3/src/hash.cc trunk/libstdc++-v3/src/hashtable.cc trunk/libstdc++-v3/src/limits_c++0x.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/bits/list.tcc trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/compatibility-c++0x.cc trunk/libstdc++-v3/src/compatibility-ldbl.cc trunk/libstdc++-v3/src/compatibility.cc trunk/libstdc++-v3/src/hash_tr1.cc trunk/libstdc++-v3/src/hashtable_c++0x.cc trunk/libstdc++-v3/src/hashtable_tr1.cc trunk/libstdc++-v3/src/limits.cc trunk/libstdc++-v3/src/list.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16896
[Bug libstdc++/16896] Use of non-reserved names in stl_list.h
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-07 18:37 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16896
[Bug bootstrap/42666] xgcc: Internal error: segmentation violation (program cc1)
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 18:58 --- Have you tried building in a different directory than the source directory? Do you have any environment variables set like CFLAGS, etc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42666
[Bug target/42940] Building GCC C compiler for --target=m68hc12-elf ends with ICE SIGSEG
--- Comment #8 from wlodzimierz dot lipert+gcc at gmail dot com 2010-02-07
19:06 ---
Hi,
I think problem may be in gcc.c do_spec_1() function,
GCC segfaults after calling do_spec() - do_spec_2() - do_spec_1() (seg fault
here).
Building of libgcc with DEBUG_SPECS.
/home/vlad/opt/gcc-build/./gcc/xgcc -B/home/vlad/opt/gcc-build/./gcc/
-B/home/vlad/CPU12/m68hc12-elf/bin/ -B/home/vlad/CPU12/m68hc12-elf/lib/
-isystem /home/vlad/CPU12/m68hc12-elf/include -isystem
/home/vlad/CPU12/m68hc12-elf/sys-include -O2 -g -save-temps -g -DDEBUG_SPECS
-m68hc11 -Os -mrelax -DUSE_GAS -DIN_GCC -Dinhibit_libc -g -DIN_LIBGCC2 -I.
-I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include
-DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../../gcc/libgcc/../gcc/libgcc2.c \
Processing spec (trad_capable_cpp), which is 'cc1 -E
%{traditional|ftraditional|traditional-cpp:-traditional-cpp}'
Processing spec (cpp_options), which is '%(cpp_unique_options) %1 %{m*}
%{std*ansitrigraphs} %{W*pedantic*} %{w} %{f*}
%{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef}
%{save-temps:-fpch-preprocess}'
Processing spec (cpp_unique_options), which is '%{C|CC:%{!E:%eGCC does not
support -C or -CC without -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v}
%{I*F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD
%{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*}
%{!E:%{!M:%{!MM:%{!MT:%{!MQ:%{MD|MMD:%{o*:-MQ %*}}} %{remap}
%{g3|ggdb3|gstabs3|gcoff3|gxcoff3|gvms3:-dD} %{H} %C %{D*U*A*} %{i*} %Z %i
%{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP
-D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}'
Processing spec (cc1_options), which is '%{pg:%{fomit-frame-pointer:%e-pg and
-fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*}
%{m*} %{a*} %{c|S:%{o*:-auxbase-strip %*}%{!o*:-auxbase %b}}%{!c:%{!S:-auxbase
%b}} %{g*} %{O*} %{W*pedantic*} %{w} %{std*ansitrigraphs} %{v:-version}
%{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help}
%{--target-help:--target-help} %{--help=*:--help=%(VALUE)}
%{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*}
%{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}
%{coverage:-fprofile-arcs -ftest-coverage}'
Processing spec (invoke_as), which is '%{!S:-o %|.s |
as %(asm_options) %m.s %A }'
../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3':
../../../../gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error:
Segmentation fault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42940
[Bug driver/42994] New: Status of using both -m32 and -m64 on the same command line
I noticed that combining -m32 and -m64 has different effects on different platforms. On sparc64: 20:06 ares:../libhugetlbfs/libhugetlbfs-2.0 gcc -c -m32 -m64 x.c gcc: may not use both -m32 and -m64 On x86_64: 20:11 borg:~/obs x.c 20:11 borg:~/obs gcc -c -m32 -m64 x.c (no error) I think that this behavior should be unified across gcc's supported arches, and I would opt for not allowing both -m32 and -m64, to detect flawed packages (like libhugetlbfs in this case) that manually add -m64 - perhaps even in the wrong place - based upon their arch detection heuristic (which is generally not accurate). The particular example point in case is rpmbuilding on SUSE where RPM_OPT_FLAGS carries -m32 (this is correct) and libhugetlbfs's Makefile statically adds -m64 (this is incorrect). This error has not popped up earlier since combining -m32 and -m64 is unfortunately permitted on x86. -- Summary: Status of using both -m32 and -m64 on the same command line Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jengelh at medozas dot de GCC build triplet: sparc64-suse-linux-gnu GCC host triplet: sparc64-suse-linux-gnu GCC target triplet: sparc64-suse-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994
[Bug target/42994] Status of using both -m32 and -m64 on the same command line
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 19:21 --- I think that this behavior should be unified across gcc's supported arches, Why -m* means it is a target specific option? x86_64 and powerpc64 both have the same behavior of having the last one being the used one which is like options act like. So really this is a sparc64 issue only. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|driver |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994
[Bug middle-end/42988] [4.5 regression] 2 libgomp test failures
--- Comment #3 from spop at gcc dot gnu dot org 2010-02-07 19:49 --- Subject: Bug 42988 Author: spop Date: Sun Feb 7 19:49:06 2010 New Revision: 156582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156582 Log: Fix PR42988: handle unknown_dependence. 2010-02-07 Sebastian Pop sebastian@amd.com PR middle-end/42988 * graphite-dependences.c (dependence_polyhedron): Set PDDR_KIND to unknown_dependence. (graphite_legal_transform_dr): Handle the unknown_dependence. (graphite_carried_dependence_level_k): Same. * testsuite/libgomp.graphite/force-parallel-5.c: Un-XFAILed. * testsuite/libgomp.graphite/pr41118.c: Renamed from pr4118. Added: trunk/libgomp/testsuite/libgomp.graphite/pr41118.c - copied, changed from r156581, trunk/libgomp/testsuite/libgomp.graphite/pr4118.c Removed: trunk/libgomp/testsuite/libgomp.graphite/pr4118.c Modified: trunk/gcc/ChangeLog.graphite trunk/gcc/graphite-dependences.c trunk/libgomp/ChangeLog.graphite trunk/libgomp/testsuite/libgomp.graphite/force-parallel-5.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42988
[Bug middle-end/42988] [4.5 regression] 2 libgomp test failures
--- Comment #4 from spop at gcc dot gnu dot org 2010-02-07 19:50 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42988
[Bug target/42683] gcc manpage: Description of x86 -march not clear regarding mmx
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 19:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|other |target Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2010-02-07 19:51:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42683
[Bug c++/42765] If the compile fails, the gch is still produced.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 20:01 --- *** This bug has been marked as a duplicate of 33980 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42765
[Bug pch/33980] Precompiled header file not removed on error
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-07 20:01 --- *** Bug 42765 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||JamesMikeDuPont at ||googlemail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980
[Bug pch/33980] Precompiled header file not removed on error
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-07 20:02 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|Linux OpenSuse 10.3 | Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:02:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980
[Bug middle-end/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-07 20:04 --- You can gzip the preprocessed source if needed. Also It might be the case we are jump threading in one case and not in the other which causes the zero expression to show up and that causes glibc's headers to produce the warning ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42688
[Bug target/42778] Superfluous stack management code is generated
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 20:09 --- Confirmed, a target bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |target Ever Confirmed|0 |1 GCC host triplet|GCC-| |trunk(20100107)/Cygwin/WinXP| |32 | GCC target triplet||i?86-*-* Keywords||missed-optimization Known to fail||4.3.2 4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:09:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42778
[Bug other/42792] cc1-dummy link fails with missing tree_ and rtl_ functions
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 20:11 --- What happens if you build in a different directory than the source directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42792
[Bug bootstrap/42787] Failed to make all-target
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-02-07 20:16 --- That line of compiling does not make sense as it is trying to compile gcc/config/m32r/m32r.c as a target object file while it should only be compiled for the host machine ... How did you configure gcc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-07 20:18 --- How did you invoke configure and make? What are your env variables settings for CFLAGS, STAGE1_CFLAGS and BOOT_CFLAGS? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Status|UNCONFIRMED |WAITING Component|target |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827
[Bug lto/42826] lto1: ICE in ipcp_iterate_stage, at ipa-cp.c:759
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42826
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-07 20:23 --- Not a FSF GCC bug so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug java/42892] Incorrect code generated for enhanced for loop.
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-02-07 20:25 --- Confirmed to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:25:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
[Bug java/42892] Incorrect code generated for enhanced for loop.
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-02-07 20:26 --- Suspend. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42892
[Bug target/39640] MIPS : buggy va_list with float, long long and long double arguments
--- Comment #6 from xavier dot guerin at imag dot fr 2010-02-07 20:28 --- I found my issue. MIPS backend assumes that the $sp is aligned on a double word frontier. Although my thread's stack malloc guarantee this point, my context_init was applying a wrong mask to the final stack address. It is now fixed. Thank you for your help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39640
[Bug c++/42911] [4.5 Regression] another compiler hang for -g -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Summary|another compiler hang for -g|[4.5 Regression] another |-O2 |compiler hang for -g -O2 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42911
[Bug tree-optimization/42720] Problematic condition simplification logic at unswitch-loops pass
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-02-07 20:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:28:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42720
[Bug tree-optimization/42729] [4.5 Regression] -fcompare-debug failure with -O1 -fgraphite-identity
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code, wrong- ||code Summary|-fcompare-debug failure |[4.5 Regression] -fcompare- |with -O1 -fgraphite- |debug failure with -O1 - |identity |fgraphite-identity Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42729
[Bug debug/42918] [4.5 Regression] -fcompare-debug failure with -O2 -ftracer (2)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code, wrong- ||code Summary|-fcompare-debug failure |[4.5 Regression] -fcompare- |with -O2 -ftracer (2) |debug failure with -O2 - ||ftracer (2) Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42918
[Bug preprocessor/42921] No error with missing header and -MM
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 20:33 --- *** This bug has been marked as a duplicate of 28435 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42921
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #15 from pinskia at gcc dot gnu dot org 2010-02-07 20:33 --- *** Bug 42921 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rhansen at bbn dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug tree-optimization/42931] [4.4/4.5 Regression] -ftree-loop-linear - valgrind warns about using uninitialized variable
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|-ftree-loop-linear -|[4.4/4.5 Regression] -ftree- |valgrind warns about using |loop-linear - valgrind warns |uninitialized variable |about using uninitialized ||variable Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42931
[Bug tree-optimization/42916] [4.5 Regression] -fcompare-debug failure with -O1 -funroll-loops -ftree-vectorize
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-07 20:37 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, wrong- ||code Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:37:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42916
[Bug debug/42897] [4.5 Regression] yet another ice in verify_ssa
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:37:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
[Bug c++/42938] ICE with 4.4.2 on MIPS
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 20:38 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938
[Bug rtl-optimization/42946] [4.5 Regression] bootstrap with --enable-checking=df (or =all) fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 20:56 --- I have an obvious patch which fixes this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|bootstrap |rtl-optimization Ever Confirmed|0 |1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:56:18 date|| Summary|bootstrap with --enable-|[4.5 Regression] bootstrap |checking=df (or =all) fails |with --enable-checking=df ||(or =all) fails Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946
[Bug rtl-optimization/42941] -fsched-pressure -fschedule-insns - valgrind warns about using uninitialized variable
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-07 20:57 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42941
[Bug driver/42955] undecorated cross-compiler gcc fails to find cc1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42955
[Bug other/42966] add some indication that a warning has been converted to an error
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 20:58 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:58:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42966
[Bug other/42965] no warnings being treated as errors for individual -Werror=x options
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 20:58 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-07 20:58:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42965
[Bug tree-optimization/42971] GCC cannot perform partial inlining
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 21:01 --- Related to PR 10474. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42971
[Bug target/42976] Illegal translation for IF operator
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c++ |target GCC build triplet|avr | Keywords||wrong-code Version|unknown |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42976
[Bug c++/42938] ICE with 4.4.2 on MIPS
--- Comment #3 from manuel dot montezelo at gmail dot com 2010-02-07 21:02 --- As I said in the report: Neither I nor the official developer who uploaded the package have access to the machines to provide you the intermediate generated files to help debugging the problem or anything, nor to test in MIPS architecture with newest GCC versions. All the versions of packages with their private Debian patches and everything is available to download, of course. By other words, this happened in the Debian farm building the binaries and we don't have access to it, and we don't have access to any other MIPS machine. All the versions of the software involved is in the links provided (especially the build log), and all the software including specific Debian patches is available for download in Debian. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938
[Bug c++/42938] ICE with 4.4.2 on MIPS
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-07 21:16 --- Then it is up to debian to upload the sources ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #16 from cgd at google dot com 2010-02-07 21:24 --- (In reply to comment #15) *** Bug 42921 has been marked as a duplicate of this bug. *** FWIW, I actually think that's a different issue (though certainly related). this bug was all about -MD and -MMD -- and what happens when an object file needs to be output, but cannot be because of a missing include. AFAICT, that bug is all about, what should the handling of -MM be vs. missing system headers. That having been said, I will note that with: gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) you get the results: [...@laptop tmp]$ echo #include does_not_exist.h foo.c [...@laptop tmp]$ gcc -MM -MF foo.d foo.c echo succeeded || echo failed foo.c:1:28: does_not_exist.h: No such file or directory failed [...@laptop tmp]$ echo '#include does_not_exist.h' foo.c [...@laptop tmp]$ gcc -MM -MF foo.d foo.c echo succeeded || echo failed foo.c:1:28: does_not_exist.h: No such file or directory failed So this certainly used to behave as the submitter of 42921 expected at *some* point. As of 4.2.2 (the next version I have handy after 3.4.4) the first case reported succeeded (and the second failed). --cgd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug middle-end/42688] gcc 4.3.3 with -O2 thinks a often non-zero expression is always zero
--- Comment #5 from mnemo at minimum dot se 2010-02-07 21:34 --- The gzipped output is also too big for this bugzilla instance to handle. It should be easy for you to download the *.tar.gz from the description and just run gcc -E -O2 on it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42688
[Bug c++/42938] ICE with 4.4.2 on MIPS
--- Comment #5 from manuel dot montezelo at gmail dot com 2010-02-07 21:37 --- What do you mean with provide the sources? I created the package, and as I said it's available for downloading from Debian, as any package, including all the private/Debian-specific modifications: http://packages.debian.org/source/unstable/openscenegraph (at the bottom). But I don't think that nobody is going to enter the Debian farm, maybe restore the state of the machine when the building failed (related software versions), change the commands to produce preprocessor intermediate files, and attach them to this bug report -- if that's what you mean. I reported the error because an ICE seems important to me, and in the hope that it might be of interest and that maybe you have the means to get a MIPS machine and reproduce it with our package, or at least check in the near future whether newer releases of the compiler fix the bug. But I also warned in the original report that further information or testing patches from our part wouldn't be possible in general. It's up to you to close the report if you don't think that it's useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42938
[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared
--- Comment #4 from marekarturpenther at gmail dot com 2010-02-07 22:07 --- Subject: Re: error in building libgcc; error: 'BITS_PER_UNIT' undeclared BOOT_CFLAGS is same as CFLAGS: -mmmx -m3dnow -msse -march=athlon-xp -mtune=athlon-xp -O2 -pipe -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DUSE_3DNOW_PREFETCH STAGE1_CFLAGS is empty (not set) anyway I forcing using all setuped flags by invoking make with this flags before make, because I using chroot environment to build gcc. I started to use it, when I had problem with java, but I found out it is bug in gcc. On Sunday 07 February 2010 20:18, pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-07 20:18 --- How did you invoke configure and make? What are your env variables settings for CFLAGS, STAGE1_CFLAGS and BOOT_CFLAGS? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827
[Bug target/42994] Status of using both -m32 and -m64 on the same command line
--- Comment #2 from rguenther at suse dot de 2010-02-07 22:09 --- Subject: Re: New: Status of using both -m32 and -m64 on the same command line On Sun, 7 Feb 2010, jengelh at medozas dot de wrote: I noticed that combining -m32 and -m64 has different effects on different platforms. On sparc64: 20:06 ares:../libhugetlbfs/libhugetlbfs-2.0 gcc -c -m32 -m64 x.c gcc: may not use both -m32 and -m64 On x86_64: 20:11 borg:~/obs x.c 20:11 borg:~/obs gcc -c -m32 -m64 x.c (no error) I think that this behavior should be unified across gcc's supported arches, and I would opt for not allowing both -m32 and -m64, to detect flawed packages (like libhugetlbfs in this case) that manually add -m64 - perhaps even in the wrong place - based upon their arch detection heuristic (which is generally not accurate). The particular example point in case is rpmbuilding on SUSE where RPM_OPT_FLAGS carries -m32 (this is correct) and libhugetlbfs's Makefile statically adds -m64 (this is incorrect). This error has not popped up earlier since combining -m32 and -m64 is unfortunately permitted on x86. It's never correct for RPM_OPT_FLAGS to add either -m32 or -m64. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994
[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-07 22:09 --- So I think we are miscompiling GCC with BOOT_CFLAGS set. I don't have access to an x86 machine which could use those CFLAGS so someone else needs to debug this. Can you try 4.4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827
[Bug target/42994] Status of using both -m32 and -m64 on the same command line
--- Comment #3 from joseph at codesourcery dot com 2010-02-07 22:58 --- Subject: Re: Status of using both -m32 and -m64 on the same command line On Sun, 7 Feb 2010, pinskia at gcc dot gnu dot org wrote: I think that this behavior should be unified across gcc's supported arches, Why -m* means it is a target specific option? It's a lot less confusing for people using GCC for multiple targets (and the wide range of target support is one of the major advantages of GCC) if when multiple targets do similar things, they do so the same way where possible. Unfortunate inconsistencies include: * The combination of -march, -mcpu and -mtune options available, and what -mcpu means where it is available (also, some targets have yet other options for specifying target processors). * The options used for selecting endianness where applicable (-mbig-endian, -meb, -mb, -EB). * Whether interrupt handlers use the interrupt or interrupt_handler attribute. It's not that code using one of these options would do so in a cross-platform way; it's that having consistency would be beneficial to users doing similar things for multiple targets. x86_64 and powerpc64 both have the same behavior of having the last one being the used one which is like options act like. So really this is a sparc64 issue only. Yes, similar to the above there should be consistency in how options overriding each other work, and I describe a proposed model for this in http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html (Appendix 1) which means the last option specified wins in cases like this of options that are exact opposites. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994
[Bug middle-end/42995] New: [4.3 regression] inline-small-functions does not inline simple delegation calls
Using gcc 4.4.1 under Ubuntu 9.10 on amd64:
main.c:
#include database.h
int main()
{
int my_id = 0;
int result_for_my_id = get_data_for(my_id);
switch (result_for_my_id)
{
case 0:
return 666;
default:
return -1;
}
}
database.h:
#include stdlib.h
int get_data_for(int id)
{
return rand();
}
Compiling with:
gcc -O2 main.c -o n
produces this code:
00400380 main:
400380: 48 83 ec 08 subrsp,0x8
400384: 31 ff xoredi,edi
400386: e8 e5 ff ff ff call 400370 get_data_for
40038b: 83 f8 01cmpeax,0x1
40038e: 19 c0 sbbeax,eax
400390: 48 83 c4 08 addrsp,0x8
400394: 25 9b 02 00 00 andeax,0x29b
400399: 83 e8 01subeax,0x1
40039c: c3 ret
40039d: 0f 1f 00nopDWORD PTR [rax]
Note the 3 bytes of padding after the return. I'm confused why
inline-small-functions does not inline get_data_for. I tried this experiment:
gcc -O2 -finline-functions --param max-inline-insns-auto=20 main.c -o n
which produces this code:
00400380 main:
400380: 48 83 ec 08 subrsp,0x8
400384: e8 27 02 00 00 call 4005b0 r...@plt
400389: 83 f8 01cmpeax,0x1
40038c: 19 c0 sbbeax,eax
40038e: 48 83 c4 08 addrsp,0x8
400392: 25 9b 02 00 00 andeax,0x29b
400397: 83 e8 01subeax,0x1
40039a: c3 ret
40039b: 0f 1f 44 00 00 nopDWORD PTR [rax+rax*1+0x0]
The padding got larger, but the code is actually smaller. Shouldn't the
heuristic used for inline-small-functions have caused get_data_for() to be
inlined?
This does not appear to be a problem in GCC 4.5.20091228 or 4.3.4.
--
Summary: [4.3 regression] inline-small-functions does not inline
simple delegation calls
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
GCC build triplet: x86_64-linux-unknown
GCC host triplet: x86_64-linux-unknown
GCC target triplet: x86_64-linux-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42995
[Bug middle-end/42995] [4.3 regression] inline-small-functions does not inline simple delegation calls
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-07 23:03 --- The padding got larger, But the alignment stayed the same. :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42995
[Bug rtl-optimization/42946] [4.5 Regression] bootstrap with --enable-checking=df (or =all) fails
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-07 23:23 --- Subject: Bug 42946 Author: pinskia Date: Sun Feb 7 23:22:49 2010 New Revision: 156589 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156589 Log: 2010-02-07 Andrew Pinski pins...@gmail.com PR middle-end/42946 * df-core.c (df_finish_pass): Change type of saved_flags to int. Modified: trunk/gcc/ChangeLog trunk/gcc/df-core.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946
[Bug rtl-optimization/42946] [4.5 Regression] bootstrap with --enable-checking=df (or =all) fails
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-07 23:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42946
[Bug preprocessor/42921] No error with missing header and -MM
--- Comment #2 from rhansen at bbn dot com 2010-02-08 05:33 --- Reopening; this is a different issue than bug 28435. Chris Demetriou in bug 28435, comment 16 says: FWIW, I actually think that's a different issue (though certainly related). this bug was all about -MD and -MMD -- and what happens when an object file needs to be output, but cannot be because of a missing include. AFAICT, that bug is all about, what should the handling of -MM be vs. missing system headers. That having been said, I will note that with: gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) you get the results: [...@laptop tmp]$ echo #include does_not_exist.h foo.c [...@laptop tmp]$ gcc -MM -MF foo.d foo.c echo succeeded || echo failed foo.c:1:28: does_not_exist.h: No such file or directory failed [...@laptop tmp]$ echo '#include does_not_exist.h' foo.c [...@laptop tmp]$ gcc -MM -MF foo.d foo.c echo succeeded || echo failed foo.c:1:28: does_not_exist.h: No such file or directory failed So this certainly used to behave as the submitter of 42921 expected at *some* point. As of 4.2.2 (the next version I have handy after 3.4.4) the first case reported succeeded (and the second failed). --cgd -- rhansen at bbn dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42921
[Bug middle-end/42860] ICE in gcc-4.4.3 with graphite
--- Comment #2 from spop at gcc dot gnu dot org 2010-02-08 05:50 --- Works with trunk GCC 4.5 at rev. 156585. -- spop at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42860
[Bug bootstrap/42827] error in building libgcc; error: 'BITS_PER_UNIT' undeclared
--- Comment #6 from marekarturpenther at gmail dot com 2010-02-08 05:55 --- Subject: Re: error in building libgcc; error: 'BITS_PER_UNIT' undeclared I can't compile it without 4.3.4, becuase depends could not be compiled by 4.2.4. There is another bug in all versions of gcc: building libada (if I am not wrong), gnatmake using just gcc, even if other exec is forced to be used by using $CC (in my case gcc-4.2.4 with flags), and this effecting in not compatible *.ali files. I will find it and report, but not now, cause I going to work right now. On Sunday 07 February 2010 22:09, pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-07 22:09 --- So I think we are miscompiling GCC with BOOT_CFLAGS set. I don't have access to an x86 machine which could use those CFLAGS so someone else needs to debug this. Can you try 4.4.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42827
[Bug bootstrap/39395] cloog link failure with non-gcc bootstrap compiler
--- Comment #3 from spop at gcc dot gnu dot org 2010-02-08 05:58 --- This should be fixed by now. Please open again this PR if this is still a problem. Sebastian -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39395
