http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51544
Matt Hargett changed:
What|Removed |Added
Summary|uninitialized variable |uninitialized variable
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #4 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42283
Matt Hargett changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51769
Bug #: 51769
Summary: bootstrap fails when using -O2 -funswitch-loops
-floop-flatten
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51769
--- Comment #1 from Matt Hargett 2012-01-05 16:03:06 UTC
---
Created attachment 26255
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26255
pre-processed source of the file that triggers the ICE
commandline to trigger the ICE with the attach
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51778
Bug #: 51778
Summary: ICE during bootstrap when adding
-ftree-loop-if-convert-stores to boo
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51542
--- Comment #3 from Matt Hargett 2012-01-23 19:16:12 UTC
---
As I mentioned in the other bug, the specific optimization from -O3 that
triggers this if -fipa-cp-clone.
Is there a reason these patches haven't been applied? Bootstrapping the
compil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51986
Bug #: 51986
Summary: [4.7 regression] uninitialized variable warning
regression prevents bootstrap
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51986
--- Comment #1 from Matt Hargett 2012-01-24 22:31:05 UTC
---
Created attachment 26448
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26448
pre-processed source of the file that triggers the regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
Bug #: 55477
Summary: [devirt] trunk fails inline-devirt tests #2 and and #3
whereas they pass in google/4_7
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
Bug #: 55478
Summary: [devirt] trunk fails inline-devirt test #4
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
Bug #: 55481
Summary: [4.8 regression] -O2 generates a wrong-code infinite
loop in C++Benchmark's simple_types_constant_folding
int8 xor test
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #1 from Matt Hargett 2012-11-27 01:09:28 UTC
---
Created attachment 28784
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28784
zip containing preprocessed source of reduced examples and multiple binaries.
only gcc48-O2 ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481
--- Comment #3 from Matt Hargett 2012-11-27 02:11:29 UTC
---
Actually, the same problem happens at -O3 with const int SIZE > 20.
base_iterations can be very high; it's just SIZE that's the problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
--- Comment #7 from Matt Hargett 2012-11-27 17:32:01 UTC
---
I'll rewrite the test to add a loop that hopefully triggers it as hot at -O3
(and gets unrolled). shouldn't it inline at -O2 since DCE would eliminate the
function body and make
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
--- Comment #4 from Matt Hargett 2012-11-27 17:37:01 UTC
---
I'll add a loop to the test that hopefully triggers the inlining (and does the
unrolling).
Adding both variants (renamed main and with loop) to the test suite would be
fantast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
Bug #: 55498
Summary: [devirt] trunk fails inline-devirt test #6
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499
Bug #: 55499
Summary: [devirt] trunk fails to eliminate dead functions where
all call sites were inlined
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499
--- Comment #1 from Matt Hargett 2012-11-27 22:26:28 UTC
---
Created attachment 28800
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28800
test case that devirtualizes correctly, but DCE fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
Bug #: 55500
Summary: [devirt] trunk fails inline-devirt test #7
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670
--- Comment #10 from Matt Hargett 2012-12-03 23:17:22 UTC
---
I no longer have access to the source tree that exhibited this problem, but it
was likely the same as the qemu issue referenced earlier. Feel free to resolve
as fixed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45700
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628
Matt Hargett changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398
--- Comment #1 from Matt Hargett 2012-12-03 23:20:57 UTC
---
loop flattening was removed as a feature, yes? If so, this bug can be closed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670
Matt Hargett changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50468
Matt Hargett changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595
Bug #: 55595
Summary: [google] r172952 (LIPO) broke profiledbootstrap on
google/main, and later in google/gcc-4_7
Classification: Unclassified
Product: gcc
Version: unkn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55596
Bug #: 55596
Summary: [google] r191813 broke bootstrap-lto on google/gcc-4_7
branch
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55074
Matt Hargett changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51233
--- Comment #5 from Matt Hargett 2012-12-04 20:35:09 UTC
---
ping? if you're more comfortable with relegating multiple passes to LTO, I
think that's a good starting point. we can wait for a per-unit C++ template
case to come up after that'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55595
--- Comment #2 from Matt Hargett 2012-12-05 00:06:47 UTC
---
I'm not trying to use google/main, but rather google/gcc-4_7. I got to the
beginning of the 4.7 branch and was still getting the error, so I traced it
back to google/main. If you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55596
--- Comment #2 from Matt Hargett 2012-12-05 00:56:56 UTC
---
We have a large C++ application that was working with LTO in google/gcc-4_6,
and now we're running into issues on google/gcc-4_7. We saw performance gains
and binary size decreas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
Bug #: 55644
Summary: profiledbootstrap fails on current trunk
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644
Matt Hargett changed:
What|Removed |Added
Summary|profiledbootstrap fails on |bootstrap-lto fails on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
--- Comment #5 from Matt Hargett 2012-12-17 19:12:11 UTC
---
Just verified this still happens in 4.7 and trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
--- Comment #2 from Matt Hargett 2012-12-17 23:34:08 UTC
---
Would iterating during LTO work in this instance, or would it need to happen
during early IPA?
is stage3 too late for the IPA-CP enhancement you mention?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
--- Comment #6 from Matt Hargett 2012-12-18 17:26:54 UTC
---
Applying the supplied patch reveals another issue underneath, which is a false
positive:
/work/mhargett/gcc-trunk-obj/./prev-gcc/xg++
-B/work/mhargett/gcc-trunk-obj/./prev-gcc/
-B/u/m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50148
--- Comment #7 from Matt Hargett 2013-01-07 22:14:21 UTC
---
This appears to be resolved for me, as of r194995. If someone with permissions
can mark as RESOLVED, I'll VERIFY.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
Matt Hargett changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #13 from Matt Hargett 2013-01-17 18:28:18 UTC
---
No.
4.6 doesn't devirt (at -O2 or -O3) and therefore the DCE isn't relevant.
At both -O2 and -O3, with and without -fwhole-program, both with and without
adjustin declarat
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 t
--- Comment #12 from matt at use dot net 2010-02-10 01:26 ---
I haven't had any issues come up with this in the last month, testing with a
new profiledbootstrap of GCC trunk every week or so. Can this be backported to
4.4 now? Or is there some specific testing you'd like me
--- Comment #7 from matt at use dot net 2010-02-11 20:36 ---
Should this fix also be backported to 4.4? I'll test your fix this weekend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930
IRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-
--- Comment #1 from matt at use dot net 2010-03-05 20:22 ---
Created an attachment (id=20031)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20031&action=view)
compilation unit that reproduces the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #2 from matt at use dot net 2010-03-05 20:33 ---
This occurs with both gcc 4.4.1 and 4.5.0.20100304.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #4 from matt at use dot net 2010-03-05 22:17 ---
It's not the fact that it's zero-sized in and of itself, but rather the
assignment to contents[0] in the ctor should trigger the warning. Oddly,
PC-Lint warns of the zero-sized array, but not the actual overflow.
As
--- Comment #6 from matt at use dot net 2010-03-05 23:24 ---
I see your point about supporting existing code that uses this feature in the
way you describe.
I modified the example to not rely upon zero-length array and have attached it.
(The bug in the original code didn't use it
--- Comment #7 from matt at use dot net 2010-03-05 23:25 ---
Created an attachment (id=20032)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20032&action=view)
updated example that doesn't rely on zero-length arrays
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43270
--- Comment #9 from matt at use dot net 2010-03-06 00:18 ---
Alright. Even though PC-Lint now correctly warns, and GCC still does not, I
have updated the attached example yet again to avoid the next constraint you
mention.
GCC still does not detect the array-bounds issue, even when the
--- Comment #10 from matt at use dot net 2010-03-06 00:19 ---
Created an attachment (id=20033)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20033&action=view)
yet another example, that does not rely on zero-length arrays or on the array
being the 'last' field in
--- Comment #12 from matt at use dot net 2010-03-06 01:31 ---
Changing contents[size] to contents[size + 10] or to contents[size+1] is
still not triggering the array-bounds warning in any of the compilers I tested
(previously mentioned). In my real code, it was an OB1 bug, so that
--- Comment #1 from matt at use dot net 2010-04-15 18:21 ---
I'm hitting the same thing when bootstrapping 4.5 on Ubuntu 9.10 using GCC
4.4.1:
../../gcc-4.5-20100408/gcc/fold-const.c: In function fold_checksum_tree:
../../gcc-4.5-20100408/gcc/fold-const.c:14251:3: error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55499
Matt Hargett changed:
What|Removed |Added
Component|middle-end |ipa
Version|4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55477
Matt Hargett changed:
What|Removed |Added
Status|NEW |RESOLVED
Version|4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55478
Matt Hargett changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
Matt Hargett changed:
What|Removed |Added
Version|4.8.0 |4.9.0
--- Comment #5 from Matt Hargett --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
Matt Hargett changed:
What|Removed |Added
Version|4.8.0 |4.9.0
--- Comment #2 from Matt Hargett --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
--- Comment #4 from Matt Hargett ---
Phillip, the problem is not that the program doesn't run properly. It's that
the code isn't inline via de-virtualization when it could be. The main() should
contain a few printf/puts calls and nothing more.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at use dot net
Created attachment 34929
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34929&action=edit
pre-processed source file that reproduces the crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65289
--- Comment #1 from Matt Hargett ---
Also reproducible with -O2 -fgraphite-identity .
I use both of these optimizations regularly to help get the most out of
prefetch on the embedded ARM targets I work on.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66068
Matt Hargett changed:
What|Removed |Added
CC||matt at use dot net
--- Comment #5 from
ent: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42282
oduct: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC
--- Comment #2 from matt at use dot net 2009-12-07 20:40 ---
Pre-processed output attached. I'm having some trouble getting it to crash
consistently, but here is the valgrind output that might indicate the problem:
==26996== Conditional jump or move depends on uninitialised va
--- Comment #3 from matt at use dot net 2009-12-07 20:41 ---
Created an attachment (id=19252)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19252&action=view)
pre-processed source
pre-processed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42282
ole-
program
Product: gcc
Version: 4.5.0
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
--- Comment #23 from matt at use dot net 2009-12-31 01:44 ---
I just ran into a bug that this feature would have found for me at
compile-time. Instead, it required exercising the code under valgrind, which
took quite some time. If voting were enabled, I would vote for this bug
arrays
Product: gcc
Version: 4.5.0
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
--- Comment #1 from matt at use dot net 2009-12-31 02:15 ---
Created an attachment (id=19428)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19428&action=view)
source file
to replicate (-O3 is required, would be nice if it just worked with -O2):
g++ -O3 -Wall -c gcc-
--- Comment #3 from matt at use dot net 2009-12-31 19:49 ---
Created an attachment (id=19432)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19432&action=view)
slightly different example that eliminates heap dependency
to reproduce:
g++ -O3 -Wall gcc-missing-uninit.cpp
--- Comment #4 from matt at use dot net 2009-12-31 19:53 ---
It seems like this analysis would succeed if the intrinsic memcpy for copying
the [2] and [4] were inlined before this analysis. Is there a reason that the
intrinsic version of memcpy isn't substituted in before this ana
: 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_6
--- Comment #1 from matt at use dot net 2010-01-01 21:02 ---
Created an attachment (id=19439)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19439&action=view)
pre-processed output of the file that emitted the warning
commandline:
g++-4.4
-Wp,-MMD,"engines/saga/.deps
--- Comment #2 from matt at use dot net 2010-01-01 21:16 ---
sorry, I lied. This is still an issue in GCC 4.5.20091228.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #8 from matt at use dot net 2010-01-03 19:57 ---
can this be backported to 4.4 as well so I can integrate it into our 4.4-based
toolchain?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #14 from matt at use dot net 2010-01-03 20:30 ---
Still happening on 4.5.0 20091228 (and gcc 4.4.1) on Ubuntu 9.10/amd64). I
found that it goes away in 3 separate instances when turning on
-finline-functions. The last 2 instances of memory corruption I am running into
are
--- Comment #10 from matt at use dot net 2010-01-04 01:04 ---
what I mean to ask is: can this fix be committed to the 4.4 branch? I'd prefer
to minimize the number of local patches we apply to our custom build.
Thanks for the quick fix, by the way! :)
--
http://gcc.gn
re not handled by the RTL oracle
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
http://gcc.
o: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628
X-Bugzilla-Reason: CC
--- Comment #1 from matt at use dot net 2010-01-05 23:10 ---
Created an attachment (id=19479)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19479&action=view)
pre-processed source of the file that evokes the crash during bootstrap
--
http://gcc.
--- Comment #2 from matt at use dot net 2010-01-05 23:28 ---
dyncast.cc, eh_call.cc, eh_personality.cc, guard.cc, and vmi_class_type_info.cc
all exhibit the same problem.
--
matt at use dot net changed:
What|Removed |Added
--- Comment #4 from matt at use dot net 2010-01-08 19:32 ---
The crash doesn't happen with:
CFLAGS="-g -O3" CXXFLAGS="-g -O3" ../gcc-trunk/configure --prefix=/home/matt
--enable-gold --enable-build-with-cxx --enable-lto --enable-stage1-checking=all
--disable-w
--- Comment #5 from matt at use dot net 2010-01-09 00:22 ---
This also happens with CFLAGS="-O2 -g" and CXXFLAGS="-O2 -g". I'll try
disabling the as-cxx configure option to see if that is the culprit, as odd as
that would be.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628
--- Comment #6 from matt at use dot net 2010-01-09 01:32 ---
Yup, the problem appears to be brought about when configuring with
--enable-build-with-cxx. I tried to work through the c++-compat warnings to try
and figure out which one could be the culprit (if any), but didn't see any
--- Comment #11 from matt at use dot net 2010-01-10 22:01 ---
I get this same problem when compiling scummvm (http://scummvm.org) on Ubuntu
9.10/amd64 using the default GCC 4.4.1:
g++ -O1 -finline-small-functions -finline-functions
-Wp,-MMD,"engines/sci/.deps/console.d",-M
--- Comment #8 from matt at use dot net 2010-01-10 22:04 ---
Created an attachment (id=19531)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19531&action=view)
pre-processed output of the file that emitted the false positive using the
commandline mentioned in my
--- Comment #12 from matt at use dot net 2010-01-10 23:29 ---
Created an attachment (id=19533)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19533&action=view)
pre-processed output of the file that emitted the false positive using the
commandline mentioned in my
--- Comment #6 from matt at use dot net 2010-01-13 20:07 ---
Does this relate to PR42617?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42716
--- Comment #9 from matt at use dot net 2010-01-14 20:05 ---
The configure command:
../gcc-trunk/configure --prefix=/home/matt --enable-gold
--enable-build-with-cxx --enable-lto --enable-stage1-checking=all
--disable-werror --enable-bootstrap --enable-languages=c,c++,lto
I then adjust
normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matt at use dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu
y: matt at use dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930
--- Comment #1 from matt at use dot net 2010-02-01 22:24 ---
I have narrowed it to the following commandline (-O1 -floop-block):
~/src/scummvm$ /home/matt/bin/g++
-Wp,-MMD,"engines/cine/.deps/gfx.d",-MQ,"engines/cine/gfx.o",-MP -Wall -O1
-floop-blo
--- Comment #2 from matt at use dot net 2010-02-01 22:25 ---
Created an attachment (id=19781)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19781&action=view)
pre-processed source file that causes the crash
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42930
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48028
Summary: [4.4 Regression] undeserved uninitialized variable
warning regression since 4.4.2
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48028
--- Comment #1 from Matt Hargett 2011-03-08 00:06:26 UTC
---
Created attachment 23580
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23580
pre-processed source of the file that triggers the -Wuninitialized warning
regression on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42371
--- Comment #9 from Matt Hargett 2011-03-16 21:43:56 UTC
---
Now that 4.7 stage 1 is open, let me know if there's anything else I can
reasonably provide to provide examples, testing, etc. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48346
Summary: ICE when compiling a specific file with both -g and
-flto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
Summary: [4.6 regression] miscompilation at -O3
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48377
--- Comment #2 from Matt Hargett 2011-04-01 01:38:20 UTC
---
(In reply to comment #1)
> Does the issue reproduce without using -ftree-loop-linear? In general try
> to avoid loads of -f switches and stick to basic (and well tested) -Ox
> options.
101 - 200 of 238 matches
Mail list logo