--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org |
Status|NEW
and the current 4.0 branch with:
elm3b11% /opt/gcc-nightly/4.0/bin/g++ -c bug.cc
/home/gcc-nightly/4.0-20050913/bin/../lib/gcc/powerpc64-linux/4.0.2/../../../../include/c++/4.0.2/ostream:
In member function std::basic_ostream<_
Using gcc -O2 -fdump-tree-all -S
to compile:
int bar (void) { return 0;}
int foo (int reject) { int result = 0; return result;}
the .t02.original dump looks like:
;; Function bar (bar)
;; enabled by -tree-original
{
return 0;
}
;; Function foo (foo)
;; enabled by -tree-original
{
int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:26 ---
Confirmed, a regression from 3.4.0. Just a note, 4.0 branch is frozen right
now.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:28 ---
>int result = 0; <--- this line appears twice...
That is because there is DECL_EXPR there and you just don't see it.
This is all really a front-end issue.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:31 ---
Confirmed, just the subreg issue.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
20:32 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 20:45 ---
The fact that the dump is different depending on function order or compilation
flags seems to point to either an uninitialized variable or some memory
corruption.
--
http://gcc.gnu.org/bugzil
--- Additional Comments From fjahanian at apple dot com 2005-09-13 21:09
---
Hello,
What is the status of Uros's patches in:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html
Looks like they did not make it to FSF mainline? Are there remaining issues
with them?
--
http://
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
21:13 ---
(In reply to comment #13)
> Are there remaining issues with them?
Yes, it does not work when configuring gcc with --with-cpu=pentium4 see PR
19161.
--
What|Removed |Add
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-13
21:46 ---
Subject: Bug 17740
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-13 21:46:04
Modified files:
gcc/fortran: ChangeLog trans-expr.c
gcc/t
--- Additional Comments From jaffe at broad dot mit dot edu 2005-09-13
22:03 ---
We recompiled gcc 4.1.0 with checking disabled. The results are now less
dramatic but still of concern: optimized 4.1.0 compiles take about twice as
long as 3.4.3 compiles on the test case:
Compile time
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
22:09 ---
Can you run with -ftime-report and attach the results?
--
What|Removed |Added
Keyw
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
22:18 ---
tree alias analysis : 5.56 (17%) usr 0.07 ( 8%) sys 5.66 (17%) wall
13812 kB ( 3%) ggc
tree SSA incremental : 3.15 (10%) usr 0.01 ( 2%) sys 3.18 (10%) wall
8152 kB ( 2%) ggc
hmm, we
--- Additional Comments From pcarlini at suse dot de 2005-09-13 22:27
---
Yes, for 4.0.3 backporting only those bits would make sense. Thanks Janis for
testing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23871
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:36 ---
It looks like the -fwhole-program version of ClearLeft only passes the
first 2 arguments to the ClearInLine call in register, the 3rd one is
passed on the stack.
The reason for that is this code i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
22:37 ---
The main function is huge, no wonder this takes more time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
But the above just fixes the symptoms, it's probably not the correct
way to test for a nested function.
DECL_NO_STATIC_CHAIN (decl) should be true for this function but
why is it not?
/* In a FUNCTION_DECL with
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-13
22:41 ---
Subject: Re: local calling convention not used when using -fwhole-program
--combine
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
>
> But the above just fixes the symp
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
--- Additional Comments From dann at godzilla dot ics dot uci dot
edu 2005-09-13 22:36 ---
It looks like the -fwhole-program version of ClearLeft only passes the
first 2 arguments to the ClearInLine call
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-13
22:49 ---
Subject: Re: local calling convention not used when using -fwhole-program
--combine
On Sep 13, 2005, at 6:36 PM, dann at godzilla dot ics dot uci dot edu
wrote:
>
> --- Additional Comments From
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 22:57 ---
(In reply to comment #6)
> Maybe a better check would be check in the decl's function struct's
> field
> static_chain_decl is set.
I am not sure I understand what you mean here...
Maybe adding
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
23:02 ---
(In reply to comment #4)
>/* We can't use regparm(3) for nested functions as these use
> static chain pointer in third argument. */
>if (local_regparm == 3 && DECL_CONTEXT (decl)
>&& !
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-09-13 23:09 ---
Additional data:
For the testcase in PR8361:
size -f generate-3.4*.o
textdata bss dec hex filename
297025 4 181 297210 488fa generate-3.4-4.0.o
318366 8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
23:13 ---
We have at least 5 SSA_NAMEs, that is just huge. We have only V_MAY_DEFs
for .GLOBAL_VAR and
a TMT.
This happens on all targets and not just ia64.
--
What|Removed
--- Additional Comments From tprince at computer dot org 2005-09-13 23:15
---
Created an attachment (id=9726)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9726&action=view)
include files from libgfortran, required in build
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-13 23:21
---
It was discovered that to use string, you have to do all this magic with the
debug mode that involves not using extern template and a bunch of the other
linkage optimizations. There were some PRs about this.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-13
23:29 ---
(In reply to comment #8)
> We have at least 5 SSA_NAMEs, that is just huge. We have only V_MAY_DEFs
> for .GLOBAL_VAR
> and a TMT.
Over half, 40,000 are scalars registers.
--
http://gcc.gnu.org/bu
--- Additional Comments From appfault at hotmail dot com 2005-09-14 00:16
---
Ok, disregard comment 16, the issue I saw was the same as comment 0.
Unfortunately, there was a '-w' sneakily in a 3rd-party makefile which hid the
warning. Maybe I should open another zilla for warning you
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
00:25 ---
Subject: Bug 23180
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 00:25:02
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
00:32 ---
[20:26] < pinskia> but 38% are in compute_may_aliases
[20:27] < pinskia> and 80% of that is in the loop which is going through all
SSA_NAMES
[20:27] < pinskia> this is in create_name_tags
[20:28] < pinskia>
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
00:35 ---
Hmm, in 4.0.0, we take a nice time at -O3.
may_alias took only:
tree alias analysis : 0.28 ( 3%) usr 0.01 ( 1%) sys 0.21 ( 2%) wall
Total time:
TOTAL : 8.55 1.04
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
00:42 ---
Hmm, in 4.0.0, we have about 6,800 SSA_NAMEs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23835
DR117 is not implemented in the same way of DR118: operator<<(short) calls
operator<<(long), operator<<(unsigned short) calls operator<<(unsigned long),
operator<<(int) calls operator<<(long), etc... I think the way we implemented
DR118 is better (i.e., following the letter of the resolution, with
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
Status|UNCONFIRMED
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
01:12 ---
Subject: Bug 22068
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 01:12:48
Modified files:
gcc: ChangeLog
gcc/config/rs6000:
--- Additional Comments From dje at gcc dot gnu dot org 2005-09-14 01:28
---
Patch committed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22068
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-14
02:49 ---
I have a patch for the alias portion of this
--
What|Removed |Added
AssignedTo|unass
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
03:22 ---
Subject: Bug 21674
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 03:22:17
Modified files:
libstdc++-v3 : ChangeLog
Added files:
libst
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14
05:12 ---
Subject: Bug 19358
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-14 05:12:12
Modified files:
gcc/fortran: trans-array.c ChangeLog
gcc/
Take the following code:
void f(void)
{
int a __attribute__((model(small)));
}
We should reject the attribute but don't as of today even though the code in
ia64.c thinks it should be
rejected:
case VAR_DECL:
if ((DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl))
== FU
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
05:16 ---
(In reply to comment #0)
> if ((DECL_CONTEXT (decl) && TREE_CODE (DECL_CONTEXT (decl))
>== FUNCTION_DECL)
One more thing is that the DECL_CONTEXT at the point where we call the function
t
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-14
06:15 ---
> I still say generating code that is not executable is a ridiculous way to
> handle this ambiguity in the standard...
You still don't get the point. Read again comment #2, the bottom line is that
it's
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:25 ---
"as promoted according to the default argument promotions" is what makes this
undefined by the way.
char is promoted to int.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-14
06:31 ---
Fixed on mainline.
--
What|Removed |Added
Status|NEW |R
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:31 ---
I Have a fix which I will posting in the morning.
--
What|Removed |Added
AssignedTo|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:36 ---
Another way to fix this would have copy-propagation for aggregates, see PR
14295.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:51 ---
Hmm, but vectors are not consider as aggregates.
at the tree level right before optimization, we have:
A_6 = {1.299523162841796875e+0, 1.299523162841796875e+0,
1.299523162841796875e+0, 1.2
101 - 150 of 150 matches
Mail list logo
