$ gcc -dumpversion
4.1.1
$ g++ -dumpversion
4.1.1
$ gcc -Wall -Wformat-nonliteral format_nonliteral.c
$ g++ -Wall -Wformat-nonliteral format_nonliteral.c
format_nonliteral.c: In function int main(int, char**):
format_nonliteral.c:10: warning: format not a string literal, argument types
not
--- Comment #1 from gcc at gaul dot org 2007-05-06 08:10 ---
Created an attachment (id=13515)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13515action=view)
-Wformat-nonliteral test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31843
--- Comment #3 from pault at gcc dot gnu dot org 2007-05-06 09:34 ---
(In reply to comment #2)
I have not regtested nor developed a testcase and cannot do so until the
weekend.
Sorry about the delay to the weekend. It did not regtest - I have just
popped a new version in to cook.
--- Comment #8 from pcarlini at suse dot de 2007-05-06 10:16 ---
(In reply to comment #6)
Unmodified, 12.cc fails here:
Breakpoint 1, bool test12_auxshort(bool) (integer_type=true)
Nothing changed in the library code for integers, lately, and, moreover, as far
as I can see, the
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
|
--- Comment #9 from pcarlini at suse dot de 2007-05-06 10:29 ---
By the way, I think it would be interesting for anyone working in this area to
know answers for at least some of my questions, e.g., whether hppa-hpux defines
__FLT_HAS_INFINITY__ to 1...
--
--- Comment #20 from steven at gcc dot gnu dot org 2007-05-06 11:10 ---
Re. comment #19: What code size regression? Your comment is too unspecific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #3 from shw_mail at wp dot pl 2007-05-06 12:08 ---
(In reply to comment #2)
http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2006-02/msg00070.html
That's why, missing a small self-contained snippet, this PR will be closed.
Ok. Thanks a lot for
--- Comment #4 from patchapp at dberlin dot org 2007-05-06 12:35 ---
Subject: Bug number PR31540
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00328.html
--
--- Comment #4 from pcarlini at suse dot de 2007-05-06 12:44 ---
Ok, I understand feedback not forthcoming. Otherwise, just re-open.
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #1 from pcarlini at suse dot de 2007-05-06 12:47 ---
This one is happening everywhere, and it's only temporary, expected:
http://gcc.gnu.org/ml/libstdc++/2007-05/msg00019.html
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #10 from paolo at gcc dot gnu dot org 2007-05-06 12:51 ---
Subject: Bug 31836
Author: paolo
Date: Sun May 6 11:51:23 2007
New Revision: 124472
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124472
Log:
2007-05-06 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #11 from pcarlini at suse dot de 2007-05-06 12:55 ---
Sorry about the wrong PR number in my last commit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31836
--- Comment #1 from pcarlini at suse dot de 2007-05-06 12:56 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #15 from hubicka at gcc dot gnu dot org 2007-05-06 15:31
---
The problem with NRV transformation is that it removes the return statement
from default path and keeps it in the catch path making GCOV to properly output
it as unexecuted. I tried to look into the NRV
--- Comment #21 from rearnsha at gcc dot gnu dot org 2007-05-06 15:34
---
(In reply to comment #20)
Re. comment #19: What code size regression? Your comment is too unspecific.
The code size regression that shows up on CSiBE between r123918 and r123919 on
ARM, mips and PPC (at
This testcase:
/gnu $ cat -n vis.cpp
1 int j2 __attribute__ ((visibility (hidden)));
2
3
4
5
6
7
8 int __attribute__ ((visibility (protected))) foo (int bar)
9 {
10return bar + 3;
11 }
12
13
14
15
16
17
18
--- Comment #1 from davek at gcc dot gnu dot org 2007-05-06 16:10 ---
Created an attachment (id=13516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13516action=view)
Testcase as described in summary.
Not preprocessed, but this testcase is not affected by preprocessing anyway.
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-06 16:12 ---
Subject: Bug 31540
Author: pault
Date: Sun May 6 15:12:01 2007
New Revision: 124475
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124475
Log:
2007-05-06 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-05-06 16:13 ---
Subject: Bug 31540
Author: pault
Date: Sun May 6 15:13:11 2007
New Revision: 124476
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124476
Log:
2007-05-06 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from jv244 at cam dot ac dot uk 2007-05-06 16:26 ---
(In reply to comment #1)
*** This bug has been marked as a duplicate of 30965 ***
Still fails for me with today's gfortran:
gfortran -O3 mytest.f90
/tmp/cc6sfSVv.o(.text+0x9f): In function `MAIN__':
: undefined
--- Comment #7 from joel at oarcorp dot com 2007-05-06 17:00 ---
It is definitely a regression against 4.1.2. It is probably a regession
against 4.0. We have been compiling this code with the same compile options
since September 2006 using the latest gcc releases possible.
--
--- Comment #22 from steven at gcc dot gnu dot org 2007-05-06 18:10 ---
Again, please be specific: Please identify the benchmark, the file, maybe even
the function, and extra bonus for figuring out what causes the size to
increase.
I don't understand why you expect anyone to go figure
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-06 18:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-05-06 18:14
---
Also file a new bug for the code size problem and the wrong code issue and link
them to this bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-06 18:31 ---
Added link to patch that should have fixed this bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-06 18:33 ---
By:
2007-04-29 Zdenek Dvorak [EMAIL PROTECTED]
PR rtl-optimization/31676
* df-scan.c (record_nonlocal_goto_receiver_defs): New function.
(df_refs_record): Call it.
On one of the longer tests ( libmudflap.cth/pass40-frag.c ) the testsuite
reports a timeout but looking at the logfile the test seem to be working. My
computer is fairly fast.
I propose that the values be increased for that test.
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00314.html
--
In the first place the .log files are not being created correctly by the
testsuite in all cases.
This results in the test_summary script failing to mail all the errors that
could be reported.
Problem 1):
The boehm-gc tests are not included by the test_summary, script (and never
were
the following patch:
+2007-04-24 Simon Martin [EMAIL PROTECTED]
+
+ PR diagnostic/25923
+ * tree-pass.h (TDF_DIAGNOSTIC): New dump control to specify that a
+ diagnostic message is being built.
+ * tree-pretty-print.c (dump_generic_node): Only write the formatted
text
+
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Printing to dump file broken|[4.3 Regression] Printing to
|
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-06
22:35 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
--- Comment #9 from pcarlini at suse dot de 2007-05-06 10:29 ---
By the way, I think it
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-06
23:07 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
--- Comment #8 from pcarlini at suse dot de 2007-05-06 10:16 ---
(In reply to comment
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-05-06 23:28
---
Subject: Bug 31201
Author: jvdelisle
Date: Sun May 6 22:28:31 2007
New Revision: 124479
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124479
Log:
2007-05-06 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-06 23:31 ---
Yes it is a dup.
*** This bug has been marked as a duplicate of 14258 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-06 23:31 ---
*** Bug 15260 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-05-06 23:32
---
Subject: Bug 31201
Author: jvdelisle
Date: Sun May 6 22:32:33 2007
New Revision: 124480
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124480
Log:
2007-05-06 Jerry DeLisle [EMAIL PROTECTED]
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-05-06 23:37
---
Subject: Bug 31201
Author: jvdelisle
Date: Sun May 6 22:37:27 2007
New Revision: 124481
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124481
Log:
2007-05-06 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-06 23:57
---
Subject: Bug 31764
Author: fxcoudert
Date: Sun May 6 22:56:52 2007
New Revision: 124482
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124482
Log:
PR fortran/31764
* simplify.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-06 23:57
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pcarlini at suse dot de 2007-05-06 23:59 ---
(In reply to comment #13)
Looking at the testresults, 123629 was ok and 123662 has the failure.
There's only one libstdc++ change in this interval:
PR libstdc++/31117
I told you that at the beginning of this
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-05-07 00:04
---
Fixed on mainline.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-07 00:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Compiling genautomata with -O2 on ARM results in a program that segfaults when
run. The problem is in output_min_issue_delay_table. What appears to be
happening is that the RTL loop optimizer is identifying a loop invariant and
hoisting it. However, the particular instance of the invariant
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-07 00:12
---
Created an attachment (id=13517)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13517action=view)
compressed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
--- Comment #2 from rearnsha at gcc dot gnu dot org 2007-05-07 00:14
---
Created an attachment (id=13518)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13518action=view)
assembly output (annotated)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
--- Comment #3 from rearnsha at gcc dot gnu dot org 2007-05-07 00:15
---
Created an attachment (id=13519)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13519action=view)
RTL dump showing invariant hoisting
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31848
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-07 00:17 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-07 00:22 ---
Confirmed, this ICEs with checking turned on, while it causes an infinite loop
without.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||31360
nThis||
Target
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-07 00:24 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from jbuck at gcc dot gnu dot org 2007-05-07 00:32 ---
The return statement, before the optimization, does two things; it causes a
copy constructor call, and it causes the function to return. NVR eliminates
the copy constructor call, but the statement still returns. At
--- Comment #9 from dberlin at gcc dot gnu dot org 2007-05-07 00:37 ---
Subject: Re: [4.2/4.3 Regression] infinite loop in tree-ssa-pre or ICE
I'm waiting till i can actually produce PRE dumps again before i can
debug this :(
On 6 May 2007 23:22:33 -, pinskia at gcc dot gnu dot
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-07
00:51 ---
Subject: Re: [4.3 Regression] FAIL:
27_io/basic_istream/extractors_arithmetic/char/12.cc execution test
I told you that at the beginning of this thread, right? Then, you reported
that
the portion of
--- Comment #16 from pcarlini at suse dot de 2007-05-07 01:02 ---
Ok. I would suggest doing the basic checks, e.g.: build and install the library
itself -O0 and then compile the testcase too -O0; comment out everything in the
main of testcase 12.cc except the line
The fix to PR31360 has caused significant code size regressions on ARM-EABI.
An example of this is from zlib (adler32.c) and is attached, compile with -Os
-mcpu=arm7tdmi -fno-short-enums -w
The new code:
1) Hoists a register containing 0 out of the loop
2) Uses that *only* as a copy into
--- Comment #1 from rearnsha at gcc dot gnu dot org 2007-05-07 01:06
---
Created an attachment (id=13520)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13520action=view)
source code showing regression
compiled code for this file regresses by approximately 3%
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-07 02:29 ---
I see this also on powerpc64 with a cross to spu-elf.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I get a timeout compiling gcc.c-torture/compile/limits-fnargs.c with -O1 and
above. I think this is because SPU has so many register to pass to a function,
that it causes one RTL pass (most likely the register allocator) to go bonkers.
--
Summary:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-07 02:33 ---
It also uses up a lot of memory, 90% of 512 Megs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-07 02:36 ---
1) Hoists a register containing 0 out of the loop
The correct thing to do.
2) Uses that *only* as a copy into another register (mov reg, #0 costs exactly
the same as mov reg, reg)
Interesting, but this is also true
--- Comment #5 from bgoodr+gccbugzilla at gmail dot com 2007-05-07 02:53
---
(In reply to comment #4)
I'm willing to accept this as an OS problem, and I'm just wondering if anyone
else has reported the same problem and if so, what the solution was.
This is happening for me too. It
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-07 03:00 ---
compiling software always taxes the system more than any thing else as it is
using more of the CPU time and memory and disk than most other software. So if
you have an over heating machine or bad memory, you will
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-07 04:14 ---
Yup. So the heuristic to just move everything out of the loop needs another
tweak. This is sort-of the reverse of the problem for Bug 31360.
Adding Mark to put this bug on his radar.
--
steven at gcc dot gnu
--- Comment #7 from bgoodr+gccbugzilla at gmail dot com 2007-05-07 04:19
---
(In reply to comment #6)
compiling software always taxes the system more than any thing else as it is
using more of the CPU time and memory and disk than most other software. ...
Thanks Andrew. I'm coming
--- Comment #1 from daney at gcc dot gnu dot org 2007-05-07 04:23 ---
I just finished bootstrapping and testing r124337 and r124338 on
x86_64-pc-linux-gnu (FC6). Not surprisingly, this verifies that r124338 causes
the regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31842
--- Comment #7 from pault at gcc dot gnu dot org 2007-05-07 05:44 ---
The patch below works and regtests. Before submitting it, however, I would
like to understand why I could not persuade the use of the repeat count to
work, rather than expanding to a full array.
Paul
Index:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-07 06:48
---
Subject: Bug 31694
Author: fxcoudert
Date: Mon May 7 05:48:24 2007
New Revision: 124495
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124495
Log:
PR driver/31694
* c-opts.c
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-07 06:53
---
Subject: Bug 31399
Author: fxcoudert
Date: Mon May 7 05:53:07 2007
New Revision: 124496
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124496
Log:
PR fortran/31399
* trans-stmt.c
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-07 06:53
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-07 06:54
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from akr at m17n dot org 2007-05-07 06:56 ---
I think the problem can be fixed by alloca or setjmp.
* alloca extends a stack as the old stack backchain will not crashed, or
* setjmp saves the stack backchain and longjmp restore it.
I'm not sure that which should be
74 matches
Mail list logo
