--- Comment #9 from patrick at motec dot com dot au 2010-04-30 06:57
---
Khem,
Your libgcc.a looks fine. As far as I know, libgcc.a is supposed to be the last
library listed when linking so the behaviour you are seeing is normal.
My problem is that libgcc.a does not contain _savegpr_*
--- Comment #7 from pault at gcc dot gnu dot org 2010-04-30 06:51 ---
Fixed on trunk.
Thanks for the help, Salvatore - I hope that it will continue.
Paul and Janus
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pzhao at gcc dot gnu dot org 2010-04-30 06:16 ---
Subject: Bug 43779
Author: pzhao
Date: Fri Apr 30 06:16:26 2010
New Revision: 158919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158919
Log:
2010-04-30 Shujing Zhao
PR c++/43779
* typeck
--- Comment #3 from david at rothlis dot net 2010-04-30 06:05 ---
> a function with a missing return is valid
I just can't reconcile that with the following line from the C++ standard: "It
is now invalid to return (explicitly or implicitly) from a function which is
declared to return a
--- Comment #6 from igodard at pacbell dot net 2010-04-30 05:28 ---
I guess I'm still not being clear. I'm not using *any* of those names; I'm not
using C; I'm not using POSIX. I'm only using ostream, which is a plain old C++
library, but when I include I'm getting C library functions l
--- Comment #8 from raj dot khem at gmail dot com 2010-04-30 04:55 ---
below is the linker command that reports liking error.
/scratch/oe/efika/cross/ppc603e/lib/gcc/powerpc-oe-linux/4.5.0/crtend.o: In
function `__do_global_ctors_aux':
crtstuff.c:(.text+0xc): undefined reference to `_sa
--- Comment #7 from raj dot khem at gmail dot com 2010-04-30 04:34 ---
calls to _savegpr_31 and _restgpr_31_x are only generated when compiling libgcc
with -Os same compiled with -O2 it does not emit the calls
here is a reduced testcase from crtstuff.c compile it will -Os and then with
--- Comment #5 from jason at gcc dot gnu dot org 2010-04-30 04:23 ---
Subject: Bug 43890
Author: jason
Date: Fri Apr 30 04:23:00 2010
New Revision: 158918
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158918
Log:
PR c++/43890
* init.c (diagnose_uninitialized_cst
--- Comment #6 from raj dot khem at gmail dot com 2010-04-30 04:13 ---
I have similar problem when building glibc for 603e. When I dump libgcc.a
then it shows these symbols but they are hidden
crtsavfpr.o: file format elf32-powerpc
g F .text 004c .hidden _savefpr_1
--- Comment #16 from kargl at gcc dot gnu dot org 2010-04-30 03:23 ---
(In reply to comment #15)
> (In reply to comment #13)
> > Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460
> > [edit] [edit] ?
>
> Compare choose_tmpdir() in libiberty/make_temp_file.c
>
Can
--- Comment #15 from dannysmith at users dot sourceforge dot net
2010-04-30 03:02 ---
(In reply to comment #13)
> Kai, what about the GetTempPath? Cf. the rough draft in attachment 20460
> [edit] ?
Compare choose_tmpdir() in libiberty/make_temp_file.c
Danny
--
http://gcc.gnu.org
--- Comment #5 from paolo dot carlini at oracle dot com 2010-04-30 01:03
---
Note that Jon closed the PR as WONTFIX not as INVALID. If you are more happy
then let's keep it open, but for sure *nothing* will happen for a looonn
time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-30 01:02 ---
hiding them behind an adaptor function has a cost and personally I don't think
it's worth fixing which is why I closed it as WONTFIX
I'll leave it open but I'm not interested in fixing it.
It's nothing to do with mixin
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-30 00:31 ---
(In reply to comment #0)
> Here is the concerning part of the log.
> In all-stageprofile-target-libgcc:
> building _moddi3.o
> ...
> ../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function '__moddi3':
> ../../../gcc-4
--- Comment #7 from beebe at math dot utah dot edu 2010-04-30 00:23 ---
Subject: Re: Erroneous expansion of __asm__() directive
I accept the explanation of the problem with my sample __asm__()
directive, and I think that we can close my bug report at
http://gcc.gnu.org/bugzill
--- Comment #17 from hjl dot tools at gmail dot com 2010-04-29 23:57
---
(In reply to comment #13)
> Created an attachment (id=20520)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20520&action=view) [edit]
> patch2
>
> Alternative patch for auto_var_in_fn_p
>
I think auto_var_i
--- Comment #16 from hjl dot tools at gmail dot com 2010-04-29 23:53
---
Another testcase
---
char *
bar (void)
{
extern char ext[];
return ext;
}
char *
foo (void)
{
return bar ();
}
--
#2 0x00cecc94 in can_be_nonlocal (decl=0x7190b0a0,
id=0x7fffdba0) at /
--- Comment #3 from igodard at pacbell dot net 2010-04-29 23:35 ---
Reopened, because comment#2 mistakes the problem. I don't want to get anything
included into namespace std. However, I also do not want tyo get C header names
imported into my application's global space merely because I
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-29 23:16 ---
it would be wrong to declare e.g. open(2) and close(2) in namespace std because
they are not part of ISO C++, they are part of your OS
If you are referring to ISO C names which get included in the global namespace
such
--- Comment #75 from dirtyepic at gentoo dot org 2010-04-29 22:58 ---
if some libraries, (zlib and fontconfig i've had personal experience with, i've
also heard libgcrypt) are compiled with -ftree-vectorize (ie. -O3) on x86
systems supporting SSE2, it causes segfaults in certain packages
--- Comment #10 from redi at gcc dot gnu dot org 2010-04-29 22:56 ---
(In reply to comment #9)
> you're throwing a string literal and trying to catch a char*, that's invalid
I should clarify that - it's not invalid to TRY to catch a char* but it will
fail, and the program will terminate
--- Comment #9 from redi at gcc dot gnu dot org 2010-04-29 22:55 ---
you're throwing a string literal and trying to catch a char*, that's invalid
if you change it to catch(const char*) it works fine with 4.4.3
--
redi at gcc dot gnu dot org changed:
What|Removed
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||diagnostic
--- Comment #7 from redi at gcc dot gnu dot org 2010-04-29 22:29 ---
compiles without error using 4.4.3 and 4.6.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from jarrydb at cse dot unsw dot edu dot au 2010-04-29
21:57 ---
that fixes it for me on x86 and x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43890
--- Comment #7 from bernds at gcc dot gnu dot org 2010-04-29 21:37 ---
Subject: Bug 42895
Author: bernds
Date: Thu Apr 29 21:37:01 2010
New Revision: 158911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158911
Log:
PR target/42895
* doc/tm.texi (ADJUST_REG_ALLOC
--- Comment #1 from hp at gcc dot gnu dot org 2010-04-29 21:16 ---
I'm unsure whether I should tag along on this PR, because the failing range
(last_worked:first_failed) for cris-elf is 158755:158765, which doesn't include
158610. But, I'm doing it anyhow. From gcc-restresults@ it looks
--- Comment #9 from joel at gcc dot gnu dot org 2010-04-29 21:03 ---
Still broken.
| 4.6.0 20100428 (experimental) [trunk revision 158844] (arm-unknown-rtems4.10)
GCC error:|
| in find_valid_class, at reload.c:704 |
| Error detected around a-ngcefu.ad
Here is the concerning part of the log.
In all-stageprofile-target-libgcc:
building _moddi3.o
...
../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c: In function '__moddi3':
../../../gcc-4.5.0/libgcc/../gcc/libgcc2.c:1103:1: error: total size of local
objects too large
The same kind of configuration built
--- Comment #15 from jakub at gcc dot gnu dot org 2010-04-29 20:46 ---
All the patches so far completely untested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43942
--- Comment #14 from jakub at gcc dot gnu dot org 2010-04-29 20:46 ---
Created an attachment (id=20521)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20521&action=view)
patch3
Patch to allow vars with non-vla types to be nonlocal if they weren't used and
their type hasn't been rem
--- Comment #13 from jakub at gcc dot gnu dot org 2010-04-29 20:45 ---
Created an attachment (id=20520)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20520&action=view)
patch2
Alternative patch for auto_var_in_fn_p
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43942
--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-29 20:40 ---
Created an attachment (id=20519)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20519&action=view)
patch1
Patch for tree-tailcall.c, only useful if the second patch isn't used.
--
http://gcc.gnu.org/bugzill
--- Comment #6 from hp at gcc dot gnu dot org 2010-04-29 20:40 ---
Well, guess what, cris-elf too!
Worked with 158780, failed with 158788 (and after) as in the description,
except the line number I see for r158788 is 10648; I'm guessing the description
is from 158793 or later.
--
hp
--- Comment #17 from dougmencken at gmail dot com 2010-04-29 20:40 ---
(In reply to comment #16)
>
> This means you didn't install libgcc.
>
So can you please tell me how to "install libgcc" then? I posted all options I
sent to ./configure for each 4.4.2, 4.4.3 and 4.5.0. I also posted
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-29 20:40 ---
Fixed by revision 158567:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00673.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #2 from redi at gcc dot gnu dot org 2010-04-29 20:36 ---
that should be -Werror=return-type
but spelling aside, this is not a bug now
the compiler MUST NOT reject it by default, since a function with a missing
return is valid as long as the caller does not use the (missing
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-29 20:31 ---
-Werror=Wreturn-type will turn just that warning into an error message in
recent GCC's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-29 20:29 ---
So, the first difference that happens is that with -g the extern var is removed
from BLOCK_VARs, with -g it is kept there. This happens in
remove_unused_scope_block_p. Next during inlining in remap_decls
can_be_nonl
I know that dozens of bugs have been opened for this over the years, but please
read this through.
If you have a C++ program missing a return statement from a function that is
supposed to return a value, g++ will compile it happily with no errors (or even
a warning, unless -Wreturn-type or -Wall i
--- Comment #14 from armin76 at gentoo dot org 2010-04-29 19:36 ---
I tried to bisect it, however there is an issue:
gcc failed to build since
http://repo.or.cz/w/official-gcc.git/commit/598767c938d0d001bbbe41e0a189104bb53e3580
Gives this error:
/root/build/./prev-gcc/xgcc -B/root/buil
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-29 19:23 ---
That doesn't sound like the right fix.
I'll look into this.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from hjl dot tools at gmail dot com 2010-04-29 19:16 ---
This patch
---
diff --git a/gcc/tree.c b/gcc/tree.c
index 8eeecff..0d79020 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -7937,7 +7937,8 @@ auto_var_in_fn_p (const_tree var, const_tree fn)
{
return (DECL_P (var) &
--- Comment #13 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 43326
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* sym
--- Comment #16 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 43896
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* sym
--- Comment #6 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 41829
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* symb
--- Comment #33 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 42353
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* sym
--- Comment #8 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 43492
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* symb
--- Comment #38 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 42274
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* sym
--- Comment #13 from pault at gcc dot gnu dot org 2010-04-29 19:11 ---
Subject: Bug 42680
Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29 Janus Weil
PR fortran/43896
* sym
--- Comment #24 from tkoenig at gcc dot gnu dot org 2010-04-29 19:09
---
(In reply to comment #22)
> It is my intention to change the array descriptor representation and
> to start with an API that provides the (lbound, ubound,stride) values.
> In fact, this API has already been put i
--- Comment #8 from hjl dot tools at gmail dot com 2010-04-29 18:44 ---
Tail call optimization doesn't handle
# DEBUG event => 0
properly.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-29 18:27 ---
Even more reduced testcase:
invoke_plugin_callbacks (int event)
{
extern unsigned char flag_plugin_added;
return invoke_plugin_callbacks_full (event);
}
ggc_collect (void)
{
invoke_plugin_callbacks (0);
}
--
--- Comment #6 from hjl dot tools at gmail dot com 2010-04-29 18:26 ---
-foptimize-sibling-calls is affected by external declaration in function.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #5 from hjl dot tools at gmail dot com 2010-04-29 18:23 ---
Tail call optimization is disabled with -g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43942
--- Comment #4 from hjl dot tools at gmail dot com 2010-04-29 18:18 ---
It also failed with gcc 4.5.0.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-04-29 18:16 ---
[...@gnu-6 stage2-gcc]$ cat x.i
enum plugin_event { PLUGIN_GGC_START, PLUGIN_GGC_END };
extern int invoke_plugin_callbacks_full (int, void *);
static __inline__ int
invoke_plugin_callbacks (int event __attribute__ ((
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-29 18:05 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43942
--- Comment #15 from hjl dot tools at gmail dot com 2010-04-29 17:59
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|NEW
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-29 17:57 ---
Created an attachment (id=20518)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20518&action=view)
A testcase
On Linux/x86-64,
[...@gnu-6 stage2-gcc]$ ./xgcc -B./ -c -g -O2 -Wc++-compat -fno-common
pr43942.i
>From PR 43936, -fcompare-debug failed with external declaration in function.
--
Summary: -fcompare-debug faulure
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assig
--- Comment #14 from hjl at gcc dot gnu dot org 2010-04-29 17:55 ---
Subject: Bug 43936
Author: hjl
Date: Thu Apr 29 17:55:00 2010
New Revision: 158909
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158909
Log:
Correct entry of fix for PR bootstrap/43936.
Modified:
trunk/gc
--- Comment #5 from hjl at gcc dot gnu dot org 2010-04-29 16:29 ---
Subject: Bug 43935
Author: hjl
Date: Thu Apr 29 16:29:10 2010
New Revision: 158905
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158905
Log:
Move flag_plugin_added out of invoke_plugin_callbacks.
2010-04-29 H
--- Comment #7 from andris dot pavenis at iki dot fi 2010-04-29 16:27
---
I had similar patch for this file when I last built GCC for DJGPP (gcc-4.4.2 as
native compiler and gcc-4.4.3 as cross-compiler). The version
for gcc-4.4.2 is in archive
http://ap1.pp.fi/djgpp/gcc/4.4.2/src/gcc
Managed to build gmp-5.0.1, mpfr-2.4.2, and mpc-0.8.1 with gcc-4.2.4/64 (all
-mlp64). Had to set $ABI to 64 to make that pass.
Due to the endless annoying libtool, building with HP C-ANSI-C was impossible.
With that triplet installed, and hand-forced iconv to be unavailable
(--disable-nls does no
--- Comment #13 from hjl dot tools at gmail dot com 2010-04-29 15:57
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01827.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #12 from hjl dot tools at gmail dot com 2010-04-29 15:38
---
I am testing this patch:
--
diff --git a/gcc/plugin.h b/gcc/plugin.h
index 94663dd..3269641 100644
--- a/gcc/plugin.h
+++ b/gcc/plugin.h
@@ -35,6 +35,8 @@ extern void print_plugins_versions (FILE *file, const char
--- Comment #11 from jakub at gcc dot gnu dot org 2010-04-29 15:37 ---
No, otherwise -fcompare-debug or even the whole bootstrap comparison which
compares -g -gtoggle built stage2 with -g built stage3 would fail much more
often.
Strangely, I saw the comparison failure on the trunk, but
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-29 15:37
---
And the bug is:
struct TBL tbl = { foo };
but:
Generating constraints for global initializers
...
tbl = NONLOCAL
tbl = &NULL
ouch. I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
--- Comment #10 from hjl dot tools at gmail dot com 2010-04-29 15:31
---
Do we do inline differently with and without -g?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43936
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-29 15:29 ---
Wow, thanks for the testcase!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
--- Comment #9 from hjl dot tools at gmail dot com 2010-04-29 15:29 ---
Also those failed files call invoke_plugin_callbacks.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from nisselarsson at home dot se 2010-04-29 15:21 ---
I can confirm that the patch above applies and gcc-4.5 now complies
successfully.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43921
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-04-29 15:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-04-29 15:10 ---
because we build with bootstrap-debug by default.
Bootstrap works fine for me with and without --enable-plugin.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-04-29 15:03 ---
Subject: Bug 43620
Author: jakub
Date: Thu Apr 29 15:03:38 2010
New Revision: 158903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158903
Log:
PR other/43620
libgomp/
* configure.ac (AM_INIT_A
For
int main()
{
void *p = __builtin_malloc (4);
if (p)
{
__builtin_free (p);
p = 0;
}
__builtin_free (p);
return 0;
}
DOM does not propagate p == 0 on the else path leaving
:
p_2 = __builtin_malloc (4);
if (p_2 != 0B)
goto ;
else
goto ;
:
__builtin_f
--- Comment #7 from hjl dot tools at gmail dot com 2010-04-29 14:47 ---
For some reason, c-decl.o in stage2 has no debug sections:
There are 16 section headers, starting at offset 0x1fbf8:
Section Headers:
[Nr] Name Type Address Offset
Size
--- Comment #6 from dominiq at lps dot ens dot fr 2010-04-29 14:39 ---
> On rs6000, the miscompare seems to start at revision 158633 ...
I think what you see at revision 158633 is a bootstrap failure due to a missing
prototype in optabs.h, fixed with revision 158643. Meanwhile revision
--- Comment #119 from bergner at gcc dot gnu dot org 2010-04-29 14:34
---
Subject: Bug 26854
Author: bergner
Date: Thu Apr 29 14:34:35 2010
New Revision: 158902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158902
Log:
Backport from mainline.
2009-08-30 Alan
--- Comment #113 from bergner at gcc dot gnu dot org 2010-04-29 14:34
---
Subject: Bug 33928
Author: bergner
Date: Thu Apr 29 14:34:35 2010
New Revision: 158902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158902
Log:
Backport from mainline.
2009-08-30 Alan
--- Comment #15 from bergner at gcc dot gnu dot org 2010-04-29 14:34
---
Subject: Bug 41081
Author: bergner
Date: Thu Apr 29 14:34:35 2010
New Revision: 158902
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158902
Log:
Backport from mainline.
2009-08-30 Alan M
--- Comment #3 from burnus at gcc dot gnu dot org 2010-04-29 14:34 ---
The issue is that
a.dim[]
is too small, which was traced by Alexander Monakov (thanks!).
This is in turn due to:
gfc_get_array_descriptor_base (int dimen, int codimen, bool restricted)
{
int idx = 2 * (dime
--- Comment #6 from redi at gcc dot gnu dot org 2010-04-29 14:17 ---
for further confirmation, the original case is covered by:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#367
and my cases are covered by:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#236
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-29 14:16 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43937
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43938
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-29 14:11 ---
the definition of integral constant expression has changed between C++03 and
C++0x, so that int() is a valid integral constant expression, as is int(b?0:0)
So that makes my 'f' and 'g' examples valid.
However, by [exp
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-29 14:11 ---
Subject: Bug 43935
Author: rguenth
Date: Thu Apr 29 14:10:39 2010
New Revision: 158901
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158901
Log:
2010-04-29 Richard Guenther
PR bootstrap/43935
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-29 14:10 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #5 from dominiq at lps dot ens dot fr 2010-04-29 13:50 ---
> ... and a SEGV configuring libgcc at rev 158639.
This is probably pr43858 and it should be fixed by revision 158898.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43936
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-29 13:49 ---
Created an attachment (id=20516)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20516&action=view)
Assembler (x86-64-linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43931
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-29 13:49 ---
Created an attachment (id=20515)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20515&action=view)
142t.optimized dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43931
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-29 13:34 ---
That example 'f' is equivalent to this, which also compiles:
int* g(bool b) { return int(b ? 0 : 0); }
that's /definitely/ wrong
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43932
--- Comment #3 from redi at gcc dot gnu dot org 2010-04-29 13:31 ---
See [expr.cond]p2
if one operand is a throw-expression the result of the conditional-expression
is an rvalue of the type of the other operand (i.e. int)
I think it's actually a bug that this compiles:
int* f(bool b) {
--- Comment #4 from dje at gcc dot gnu dot org 2010-04-29 13:29 ---
On rs6000, the miscompare seems to start at revision 158633 and a SEGV
configuring libgcc at rev 158639.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43936
--- Comment #3 from dje at gcc dot gnu dot org 2010-04-29 13:25 ---
rs6000 also is experiencing stage 2/3 comparison failures on both Linux and
AIX.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-29 13:24 ---
Revision 158854:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00961.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
On Linux/x86, revision 158895 gave
FAIL: gcc.dg/lto/const-uniq c_lto_const-uniq_0.o-c_lto_const-uniq_1.o link
Revision 158852 is OK.
--
Summary: [4.6 regression] gcc.dg/lto/const-uniq c_lto_const-
uniq_0.o-c_lto_const-uniq_1.o link
Product: gcc
1 - 100 of 139 matches
Mail list logo
